A short History of iOS programming
Do you remember? When we started to write Applications for iOS we used Objective-C / C / C++ for the classes and Interface Builder to develop the GUI’s. It was a cool but at times slow method to build what we needed. It was all about NIB and XIB files and connecting them to the Obj-C code. Since the resource files were binary it was hard to source control them and it was therefore quite clumsy to work together in teams on the GUI. And not to forget the reference counting! My god, how many bugs I introduced because I forgot to release memory. ARC was a long awaited and necessary compiler enhancement which made our lives much easier!
When Apple then introduced the storyboards and content constraints with size classes, hugging priority values and various other parameters and settings I must admit it was a huge change I needed to adapt for my apps and I almost gave up and really thought about ditching my Music App “Drumsetlist Manager”. But I transformed the complete App to the Storyboard System and gave all GUI parts nice constraints. But indeed it is from my point of view quite a whacky system at times and I avoid changing too much in the GUI since the constraint system is doing sometimes weird things.
Then came Swift. It changed everything for me. No more header files! My entire programmer life I loathed that .h files. I know, it is useful to expose API’s in C / C++ but I loathed them, period. I always thought about them as duplication rather than something which brought value. Of course that was not the only thing I immediately liked about Swift: The strict type system, the powerful switch / case constructs, the much easier to understand closures and much more. Again, I started the adventure and ported my entire App to Swift. It was a long and slow moving process. But thanks to the fantastic tool Swiftify for XCODE I managed to survive that trip with almost intact sanity.
And now for a while SwiftUI looms around the corner and wants to get our attention with an “all source code” approach to GUI Design. With the nice live preview of the coded GUI it seems very approachable and easy to design. Padding and Spacer promise smooth designs without too much constraint tweaking. But without doubt the built in automatic refresh of values through $State, $Binding, $StateObjects is such a relief when you have lots of values which need to have the GUI refreshed. Can’t pay enough attention to that, it makes GUI design so much easier when you do not have to refresh GUI “by hand”. $Environment and $EnvironmentObjects play a huge role when providing global data to the views. Makes life much easier.
So is it the holy grail of App design now?
Here I want to give my opinion about some questions which might arise in some of us developers with this challenge:
- Is SwiftUI hard to learn?
- Is SwiftUI the future of GUI design?
- Shall we rewrite our existing GUI’s with SwiftUI?
So lets dive in:
Is SwiftUI hard to learn?
SwiftUI is very closely connected to Swift and that makes it quite easy to start to learn the basic concepts when you, as I did, either converted some of your apps to Swift or started Apps from the beginning with Swift. You will see very quick results through the usage of the Live preview function. But hold your horses: some concepts need deeper understanding than others and the documentation is not always concise. There is so many “dot” functions with parameters and closures which you need to find out about to write a Coll GUI. There lies the hardship of understanding SwiftUI, it is huge and some concepts are not too easy t understand.
But I would say it is worth the effort. SwiftUI makes so many things easier for you so you should not miss the opportunity.
Is SwiftUI the future of GUI design?
That is easy to answer: yes! Apple will push SwiftUI since they do that with new design methods. It’s about usability for the customers and there SwiftUI makes a difference.
Shall we rewrite our existing GUI’s with SwiftUI?
Here I would say: it depends. I for example started beginning of 2022 a try to convert Drumsetlist Manager to SwiftUI and in the beginning I made good progress. It was wonderful to see how much lines of Code I could ditch due to the React functionality. But then I got stuck because I just had not enough time to do the massive conversion and now this sits as unfinished business on my MacBook Pro.
So I would say you need to decide if it is worth to convert your app and profit from the decrease of source code, resource files and storyboards or you leave it as is and start new apps right away with SwiftUI.
Have a great time coding, leave a comment and I will answer. See you until l the next programming blog!