Written by 
With every mobile project, you will eventually find yourself hitting roadblocks that are less about the product and features themselves and more about the surrounding infrastructure that allows everything to exist in the first place. This can manifest in a variety of ways, but as a mobile developer you’ve certainly witnessed some of the telltale signs in areas like maintaining project and build settings, managing code signing, and resolving issues with CI/CD pipelines. These are just a few examples of tasks outside the feature development domain that you might have to deal with when working on a mobile product, and which can really slow you and your team down.
While these sorts of non-product issues are often dealt with in a distributed and ad-hoc way on smaller teams, this approach breaks down as you scale. Platform infrastructure issues can quickly become the single biggest bottleneck for team productivity and have a huge impact on team happiness as the size of both the codebase and the team increases.
Mobile platform teams are born out of this need to tackle infrastructure pain points head-on. The end goal is to create a robust ecosystem that the wider mobile org can reliably build within and on top of, and members of a mobile platform team dedicate their time and attention entirely towards this end. That might sound bizarre to people on smaller teams – “mobile folks not working on our actual mobile product??” – but the allocation of resources to mobile platform work can be instrumental for larger companies looking to operate and scale successfully. In this article we’ll look at why that’s the case, and how to know when it’s becoming an important consideration for your organization.
When and why does mobile infrastructure become a problem?
Mobile infrastructure at smaller companies is usually a shared responsibility. Instead of having a dedicated person – or persons – owning project infrastructure related chores, those tasks are considered to be everyone’s responsibility and they are normally assigned to whoever has bandwidth or is experiencing a given pain point the most.
This approach can work just fine for smaller teams, because project infrastructure issues at that earlier stage are usually relatively simple and dealing with them involves little additional work or overhead. Also, those sorts of rote tasks and common issues – think conflicts in project files and managing code signing – don’t require specialists. Most mobile developers have at some point in their careers encountered these types of early-stage issues, and so just about everyone on the team should be well enough equipped to chip in and help with infrastructure where and when needed.
But as a mobile team grows in size, and as a mobile product and codebase grows in scope and complexity, project infrastructure issues become a recurring pain point and they too grow in complexity. At a certain point, infrastructure problems become so constant and so complex that you’ll need specialists working on them, dedicating time and effort not only to initial investigations and solutions, but also to continual maintenance for the rest of the project’s life. For example, on the iOS side, wrangling .xcodeproj files and handling occasional conflicts isn’t too bad for a small project, with a small team. Scale things up and project files become a huge point of friction, with frequent conflicts that quickly render effective collaboration impossible. There’s no quick fix – teams need to migrate away from locally generated project files, likely using specialized tools and adding robust new processes. So, solving infrastructure at scale isn’t a job for random individuals on the team to switch over to sporadically, on an as-needed basis, but rather it becomes the domain of an entirely new and dedicated team: the mobile platform team.
In practice, project infrastructure issues span so many different areas that it’s normal for larger companies to spin up multiple mobile platform teams over time, each with a certain area of focus. For example, Uber has had an “App Platform” team focusing on performance and architecture, and a “Mobile Foundations” team in charge of frameworks and modular components. Together, they create and maintain the robust groundwork that allows the rest of the mobile org to build and ship product confidently and seamlessly.
The tipping point: how to know when you’re ready for a mobile platform team
Given that infrastructure starts as a non-issue and becomes more problematic with time (and scale), how do you know when it’s time to tackle it head-on? How do you know when you’re ready for a mobile platform team? Understanding the “when” is important, because spinning up a platform team too early can be a distraction and a poor use of resources. Thankfully, to help answer that question, there are some common examples of “tipping points” that lead companies to create dedicated mobile platform teams. If your team is starting to run into any of these telltale signs, it might be time to consider a mobile platform team of your own!
Slow build times
Any team is bound to end up with an app that compiles too slowly unless measures are taken against that from day one — which is something you probably shouldn’t sink time into as a small team, given how difficult the problem can be to solve. Keeping build times down can be exceedingly tricky, so most teams try to keep the problem at bay on an as-needed basis until it runs away from them and becomes a clear and obvious impediment to the team’s productivity.
There’s a lot to be said around different approaches to improving build times, but at a very high level, the solution usually involves fundamentally re-architecting the project into something more scalable and/or migrating the entire project to use a modularized build system like Bazel. Both of these strategies require plenty of know-how and are far too complicated to be tackled by a single developer working alone. In very large companies, this usually results in the creation of a dedicated “Build System/Project Architecture” mobile platform team.
Complex CI/CD needs
Having a robust CI/CD pipeline is an established strategy that can help to maintain high velocity and quality on large development teams, but as the complexity of the workflows increases CI/CD can start to become problematic in its own right. While it’s not hard for a small team to set up a simple pipeline that covers the basics, at larger companies the tasks and functionality being handled by CI/CD become so involved that it demands a dedicated team with the bandwidth to look after it all. This is because large products are hardly straightforward; they often support multiple platforms and have quality thresholds that require a multitude of scripts and third-party tools being activated on pull requests (which will in turn require focused attention from a group of developers). Additionally, CI/CD pipelines increasingly become an integral part of the overall development workflow for the entire team — so much so that a failing or buggy pipeline could prevent anyone from merging work and cause development to grind to a halt. Most teams understand that this kind of situation should be avoided at all costs, and it more than justifies the creation of dedicated platform teams to oversee these critical pipelines.
Testing struggles
Writing and maintaining comprehensive automated tests, like unit tests and UI tests, can also naturally become more difficult as the size and complexity of a project increases. Products with large audiences and lots of features often have extremely complicated business logic, A/B testing scenarios and entry points that most individual contributors have little or incomplete knowledge of. Without the right tools in place, it becomes increasingly difficult for developers to know how to fully test their features across the multitude of scenarios that need testing — and once that tipping point is reached, the quality of the product inevitably suffers. To codify and help engineers uphold the necessary testing practices, it becomes critical for companies to invest in robust testing infrastructure and a team to own that domain.
Release mayhem
Release processes tend to spiral out of control as projects and teams grow. In short: the larger the project and the more contributors involved, the harder it becomes to release regularly and confidently due to there being so many moving pieces, with lots of code from lots of individuals being squeezed into a single shippable unit. Release trains have become a popular solution to deal with some of the coordination overhead, but implementing them successfully demands robust automated test coverage and advanced CI/CD workflows (sound familiar?). Even with release trains in place, many larger teams find themselves eventually needing a dedicated release engineering platform team to make sure the process runs smoothly for each and every release.
Unwieldy project metadata
As a project grows, project metadata — build configurations, code signing collateral, and the like — become increasingly difficult to manage, especially when it comes to maintaining parity across environments and developers. On the iOS side, for example, if you keep finding yourself needing to resolve .xcodeproj file conflicts, chances are you’re at a project metadata tipping point. Out-of-the-box, ecosystem-specific features for managing project metadata usually work well for small projects, but they tend to become inefficient or just outright non-functional for larger ones. Take code signing for example — large projects often include multiple build types (like builds with additional developer features versus clean production ones), so keeping track of which settings are used in which build types can quickly get out of hand. Building custom infrastructure to deal with this type of problem is often what’s required — a task that’s better suited for a dedicated platform team than for an individual developer.
Issues around managing project metadata are often handled by the same platform team that tackles build times, since improving build times at scale often requires using an alternate build system, and for that changing how project metadata is managed is a prerequisite.
You will need a mobile platform team — but maybe not yet, and assembling it might not be easy
With their undivided focus on infrastructure problems, dedicated mobile platform teams can provide a significant boost to large and scaling companies by increasing the capacity of product-focused mobile folks to tackle more complex problems, more efficiently. But, like any other “advanced” concept, it’s important to carefully evaluate when it’s the right time to take that next step and stand up a platform team. If you’re too early, you’ll be in a “large hammer, small nail” situation and you’ll end up wasting time and resources that would be better spent on product work.
When you are ready for a platform team, you’ll find they can be difficult to get going. Not only is it tough to staff a platform team with people that have the right mix of skills and experience in the mobile infra and tooling domains required, but you also have to make a business case for the platform team’s existence in the first place. Your company’s leadership might be reluctant to allocate headcount and money to problems that seemingly have no relation to the product itself. Ideally your team can communicate the need persuasively before you reach a tipping point, but unfortunately you’ll often have to wait until the project infrastructure issues are already affecting daily work and are thus more obvious and measurable.
However long and complicated the journey towards a dedicated mobile platform team might be, it eventually fills an essential need and allows your org to continue growing your team and product successfully. As the complexity of daily tasks and collaboration continues to increase, having dedicated folks focused on project infrastructure can be the key to unlocking the next level of productivity for the rest of the team.