In 2020 I swapped from primarily doing iOS development to doing some backend PHP work for several months where I used a custom microservices framework and then switched to Lumen, and then to Laravel, and then integrated GraphQL with Lighthouse to make backend APIs for a couple of different projects. It was all good fun for those months, but I’m now back to what I enjoy most which is iOS app development.
With SwiftUI launching at WWDC in 2019, I didn’t get to spend much time using it other than running a few tests to see what it was like and becoming familiar with Text, VStack, HStack, and various other views. I liked it in 2019. It was only this year, 2021 when I decided to pick up on it again more seriously.
What I have found so far is that SwiftUI is great at some things, but introduces new challenges of breaking away from the traditional way of structuring a program. In the past, I structured my projects so that the ViewController contained just enough code to handle putting information on the view and responding to touches. The logic was separated into business objects which then communicated with various models. This allowed for the logic of the app to be reused elsewhere in the app and not be tied to a single view.
To get more familiar with how SwiftUI works and how it works in an app environment I have started creating a test app to work out what works well. One good example I found from Apple is the Fruta test app that utilises a three-column layout, state objects, nested SwiftUI views, models, amongst other things. Although I won’t be using the three-column layout for my tests, I will be using the other things mentioned, but I won’t really be mentioning what I’m using specifically in this post. I simply wanted to mention Fruta because it’s a great example from Apple.
… →