SwiftUI is amazing and surely helps a lot to ease up the development process for iOS apps but one thing as a developer I am curious to know is
What’s the default architecture of SwiftUI?
It’s been more than 2 years already and apple should’ve come up with a default architecture document that would’ve acted as a standard baseline for developers to start their development with SwiftUI
But knowing what a wonderful job apple does in writing developer documentation, I don’t see that happening soon.
SwiftUI is not the first language to be declarative, there are many with good documentation, examples, and separate documentation which speaks of good practices to follow
In one of the WWDC talks, Apple talks about how it has certain tools to manage state and binding for it’s views.
The video also has a 10 second wisdom starting from 31:49 on how you can build/choose/implement the architecture that you always want to build without any sort of trade-offs between great architecture and performance, but never really talks about what should the starting point be for SwiftUI architecture.
The lack of documentation has caused developers to be creative in their approach and use good/bad/worst practices for their SwiftUI projects because apple literally said do whatever you like in their WWDC talks
This doesn’t mean that one exploits all the basic principles of programming and start introducing tight coupling or implementing poor abstraction practices in their code.
Example: One can include API & Database calls inside a SwiftUI views and nothing wrong with that the app would still work and can be shipped to the app store ✌️
Even when you were reading the above statement, you would’ve heard a voice in your head that said
No, that’s a bad idea of dumping everything inside the view, don’t do that
and that’s because doing that would result in massive views and that’s kind of bad when it comes to writing tests or even reading the code.
Making changes in such a codebase will be like fighting a war, and being high on caffeine all the time.
The WWDC video also introduces us with a new term
Single source of truth for views
This statement is just like how apple names the colors of their iPhone.
The above statement means there should be one class that should provide data to your view and the view will render based on the changes.
Many tech enthusiasts call this data provider class as “Model” because that’s what apple has done in their SwiftUI demo.
I have never followed the demo code provided by apple and the reason is that IT’S A DEMO don’t expect some wonderful standards to be followed there.
If you end up following a demo code word by word, you would end up breaking separation of concern, implementing poor abstraction practices and whatnot
The Fruta demo of apple is a good example that violates single responsibility principles but that’s a demo I don’t expect a demo to follow all the good principles
Just like many tech influencers out there use good old singleton patterns to demonstrate database CRUD operations and end up creating one massive GOD LIKE OBJECT or multiple singletons classes per entity.
The singleton file containing all those CRUD operations of multiple entities literally feels like Thanos having the gauntlet with all the infinity stone
Sure the app will work, as the compiler doesn’t care what you follow, as long as its code that the compiler can understand it’ll process it.
But remember, we don’t write code for the compiler, we write it for humans so that whoever ends up managing the code after you, does not have a tough time making changes to the code.
It’s not even about management it’s about doing the right thing.
So what should we use?
I would start with a simple good old MVVM along with decomposition where I don’t have all the code inside my ViewModel.
Remember, the ViewModel is a orchestration layer and should not contain any API, database, validation code and must not contain any knowledge about the views.
The ViewModel is your single source of truth for the views and can contain required publishers for rendering the views.
I am not an MVVM enthusiast, but before coding I start with something simple and then move forward analyzing if it make sense? and checking if I am following all the principles of programming
For some reason, many tech influencers are moving away from using the term ViewModel and want to call the ViewModel as “Model”
The reason for this, apple in their demo is using the word “Model” and is simply dumping everything in the “Model” class making it similar to a GOD LIKE OBJECT containing everything
If you follow this route of dumping everything in one “Model” file, the size of this file will be astronomical, it’ll be a violation of not only single responsibility but also abstraction and everything will be tightly coupled to this one model file
I don’t expect that apple follows all the principles of clean coding in a demo as the intention of the demo is just to show you how to gt things done.
Just because one refrains from calling the ViewModel as ViewModel because apple is not using that term and wants to call it “popeye the sailor man” doesn’t change the fact that it’s a ViewModel.
Irrespective of the architecture that you follow, if you are not going to write decoupled code or if the codebase you end up with is not flexible to change.
The cost of making changes in such codebase will increase and that cost will be paid by endless hours of debugging, sleepless nights and tons of frustration.
I hope this article helped providing some insights into the topic, don’t implement bad practices only to realize that it’s too late to make changes and now you have to live with a bad design.
Think before you code.
