Does the following describe your iOS development process? Is this you?
Think about the new feature you just added today. Did you just hack it together and try to get something up as soon as possible? And then found out you just broke something else that was working before.
Now, you have two options:
- Figure out what broke and why? Then fix it. But there is no unit test. So your fix may break another thing…
- You can do a
git reset --hardto take another crack at the new feature. All that work in the last hour goes to the trash can.
This kind of ad-hoc programming is a difficult habit to break
Rewind to one year ago, did you do the same thing with the same result? That’s why your app is full of these quick hacks now.
At the beginning, it felt so easy. There were just 3 view controllers. They were not that massive. Yet. Sure, it worked. But it always leaves a sour taste in your mouth.
Fast forward to today. There are 23 view controllers. Every time you need to do anything, it feels like dragging some deadweight around. You may even be allergic to looking at your own code.
Imagine a year from now. You’ll be doing exactly the same thing with exactly the same result. Only this time there’ll be 33 view controllers.
Is this how iOS development supposed to be? Does every iOS developer feel this way? Even senior devs or software architects?
If this is how you’ll develop all your apps in your career, do you still want to be an iOS developer for the rest of your life?
You want to make things better but just don’t know how.
Why is MVC so popular even though it is so bad?
The iPhone has been around for a decade now. And iOS development is not new anymore. But MVC, for all the troubles it brings, is still the most prevalent architecture you see in a typical Xcode project.
Apple’s very own sample code uses MVC. When you’re trying to learn a new framework, you check out their sample code to see how to make calls to the new APIs. What do you see? MVC. It looks so easy. And you’re so eager to get something cool to show up on the screen. Once it’s working, you leave it the way it is. Then move on to the next feature. After all, you have a tight deadline.
But have you ever thought about why Apple puts everything in the view controllers? It is because they want to show you the easiest way to use their new APIs. They achieve this goal very well. But they didn’t tell you to stop improving. What Apple shows you is just a starting point for a sample project. You’re supposed to integrate it to your production apps!
This “get something to work then move on because you have a tight deadline” disease also manifests itself on StackOverflow, Reddit, …etc.
Another common reason why MVC is in your everyday development is because you inherit an MVC project. The project began in MVC, stay in MVC, and die in MVC. This is a tough thing to overcome since the codebase is already in stage 4 cancer, and the tumor is so huge. As mentioned below, the Clean Swift Handbook includes a one-month free access to my premium mentorship program. You’ll get instant access to a 3+ hour video course on how to convert an existing project to Clean Swift.
You may have heard or even tried MVVM or VIPER
You almost certainly have heard about these other application architectures. That means this problem is real. MVC is not the way to go in iOS development.
But if you try to use these, you’ll quickly find out they come with their own problems.
Using MVVM on its own, it simply moves the massiveness from the view controllers to the view models. Instead of massive view controllers, you have massive view models.
A lot of MVVM’s popularity comes from the reactive nature of using another external dependency – ReactiveCocoa or RxSwift. It is one thing that your app has to rely on yet another pod. It is another when you have to learn a new paradigm called signals programming. Do you know setting up all these signals add a lot of cruft in your
viewDidLoad()? And, most of the time, you don’t even need this reactiveness. Unless you’re building a real-time chat.
VIPER is a good attempt to mimic the Clean Architecture proposed by Uncle Bob that’s been proven over many years of highly critical software systems. It’s been used in many languages such as Java. It is battle-tested for decades and encompasses a lot of good old software design principles.
But it’s missing one very important thing. VIPER puts the presenter at the center of the universe. Every user action, model update, and routing passes through the presenter. Because of this, the presenter has references to every other components in the scene. Instead of a simple unidirectional flow of control as illustrated in the original Clean Architecture, it becomes so easy and tempting to invoke methods on all those references. As a result, you’ll end up with a massive presenter.
Clean Swift provides you a systematic way to develop iOS apps
What if there’s a system that you can follow? That can make the massive view controller problem vanish into the thin air. That can make writing and maintaining unit tests easier than writing the app code.
You no longer have to write spaghetti code, or implement features in an ad-hoc fashion. You can write code that remains readable and understandable for the life of your app. By you or another developer. After a week, a month, a year. You can be confident making changes to your app because you can finally write unit tests that are robust, not fragile.
Why having a system is better than ad-hoc refactoring?
A proven system allows you to make decisions beforehand. Instead of having to pull out a different trick from your bag of tricks for every feature, you pre-decide what you want to do. You don’t waste time by constantly refactoring. You can be more productive by following the same steps to have the right code naturally falls into the right place.
To get a glimpse of this system
Clean Swift fixes that flow of control problem in VIPER by introducing the VIP cycle. The VIP cycle provides the unidirectional flow of control and forms the basis of this system. When you implement a new feature, you always follow these steps:
- Trigger a use case from an
IBActionmethod or from
- The view controller invokes the interactor to perform some business logic.
- The interactor invokes the presenter to format the result to some primitive types.
- The presenter invokes the view controller to display the results on the screen.
The flow of control is always:
No one component can cannibalize the bulk of the logic.
What about reactiveness? In Clean Swift, you don’t need to add ReactiveCocoa or RxSwift. You don’t need to learn about signals. A plain old closure-based asynchronous method in the interactor can provide periodic updates due to the cyclic nature of the VIP cycle.
There are more:
More complex business logic can go to a worker component that is invoked from the interactor.
The new and improved routing system breaks down the routing process into two phases: navigation and data passing.
Last but not least, the request, response, and view models provides the data independence that is super important in isolating changes and writing robust unit tests.
The system is boring but effective. The templates take care of the boring part so that you can be creative in optimizing business logic in the interactor and worker.
After you get the hang of it (and it won’t take long), you’ll get that lightbulb moment and wonder why you haven’t done things this way before.
And that’s why I frequently receive feedback like this:
You can learn this complete system of building iOS apps in one comprehensive package
With The Clean Swift Handbook, you’ll have everything you need to start writing clean Swift code today. You’ll be able to apply the Clean Architecture and its proven SOLID principles to your project.
When you leave work, you can finally free up your mind for your family and friends. You don’t have to think about code at night when you have a system to follow the next morning.
When you buy The Clean Swift Handbook, you’ll get instant access to:
- A 102-page PDF ebook based on the Clean Swift iOS Architecture for Fixing Massive View Controller blog post (updated for Xcode 9, Swift 4, and the latest templates). You can read the original post, but this ebook is updated to work with the latest versions so that you won’t waste time on translating from the old to the new. After this early bird offer, the book will be updated to cover all the scenes and the routing between them.
- A Setup Tutorial screencast to get up and running quickly
- The Quick Start Guide so you can implement your first feature today
- A complete VIP diagram to show you the big picture
- BONUS One free month of 24/7 access to my premium mentorship program (a $99 value) where you can join our private Slack team to get help when you’re stuck, with additional access to even more screencasts and tutorials in our private Wistia group. There is already a 3-hour screencast on how to convert your existing project to Clean Swift. I’ll be adding another one on how to add unit tests later this week.
You can get all these goodies for just $79.
My goal is to teach you how to write clean Swift code. That’s why I include all these bonuses. That’s why The Clean Swift Handbook is more expensive than other ebooks that teach you a bunch of stuff, but only a few chapters are useful. The handbook is a complete walkthrough of building an iOS app using the Clean Architecture. Every chapter is applicable.
More about the mentorship program
Watch the videos to learn how to clean up your existing projects. Take advantage of the mentorship bonus now to guarantee your success. Ask questions and have your code review by me.
This is not just yet another ebook that you buy and forget. I design this package so that I’ll be there to personally interact with you when you need it. When you ask me a question in Slack, don’t expect a short answer. I’ve been known to provide super long and detailed answers to walk you through my entire thought process. I’ll open your Xcode project on my computer to review your architecture. I’ve even put together some sample projects to demonstrate how to make Clean Swift work with the tab bar controller, notifications, and container views.
There are about 100 developers in the mentorship program now. But this isn’t some other Slack teams where you get a lot of noise but few substances. All discussions are specific and practical. They arise from real world projects that we, and you, are actively working on.
You also don’t need to worry about catching up to all the discussions in the many Slack channels. At the end of every month, I’ll provide a monthly roundup to all my subscribers on that month’s takeaways. You won’t miss a beat.
I don’t know how long I’ll continue to offer the mentorship program as a bonus. When it starts to take up too much of my time, I’ll have to stop including it. The handbook by itself gives you a self-contained system that you can follow in your own projects. But the mentorship program virtually guarantees success. So take advantage now while it’s still available.