Clean Architecture for SwiftUI
Can you imagine, UIKit is 11 years old! Ever since the release of the iOS SDK in 2008 we were building our apps with it. And throughout this time the developers were in a relentless search for the best architecture to use for their apps. It all started with MVC, but later we witnessed the rise of MVP, MVVM, VIPER, RIBs, and VIP.
But something has happened recently. This “something” is so significant, that the majority of the architectural patterns used for iOS will soon become history.
I’m talking about SwiftUI. It’s not going anywhere. Like it or not, this is the future of iOS development. And it’s a game-changer in terms of the challenges we face when designing the architecture.
What are the conceptual changes?
UIKit was an imperative, event-driven framework. We could reference each view in the hierarchy, update it’s appearance when the view is loaded or as a reaction on an event (a touch-down on the button or a new data becoming available for display in UITableView). We used callbacks, delegates, target-actions for handling these events.
Now, it is all gone. SwiftUI is a declarative, state-driven framework. We cannot reference any view in the hierarchy, neither can we directly mutate a view as a reaction to an event. Instead, we mutate the state bound to the view…
