“Want to play ping pong while my UI tests are running?”

How long does a ping pong match last– 10-15 minutes if you’re any good? That’s how long a UI test can take to complete for a mid-size iOS app. And, as your app size grows, both testing and compile times increase too! This is why I, alongside my Devsu counterparts, began looking into possible solutions to improve performance and increase testing speeds within iOS applications.

An app should have unit and UI testing targets throughout its QA process. So, when you only consider a single target during the development stages then you need to change a line of code, Xcode rebuilds the entire app. Headache, right?

Additionally, the 5 minutes for it to compile is also a reason to pop an Advil. And, that’s just for a small to mid-size app. It can be upwards of 10-15 minutes for larger apps. The time lost is even more significant when you have a team of developers working within the same environment. The time adds up fast! No wonder we’re so good at table tennis.

This problem has been prevalent in app development for a long time and many believe frameworks are the answer.

Frameworks

Apple says “A framework is a hierarchical directory that encapsulates shared resources, such as a dynamic shared library, nib files, image files, localized strings, header files, and reference documentation in a single package.”

In other words, frameworks are self-contained, reusable pieces of code that have a target and are separately built. Meaning, if you change a line of code in one framework, Xcode only rebuilds this one which saves time and increases speed.

There are also some architectural benefits of using frameworks as well. As a bonus, they follow some of the clean code principles:

• Encapsulation
• Modularity
• Reuse

Why CocoaPods?

By this point, you should have installed cocoa pods in your app, and if not, you can find how to install them here. 

There are a few advantages to using CocoaPods with your frameworks:

• Light repo: There’s no need to keep your frameworks in the main project; they can live in a different repository, making the main repository lighter.
• Centralization:  When working with multiple apps, you can create a framework for appearance so all apps can use the same framework, keeping consistency in colors, button styles, fonts, etc. 
• Modularization:  You don’t need to have all the code or features within the same project. If launching a feature, a developer could work on this repository separate from the main product. Simply add the pod when ready to activate the new feature and remove it whenever you choose to deactivate it.
• Documentation: Each feature or framework can have its documentation, allowing for an easy transition of work if needed.

What should get a separate framework?

The short answer– it depends. We can divide frameworks into two big groups: 

• Features: Frameworks that hold full functionality including visual and logic. 
• Utils: Frameworks that hold technical parts of the app such as storage. 
  

To conclude, frameworks are useful to modularize an app and, in conjunction with Cocoapods, improve an app’s architecture, therefore, positively impacting the speed and performance. Now, instead of playing Ping Pong to kill the time, we play to relax after a successful test and completed ticket– “Anyone up for a match?