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.
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:
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!
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.
This step is pretty straightforward:
For our case, we are going to keep it simple and provide a simple function to show a native alert.
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!
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.
From the perspective of building the framework that is pretty much it!
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:
This article has been authored by Ghayas Baig, a Software Developer who joined Airlift fresh out of college in 2020. In the absence of full-time professional experience, Ghayas brought in a rather a wicked knack for back-end development. A few weeks in, Ghayas deftly started picking up on iOS development at Airlift, earning him the unofficial title of an”Ultra-Stack Developer” on behalf of his engineering peers.
If you are excited, like Ghayas, to learn and work on latest technologies, and catch up with other Engineers to problem-solve various facets of our product over lunch, we would love to hear from you at email@example.com