We Decided to Rewrite Snapp iOS App; Here’s Why
It was about a week that we were trying to reproduce some nasty bug in our iOS app that we were hearing about a lot lately. Lots of hair-pulling lead to nothing. We were desperate. We decided to forfeit to the bug and declare a defeat. But this could not go on. Something had to be done, so we decided to rewrite the application from scratch.
This scenario happens a lot when developers are working on some code base they didn’t write. They try to read between the lines to see what the original developer was thinking when she was writing them. Almost always to no avail, so they decide to throw away everything and write the code themselves, hoping the bugs will never appear again. Moreover, it’s not always about debugging. We had a really hard time developing new features on top of the old code base. We had a lot of technical debt that was a result of Snapp’s fast-paced growth. We had to come up with a new architecture and code base that could live long and have features developed on top of it for the years to come.
We had two options to choose from: migrate the code gradually or halt everything and rewrite the app from scratch.
Migration
The less risky approach was migration, of course. This way, we didn’t have to stop developing the app and things can go smoothly over a long period of time. But we found some problems with this approach.
First, we had serious architectural problems in some of the most important parts of code. Snapp is a network-intensive, realtime, event-driven application and our event handler and networking code had deep roots everywhere in the code. We didn’t have problems with static or less-used parts of the app, our main issues raised in the realtime features of it. We figured out that refactoring the networking part of the app would practically mean rewriting the whole app, so gradual refactoring was not possible.
Second, we had a previous failed experience at refactoring parts of the networking code. It was never completed because at that time we didn’t have solid QA mechanisms in place and couldn’t risk releasing the app when we couldn’t thoroughly test it first. Every attempt at refactoring important parts of the app scaled up to editing almost every file in the project. You might think ‘well, you could write unit tests first’. Try writing unit tests for an iOS app with M[assive]VC architecture. It’s not pleasant, it’s borderline impossible.
Rewrite
Since we ruled out “migration”, we ended up with only one choice: Rewriting the application from ground up with a reliable and scalable software architecture, upon which we could write unit tests. Also the QA team had enough time to come up with ideas on how to test the app. This was the technical side of things and we the developers were convinced that rewrite was the way to go… but! Rewriting software that has been working in production for years is risky. Rewriting software that a large business like Snapp relies on is even riskier. So we had to convince the management to let us allocate enough time and resources to this ambitious project.
write their application, you will probably end up reading Joel Spolsky’s article about how Netscape brought themselves down when they rewrote their browser. It’s a nice piece of writing and you must read it before you decide to rewrite the software you’re working on. But that’s just one side of things. There have been definitely successful rewrites in big companies, and what company better than the mighty Uber to have done a successful rewrite? When we started to research on these matters we found out that Uber had recently launched their new application and it was the inspiration that we needed to start the project.
The next reason came from the fact that we had problems developing in Objective-C. When the first version of the app was being developed, Swift 2 hadn’t been released and not only it didn’t have a community around it, but also the language itself had flaws. So all in all it was a logical decision to go with Objective-C then. Flash forward a few years and Swift 4 is released, it’s pretty stable, almost all of 3rd party libraries and tools support Swift and it’s a delight to program in it. All the new developers in the team were also more comfortable with Swift, so the switch to Swift seemed inevitable. It was going to pay off in the long term.
Now we had our reasons, but first we had to convince management that it was a good decision business-wise. Our proposed approach was to break down the timeline of rewrite into three phases: research, implementation and test. During the research period, we would keep developing the old app normally albeit with fewer resources and longer development times; during the actual implementation we would only maintain the old app by fixing critical issues and crashes; and during the final phase we would stop doing any development on the old app and allocate all resources to the new app to make it ready for launch as soon as possible. This would mean that the product team had to agree to a feature-freeze for a few months.
Luckily, management gave the green light and we started this project. We did research for around 5 months and finally came up with an architecture framework of our own, then it took us nearly 10 months to write the app using the framework and finally release it.
Conclusion
There were times that we looked back at our decision to rewrite Snapp and thought it was a mistake; that we weren’t going to finish the project; that we may end up with an app that didn’t work as intended. But we were wrong. We rolled out the new version and received no complaints. Maybe even most of the users didn’t even notice anything, which was the goal from the start.
Please don’t consider rewriting software as a silver bullet to every hard-to-find bug you encounter in development. You have to carefully analyze everything. Maybe if you invest time on rewriting a piece of software that is already working, you lose market share because you have to stop working on new features. And keep in mind that these kinds of decisions are not ones that can be made solely from the technical team. All teams in a company are involved in such matters: Business, Marketing, Product, Design, everyone. They have to plan accordingly.
I currently work as iOS Tech Lead in Snapp and spearheaded the rewrite project with the help of our amazing iOS team. You can also find me on Twitter.
