Developing Reusable Components for iOS

Save time developing and testing your apps by writing reusable code. iOS streamlines the process for you with Frameworks built right into Xcode. Frameworks are projects specifically designed to be integrated into other apps.

During my summer work term at Hootsuite, my objective was to build a component similar to the sliding menu in Apple Maps and Apple Music. I built a framework to display a View in a sliding drawer located at the bottom of the screen. The “Bottom Drawer” I programmed can display any View in a sliding drawer located at the bottom of the screen. The component is its own framework so it can be used on any iOS app or even in other frameworks. My first application for the Bottom Drawer was a new framework to allow Hootsuite’s user to select social profiles. The social profile picker will ultimately be integrated into Hootsuite’s flagship iOS app.

Apple Maps (left). Bottom Drawer (center). Social profile picker (right).

In the following blog post, I will go over the hows and whys of writing reusable components and in the process, highlight some best practices I learned in my time at Hootsuite.

Italicized text elaborates on the Hootsuite way to write iOS frameworks. Standard text tells my story at Hootsuite, exemplifying the ideals described.

1. Split up your framework into a separate Xcode project and GitHub repository

Dependency management tools require your framework to be split up from your project so it can be imported at will. As a welcome side effect, your code compiles faster because you only have relevant files in your project.

The iOS team at Hootsuite uses Carthage to manage our dependencies. When I programmed a change in an existing framework distributing the update was as simple as creating a new release on GitHub.

2. Make a demo app to interact with your framework as you work

When working on a personal project, you will often run the whole program and interact with what you just made. If you are making a framework there is no app for you to run, but you can create a separate target within the project that does contain a runnable app. The app should be as simple as possible so it is quick to compile, encouraging you to interact with your framework as often as necessary.

The gif shown is the demo app I used while developing the social profile picker. Most of each demo app is just a ViewController with button actions that connect directly to actions in the framework.

3. Write tests for your framework

Decoupling your framework from the main app makes it easier and faster to test. When a test fails it does so in the framework rather than the main app so you instantly know what files may be relevant to your bug. Additionally, your framework will only contain tests relevant to changes you make so running the tests takes less time.

One of the first things I noticed when I joined my team at Hootsuite was their commitment to high test coverage. In my first week of work, my team taught me about snapshot testing with Uber’s free library. Snapshot tests take a screenshot of a View and compares it to a saved screenshot. The test will fail if the two screenshots are different in any way. These tests are really useful for protecting against unintentional changes in your interface. Better yet, writing snapshot tests is fast and easy to learn.

4. Limit how many files are public

Public files are accessible outside of the framework. Ideally, your framework should have few entry points so it is obvious how to incorporate it into a new project. There is no reason for other programmers to be able to subclass everything in your framework. If anyone wants to expand your work, they can always fork the framework and make a pull request with their changes. When you review the pull request you can double check their files are minimally visible. Of course, your framework may hold a variety of public files intended that serve as building blocks for other projects you own. If you have many files that have to be public, that is all the more reason to hide the ones that do not need to be.

Both frameworks that I have developed for Hootsuite are designed to be displayed from a single class. The few other public classes in the frameworks are small and are only used to configure the main class. Overall, the main public class does very little work other than to delegate work off to the relevant private classes.

Follow your company’s best practices

The recommendations laid out in this article are what I have observed while working at Hootsuite. Most companies operate in different industries and may have different recommendations. Adhere to your company’s guidelines above all else. Working efficiently with your team is more important than writing code the “best” way.