Do you resonate with any of the following?
- Do your view controllers become massive and hard to understand, fix bugs, and add new features?
- Okay, you moved the business logic to the models. But now your models become too fat.
- Does your app use one gigantic storyboard?
- Have you ever wasted 4 hours to try to reproduce a bug, and then a week to fix it? And still going nowhere? Ready to just monkey patch it?
- Adding a new feature means regression and more re, re, re-factoring?
- Do you feel guilty when your client says “This used to work”?
- The effort vs benefit tradeoff with TDD just isn’t worth it.
Of course, we all know testing cures all these problems. But you’ve tried to write unit tests and given up.
The number one reason why people give up on TDD and testing is because they write tests on top of a bad application architecture.
Think about it. If you can build the world’s most beautiful house but on a bad foundation, the house will collapse. The same thing is true for your application architecture.
I’ve tried repeatedly over the years to work with Unit Tests (especially with iOS) and have failed to find a way that makes sense and does so in a way where the time vs benefits pay-off. I feel I have found it in this Architecture.
But it doesn’t have to be that way. You don’t have to stick with MVC. So you are on your way to search for something better.
- You are convinced MVC is not the way to move forward.
- So you’ve tried MVVM with ReactiveCocoa, but you have to learn a new thing. More dependencies, Yikes!
- Or even VIPER. But setting up all the interfaces in the wireframe is so complex. And you can’t use segues.
I started implementing the Clean Swift architecture just to compare it with the original VIPER architecture. I must say that you did a great job with it and I really enjoy reading your posts.
What if you don’t have to learn yet another framework? You don’t need to add any new dependency.
Imagine you can take back control of your code. You can know quickly and exactly where things are. You can fix bugs and add new features with confidence. You can break down your application flow into multiple storyboards. And yes, you can continue to use segues. And no, there is no wireframe to confuse you.
Finally, you can make clients say yes to paying for TDD, and show them solid proof how their investment pays off. You’ll be able to confidently pinpoint where a bug lies, and have a guilt-free answer to the most dreaded comment – This used to work.
A good application architecture facilitates testing.
Just enter your name and email below. You’ll be taking a huge first step to level up your iOS development skills and impress your peers with clean code and tests. You’ll learn how to apply Uncle Bob’s Clean Architecture to your iOS apps.
Glad to have you on board.
Now that you subscribed, you’ll get a link in your inbox to download my Clean Swift Xcode templates to automatically generate all the components for you. Don’t waste time writing the same boilerplate code. Focus on writing your business logic.
Your templates work like a charm. Everything is very neat and I prefer the Clean Architecture pattern over VIPER.
You should also read Clean Swift iOS Architecture for Fixing Massive View Controller to get an introduction to Clean Swift. This post demonstrates the concepts using an example straight from Uncle Bob himself. It also walks you through how to use the Xcode templates to generate the Clean Swift components. So you’ll start implementing your app’s business logic in no time.
Over the next few weeks, we’ll also deep dive into the following topics:
- Apply Clean Swift and the VIP cycle to Apple’s sample codes
- Put your delegate methods in view controller, interactor, or worker
- Advanced router with multiple storyboards
- Write fast and maintainable tests with confidence to make changes
- An outside-in approach to testing – from acceptance to unit tests
- Writing your own mocks and stubs
- Deep dive into each Clean Swift component
- Compare Clean Swift, MVVM + ReactiveCocoa, and VIPER
- Protocol-oriented programming and Clean Swift
- Converting your existing project to Clean Swift
- How does Clean Swift perform in a large project
- Extracting common code for reuse in workers and service objects
- How to break down complex business logic using workers
If you want me to write any of these particular topics first, or if you have whole other topics in mind, drop me an email.
Also, if you work with Objective-C and like to help me test an Objective-C version of the Xcode templates, email me after you subscribe.
I love to hear how you apply Clean Swift to your iOS projects.
I have to say that the VIP architecture is really growing on me. With the help of templates, everything becomes clear and very straightforward, without the sensation that the architecture is producing too much boilerplate code.