Setting the scene: you’ve just started a new job at a bigger company. You’re excited and a bit nervous as its your first job working on a larger app. What will it look like? What are the differences between this and some of the other codebase’s you’ve worked on? You get access to the repo where the project is stored, open the codebase, and you’re greeted with a navigator pane in Xcode that contains several projects and packages. Not exactly what you were expecting. At first glance, it all looks a bit confusing, and you’re not sure how to approach the work you’ve been assigned. The more you get to know the team, the more the word “modularization” keeps cropping up in conversation, and you’re a bit nervous to admit you’re not totally sure what that means.

What is it?

Modularization is the practice of pulling out portions of code from your main codebase into smaller, separate, units of code. These units of code exist separately from the main codebase. The actual definition of modularization is just that, and quite simple to understand. There are technicalities to it, like all things in software engineering, and the approaches will vary by project as to what is actually inside those smaller units of code.

Whats the purpose?

The belief behind modularization is that these separated units of code are reusable and decoupled from your main codebase. Good modularisation embraces decoupling, and gathers code together with a high level of cohesion. Modules that have a high level of cohesion typically have the same reason to change when you need to amend a portion of its functionality. This mean you effectively turn pieces of your codebase into units of code that are independent, and don’t know much (if anything) about one another.

Its usage has been widespread in the industry in other platforms for a while now. You’ve perhaps have heard of “microservices” which is a type of modularization web platforms use to divide API services up into smaller units of functionality. For example, if you had a REST API for a system handling hotel bookings, a microservice architecture would have a unit of code backing the /bookings/ endpoint that allowed the consumer of that API to make a booking, and a separate, decoupled unit of code backing the /hotels/ endpoint, that returns data on which hotels the company has available. These two endpoints won’t know about each other directly, with the goal that making a change to one endpoint, won’t effect the other endpoint.

Much like other concepts that more mature development platforms have pioneered and moved forward with, this is now dripping into the iOS world.

A more iOS-like example of the above would be that your screen for showing upcoming bookings a user has, exists independently and wouldn’t know anything about the screen for showing a list of hotels the user could book. These modules would also be highly portable, meaning it would be easy to use them in another project. Perhaps your company has a “spin off” app that uses bits of functionality from the “main” app i.e the YouTube Kids app uses portions of code from the main YouTube app.

Why is it such a buzzword now?

The below shouldn’t be treated as fact, just a collection of thoughts I’ve been forming about this.

When iOS first started out as a development platform, it captured the attention of a lot of hobbyists and new developers. A lot of those early codebase’s reflect that. Software development practices weren’t always followed – much in the same way early webpages were developed. This was great, as it allowed people to explore the new platform and get creative, but the obvious downside was the projects created from that weren’t always built to last. In part because no one knew if it would last, so it arguably didn’t make sense to invest the energy in building a scalable product.

Over a decade later, some of those earlier apps that have continued to be developed will have faced a problem: making changes at scale will have become increasingly challenging as teams and projects grew in scope and complexity. We’ve all been there and experienced the fear of being in codebase’s where you’re too scared to make a change as the code is so coupled. Making even the smallest changes in those codebase’s can have a ricochet effect across the rest of the app. When you have that sort of fear in a codebase, you’re less likely to make the more radical changes to improve the code as you don’t have confidence in the changes you’re making. Its a viscous cycle.

This is why its a popular topic in mobile at the moment. Development teams are wanting to be able to build things faster, and codebase’s where every object has the potential to know about every other object in the codebase, do not allow for quick or confident changes. Google even has their own page dedicated to modularization in Android. Its arguably why theres a momentum around Swift Package Manager, as the previous ways for pulling out code into separate units of code took all sorts of forms, and theres been an increasing desire to standardize it.

It feels…odd…

…and thats totally fine. Expected even, if you’ve not been exposed to this before. What I would say is its worthwhile taking some time to understand it and why the team have opted to go this route. Its easy to look at something new like this and think its "convoluted" or "over-engineered", but if you give it a few months to a year to let the concepts sink in, you’ll be thankful for it in no time.

Getting your head around the finer details of modularization is one of the more challenging aspects of modern day iOS development. You’re not alone in feeling that, and you’re probably not alone in feeling that on your team. Ask questions. Lots of questions. You won’t be the only one who has those questions and quite often they’ll lead to discussion points that the rest of the team will be grateful for!

In conclusion

The overview to take away from this is that modularization is a way of pulling out code from the main codebase, into smaller units of code, with the intent of decoupling those units of code to make changes and additions to the codebase easier. Every team will have a different approach as to what those smaller units of code will look like. Its a new-ish topic in the Apple development world given the history of the platform, so its the perfect time to be asking any questions you have about the project structure.

We’ll be diving into the finer implementation details of modules much more in the future.