The Simple Life(cycle) of a SwiftUI View
Taking the Veteran Approach to the Next Generation
An interview question that I’ve seen appear for numerous iOS developer positions is to name and explain the View Controller Lifecycle events (in order). They are:
- loadView
- viewDidLoad
- viewWillAppear
- viewWillLayoutSubviews
- viewDidLayoutSubviews
- viewDidAppear
- viewWillDisappear
- viewDidDisappear
- viewDidUnload
What’s interesting about this piece of iOS knowledge is that it is (possibly soon to be was) actually quite relevant. If your View Controller does anything beyond just transitioning to the next page or, perhaps, just exist with no other purpose, then you will need to implement at least one of these events to trigger running anything else associated with it.
These events serve a purpose, as well. You could be collecting data before you feed it to your UI. Perhaps you’re waiting for your UI to be displaying before an animation should trigger. Or maybe you need save changes before you leave and move on to the next view.
A Change has Come
Now that SwiftUI is here, native Apple UI development’s future has been, in a sense, revealed. And for many veteran developers, there’s a number of questions surrounding the coming shift.
Flawless’ own Nabil Kazi goes in-depth on the life expectancy of Storyboards and whether or not SwiftUI spells out its doom.
So when it comes to such a core UI topic such as the VC Lifecycle, the logical question many veteran iOS devs are asking themselves (and each other) is this: does this lifecycle (or at least something similar) still exist, or is there something new altogether?
Note the Difference
Right off the bat, before we even get into the new lifecycle and all this talk about View Controllers, there is an immediate difference that should be pointed out. There are no View Controllers in SwiftUI.
That’s because SwiftUI is not UIKit. Though they can interact, SwiftUI is an independent UI framework. With it, Apple is saying “we’re moving forward”.
SwiftUI’s View ‘Lifecycle’
Ok, to be honest, there is no stated View Lifecycle. It’s really because we don’t have to necessarily think in terms of a UI lifecycle anymore (I’ll get into that later on). Paul Hudson from Hacking with Swift even points out how the cyle has diminished in SwiftUI and how that actually reduces clutter in our code:
“Your SwiftUI code will be maybe 10–20% of what your UIKit code was — almost all of it disappears because we no longer repeat ourselves, no longer need to handle so many lifecycle methods, and more.” — Paul Hudson, Hacking with Swift
But that doesn’t change the fact that there are identifiable serial “events” in the life of a View in SwiftUI. Knowing these will definitely be helpful as you transition into SwiftUI.
And so here are what I would consider the lifecycle “events” in SwiftUI:
- View Initialization (my term)
- State and Data Flows
- onAppear
- onDisappear
Where This List Comes From
I deduced this list very carefully. For onAppear and onDisappear, they are actually available as properties on View and mirror the “appear” events in the old lifecycle, so they were quite simple to identify.
View Initialization seemed obvious when declaring properties and States. How it was confirmed for me was when I received this error when setting a property to a function I placed within the same View struct:
Cannot use instance member ‘someFunction’ within property initializer; property initializers run before ‘self’ is availableThis exposes that there is an initialization event before the View’s properties are available (even to each other) but where code could be run nevertheless.
Lastly, there is State and Data Flows. This is really at the core of what Apple is trying to do with SwiftUI and Combine. This is not so much a singular event in a View’s lifecycle. Rather, this opens a view up to almost limitless events.
An argument can be made that States are bindings and are like triggers (such as a tap gesture). They can be used like that, but they’re also triggers that can be used to even determine whether a view or its hierarchy of subviews are displayed. Surrounding those state changes could be logic you would find in viewDidLoad/viewWillAppear and their counterparts. Therefore, I absolutely count them as part of the new lifecycle.
The Philosophy of the New View Lifecycle
To understand the new lifecycle from a bird’s-eye view (pun intended), we need to read into Apple’s own words in regards to SwiftUI:
With a declarative Swift syntax that’s easy to read and natural to write, SwiftUI works seamlessly with new Xcode design tools to keep your code and design perfectly in sync. — Apple
When you line up that statement against SwiftUI’s features and capabilities, you realize that it’s actually a loaded statement. Specifically, that last statement regarding code and design speaks to Apple’s mindset around the new lifecycle.
Whereas in UIKit the VC LifeCycle is a requirement and dictates the WWWWH of our code, the declarative (and reactive) nature of SwiftUI lets data have some say over and alongside Views. In other words, Views and Code have reached a sort of compromise with each other and their relationship has moved on from “It’s Complicated”.
This is evidenced in the new lifecycle. During View Initialization, we can run any code and load any data we need so that the results can/will be used by the UI when it renders. Any changes to State (or any other Combine element) can be surrounded in code leading up to the UI’s reaction. And didAppear and didDisappear cover the ‘life events’ that we need the UI to let us know about if and when we state that we need them (there is no requirement to use them).
Final Thoughts
This philosophy should be familiar to anyone who’s used another declarative and/or reactive framework. Apple is merely accepting and embracing these concepts in a way that works best for their platforms.
While I attempted to translate two generations of lifecycles to each other, the real solution would be opening up to and adopting the more modern approaches to UI should you take on SwiftUI. There is certainly some time before there may be a need to embrace it fully, but Apple has made it clear that this is where they plan to head moving forward.
And lastly, I’m not declaring that this is gospel. Rather, it’s helped me make the transition easier after developing native iOS apps for nearly 5 years now. My hope is that this could help and encourage other vets out there!
P.S.
Be sure to check out the article I referenced above, especially if you’re a Veteran iOS Dev:
