Down the rabbit hole of iOS design patterns
For years now, the whole iOS community has written content about the best way to improve or replace the Apple MVC we all started with, myself included. MVC, MVVM, MVP, VIPER? Regardless the type of snake you have chosen, it’s time to reflect on that journey.
When I started iOS development, the code architecture wasn’t yet such a big question. At that time, Apple gave a guideline with its well known MVC where a lot responsible held to the ViewController layer.
But then, app became quickly hard to test and maintain. As for any software community, design pattern emerged to help developers. However, the goal never changed: keep a separation of concern and clean architecture.
New one came up to the eco system as alternatives: MVC, MVVM or VIPER. Even if for some of us it’s still new approach, those pattern are definitely older than you think. For instance, MVVM pattern was borrowed from Microsoft ecosystem to support event-driven programming of UI elements got first introduced in 2005.
Moving forward, we added more elements to our new pattern still going further in that search of perfect code architecture: protocol oriented programming, dependency injection, test driven development, functional programming, reactive programming with RxSwift/RxCocoa and so on.
But slowly the best practice results now more to mainstream structures and approaches instead of solving a problem. I think that’s where people get lost today. I’m not sure everybody should follow implement RxSwift for instance.
Don’t get me wrong, I don’t critic the tools, I personally found my balance with RxSwift + MVVM + Coordinator, but I wouldn’t recommend it to everybody. It does solve my problems and fit my needs.
Personally, I think best practice aims for core principle to follow through development, like having an app testable, maintainable with a clean separation of concern. It’s not “VIPER + PromiseKit”. Those are tools and frameworks to allow you to accomplish easier those best practices, and not the opposite.
This apply to everything in general: to be healthy, you need to practice activity and eat healthy. That’s the best practice you should follow. That doesn’t mean everybody has to do yoga. I believe same goes for software development.
Almost every week you see articles and talks about “fixing MVC”, proposing new architectures and flows, even though I’m sure that the majority of the apps still use (in one way or another) MVC, Core Data is still used by a lot of developers and there’s still a lot of Objective-C out there.
— Marius Constantinescu, ios-goodies.com
Since every iOS app is different, every iOS developer should find the right balance for this app. Don’t base your code based on somebody else tool too quickly, maybe they didn’t have the same challenge. Make sure you understand what you’re doing at all time.
Also don’t forget that’s there are still a lot of Objective-C app out there, not everybody migrated to RxSwift + MVVM during the night, don’t blame yourself.
Nowadays, depending of my goals for a new project, I actually prefer refactoring along the way instead of coming too hard with strong tools. I think as long as I follow a clean architecture, I know I’ll be able to pivot along the way if needed. I know some others do the same.
When building a new UI, I always start with just a single, simple view controller. Then, if things grow or get more complex, I start introducing new objects like a logic controller, view model, child VCs, etc. Constant refactors is much better than separating things too early 👍
— John Sundell @johnsundell
In conclusion, I think mobile developers should first stay focus on finding the best problem solver fixing their needs while following best practices. This will avoid getting trapped between complex code structures and powerful frameworks.