Tools and tips to scale your iOS project along with your team

We often talk about scalability of iOS app but not much about the project itself or the team. How to prepare your project to move from 2 developers to 6? How about 10 or 20 more? In that research, I’ve listed different tools to prepare your team and project to scale.

Code style

Starting first with code style and syntax, one of the easiest way to standardize it across your team is to add a lint tool. This will analyse the source code of your application to flag any stylistic error and trigger warning when needed.

The most common one for Swift projects are SwiftLint and SwiftFormat. For both of them, you can create a specific set of rules to apply to your code base. This is great to discuss with your team and decide what should trigger a warning or not.

Once you choose which tool and configuration, you can integrate it into Xcode itself or in your git flow to enforce it and make it automatic.

It’s also a great opportunity to define your swift style guide, either based on an existing one like raywenderlich’s one or from scratch.

Project structure

This might not seem a major point but it’s nice to have an iOS project in order. Each team can have a different way to order it, but as long as the whole team agree on it, it’s nice to have standards.

It will avoid having big Views or ViewControllers folders with tens of files lying around and hard to find what’s your looking for. One way to tackle it can be separate folders between features or flows instead of type.

For instance, you can have a Login folder with:

LoginViewModel
LoginViewController
LoginCoordinator
LoginNetworkService …

You can also find inspiration from other companies, for instance I really like Kickstarter iOS approach to put unit test next to each class. That’s an easy way to identify if there are test to add / edit / remove along with your code changes.

Xcode project

With an iOS team and project growing, the Xcode project becomes more and more subject to merge conflicts. However the file format isn’t easily readable and it can take time to resolve each of them.

Fortunately, there are couple tools that can address this issue by (re)generating Xcode project based on a project folder and config file more readable.

A different approach to move from an iOS only integration to something more general. Some developers choose instead to build Xcode project with Bazel, a tool to build and test different kind of apps and languages (Java, C++, Android, iOS, Go) for different platform.

For the past few weeks all Lyft apps in the App Store have been built entirely with Bazel.

— Keith Smiley @SmileyKeith

Assets and Localizations

If your app includes many assets or localizations, it might be good to include a string generator tool to increase their discoverability via autocompletion. It also avoid any typo issue during the implementation.

In that matter, my favorite tool is SwiftGen. In can either be installed for the project itself or wider to the whole operating system via Homebrew.

Storyboards

If SwiftGen supports storyboards and can generate code to initial each of them, I’m not sure that is the best approach. If each storyboard can represent a specific user flow, over the time it can easily become crowded. It also limits the ability for developers to work on same flow, storyboards are known to generate many merge conflicts.

Depending of the size of your iOS developer team, I would suggest to limit this usage or even ban it to anticipate any issues coming when your team will scale.

That being said, it stays a great tool in small apps and app team to quickly prototype and gives a great feedback for new joiners to understand what is the user journey.

Automation tools

In regard to automation tools, the most famous one is fastlane. You can add many steps to automatically test, upload screenshots or distribute your application.

One of those step to highlight in fastlane is iOS certificates. This is a common problem when the team scale, we need new developer certificates or add new test devices that need to be synched across the team. With fastlane, you can do that with not too much effort.

Finally, distribution is key in iOS development. With fastlane, you can easily distribute to TestFlight, HockeyApp and many more other platforms to avoid the manual task of packaging for beta testing.

Continuous integration

There are many many tools of continuous integration in iOS. I will mentioned only couple of them like Bitrise, CircleCi, Bitbucket Pipeline or Jenkins. They all work (more or less great) with other scripting tools to test build and deploy your application.

If your team is small and distribution might not be the priority right now, I would still encourage to find a solution to make sure your app is constantly build and the tests are running to anticipate any issues when scaling the team.

Git flow

Continuous integration goes well with git flow: each pull request will trigger a task to verify that the latest code doesn’t break anything already test covered.

I would also recommend to add Danger for code review to automatically flag any issues for a freshly open pull request. It can highlight dependencies update, if the pull request is too big, if unit tests are missing, etc.

Documentation

Finally, the best way to keep your team and project scalable is to document it along the way. It doesn’t need to cover all the application, but enough for new joiners to get into it by themselves.

For instance, an app diagram listing services and dependencies is a great to have an overview of the application. Your app release flow is also another great candidate. Can a newbie release the app with it? If not, then make sure to update it.

Last but not least is to also document past decisions and code standards defined by the development team. In my current role, we recently defined as a team our new code architecture, our motivation and our choice. It includes examples and playground for the team to experiment. it’s also a great way for new joiners to exercise if not familiar and challenge ideas, we are always open to new ideas.

In conclusion, we went through some of the challenges that can face an iOS team while scaling. I might have not covered all the questions but the idea is to keep them in mind to anticipate issues before moving from 3 developers to 10 and avoid spending days fixing code structure and workflow to support your team.

I didn’t mention recruitment which might be the biggest challenge but could be one single post by itself.

What do you think? What are your biggest challenges while your team and project scaled?