Modularising iOS apps into powerful reusable kits

Published Mar 17, 2018
Modularising iOS apps into powerful reusable kits

Based on how we do at Zomato for 10+ apps and Millions of users

"You might not think that programmers are artists, but programming is an extremely creative profession. It’s logic-based creativity. — John Romero"

When I joined Zomato, our iOS team was young. We were quickly expanding from a single app to multiple apps for customers and restaurant owners. In addition to this, we started developing another app for food ordering in parallel.
The restaurant discovery app of Zomato encompasses the online ordering product, along with a lot more features. To keep up with the pace of the business, we started duplicating code between multiple apps.
Eventually, features started breaking, development time increased, and poor repetitive code led to a frustrated team. A bad place to be in.

The Challenge

"Clutter is non-essential. In code and in life."

Our code could no longer live as a whole. We had to do something to break it down and make it more manageable.
Our vision was to have a development system where a change in a single pixel would cascade to the whole picture within seconds.

The challenge : To create kits that could be shared between multiple apps.

The Solution

We started dividing the main restaurant discovery app into kits. Some core kits are: UI, Commons, Networking, Models, Controls.

These kits would be independent but smoothly work with each other. For example, a use case is to change the primary colour of all iOS apps from one place.

Tip : Well-built, reusable kits will save time and development cost.

Some common kits to start structuring your appsWe also started creating an internal UI Kit app to showcase all the components within the organisation. Today, the Zomato iOS UI Kit powers the user interface of all products — restaurant discovery, online ordering, business apps, and more. It helps millions of users, restaurant owners, and of course our development team.
Since we supported iOS7 then, we had to create static libraries for each kit. For later iOS versions, Apple introduced dynamic frameworks with better memory management.

Tip: Use an XCode workspace with multiple projects. Each project can be a kit.
This way, each kit will have independent code but still work smoothly with other kits. These projects can be used between multiple apps.

We use these modular kits to build the best experience for our users and structure our massive code.

Finer details 👾
What about versioning for kits? Can we use subtrees in Git for these kits? Subtrees provide better code semantically, but we found them to be buggy. Plus they complicated things for our newer team members, so we decided to not use them.
What works for us is to store repositories locally within the same hierarchy and have separate GitHub repositories for each of them. To keep the code in sync, we use the same branch name. For important release versions, we use Git tags.

Our app kits stored locally. These are XCode projects are in the same hierarchy and used together in a single XCode workspace. To keep them in sync, we use the same branch names.What if a kit needs app-specific code? Here’s the awesome part, there is a configuration and an initialiser layer to each kit. These layers are initialised during the app initialisation and data is passed from the app core to these kits during runtime. This is somewhat similar to UITableViewDataSource where it expects data from the controller. Here the main app can be considered a view controller and the kit can be considered a table view that demands its configuration through a data source.

When do we add a component to an app kit? If a component needs to be shared between multiple apps, it is added to the relevant kit and reused. We have a serious policy of NOT copying code between multiple apps now. Super modular and a single source of control.

Tip : Single sources of control in your application are very important for modularity.

Learnings and Impact

By moving the app to kits, our team ended up essentially creating iOS “stationery”. Our development time sped up by almost 5X. We now kick off new apps in a single day with the help of all of this shared code.
These apps look and feel similar, and function well for over millions of users.
These modular kits power all our main consumer-facing, merchant-facing, and internal iOS applications. We also used this architecture to ship 200+ white label apps for individual restaurants seamlessly. (The system is a completely different story of automation)

And most importantly, it’s less stressful for our single-digit team to manage millions of users! 😎

Be modular and win 🏆

Thanks for reading. Hope it helps you!
See more on my website —

Discover and read more posts from Arpit Agarwal
get started