No More Reinventing the Wheel — Implanting Modularity with iOS Frameworks

administrator

August 28, 2021

Being at Airlift for more than six months, I have come to realize that one of the most critical components for building a highly successful startup is speed. The issue with that, however, is that in meeting the demands for high-velocity executions, people, especially engineers, run the risk of forgoing quality and consistency.

At Airlift, one of our core principles is to embody the spirit of a “doer” i.e. to not wait around for perfectly complete information to make informed decisions. As a growing business that takes on new challenges everyday, we often find ourselves in these situations. Our approach, generally, is to do what is required – if it goes well, we celebrate, if it fails, we learn.

Generally, this philosophy works well — it is what allows developers like myself to experiment with new and uncommon things which often lead to one of a kind quality product/feature. However, as with an aggressively-scaling business that puts forth even more aggressively-scaling product requirements, pending features stack up to a huge backlog. In this case, not only does speed become a necessity, but quality and consistency are also required so that what reaches our customers is something that they adore and not something that frustrates them.

So – this poses the question – as engineers, how do you strike a balance between speed and also quality and consistency?

TL;DR: Become Modular!

While you can always copy and paste repeating items from your codebase to build a screen that looks similar to another one, it is certainly not the most ideal way to do so — here’s why:

Imagine copy pasting work from 5 files into 5 newly created files. Not only is this still time consuming, you will be forced to rename a lot of variables or functions according to the new requirements.
Now imagine that a bug has been identified in a piece of code that you copied to multiple files. Now, you have to fix that not only in one file, but all the files containing that code. All this leads to a very unmanageable spaghetti code.
Worst of all, now the QA teammate will have to test all the impacted areas since your code was changed at so many places and not just one place. This will only add to the backlog and slow deployments down further.

The solution here is to make everything modular — to make every piece of code as generic as possible. By virtue of being modular and generic, it becomes all the more easy to manage and faster to implement. In iOS, we should transform everything that can be made generic into a set of frameworks (modularizing them) and reuse them in our actual codebase.

How does this help, you ask? Well, having a piece of code as part of a framework will help you reuse it in many files or places in your code without having to copy & paste it to different places. Having a bug in your code now means changing it only at a single place — your framework.

What Should be Modularized?

Anything that can be made generic should be modularized. Having a framework of utility functions that are used by your application at hundreds of places is significantly more effective than having the actual code of the framework copied to hundreds of places.

The takeaway? Modularize your UI components, modularize your logical components, modularize your navigation components, modularize that which is reused.

Enough justifications — let’s get to how we can actually build our own framework in iOS!

Building your own iOS Framework

Prerequisites : at the risk of stating the obvious to the engineering-audience, building an iOS framework requires XCode, and of course, running XCode requires a macOS. That being said, for this article, I’ll be using XCode 12.5 along with macOS Big Sur on an M1 Macbook Air.

Step#1: Create a new Project in XCode

This step is pretty straightforward:

On XCode, select Create a new XCode Project.
On the next screen, select Framework/Cocoa Touch Framework depending on your XCode version.
Give your project a name and select a location to save your project:

Step#2: Adding necessary files that make up the Framework

For our case, we are going to keep it simple and provide a simple function to show a native alert.

Add a file called Alerts with the following code:

Step#3: Building the Framework

It is critical to understand that XCode builds the framework only for the selected architecture. So, if you have selected any iOS Simulator, the built framework only works with the simulator, but if you build it for a physical device, the framework will only work with a physical device. That is just Apple’s way of ensuring that unused framework builds are not shipped to AppStore Applications.

There are ways to build a framework for both the architectures called “Universal Frameworks” — but I will leave that discussion for another day!

Start by building the framework to make sure that there are no errors.
Once the framework is built, on the left pane in XCode, under the Products Group, you will find a .framework directory. This is your build framework:

Step#4: Using the framework in your Applications

There are multiple ways in which you can use your framework in a multitude of your Applications. If you plan to use the framework only in your own applications, then a simple drag and drop should do the trick.

Simply drag the .framework directory into your application on XCode. Ensure that you have selected ‘copy items if needed’.
Ensure that you select ‘Embed & Sign’ under the ‘Frameworks, Libraries and Embedded Content’ in the ‘General’ tab of your Target.

To test the framework, import it and use the following code:

From the perspective of building the framework that is pretty much it!

To sum it up, I present the Golden Question — by doing the above, what do we achieve?

Suppose that you have an e-commerce application which follows a strict theme in terms of look and feel. At numerous places you show alerts to your users. Most of the time, developers merely create an alert wherever it is required, often by copy-pasting the same alert code from the existing one. Not only does this increase the lines of code, over time as the application grows, it becomes messy and unmanageable. Refer to the figure below:

Having this Alert code as part of a bigger UI framework that constitutes the common UI elements of your application, makes it much easier to not only manage it but scale it very quickly as well. All that is done with quality and consistency.

In large applications, you can have your own UI framework for displaying commonly-themed UI elements like Alerts, Pop Ups, Table Views and Collection Views. You can have a Utility Framework that has some common business logic that is used in various different places throughout your application. Refer to the figure below:

All of this, with the extreme maintainability and scalability benefits, ensures that now that your code resides only in one place rather than being spread out everywhere.