Smaller, more specialized teams

The journey from monolithic team (and codebase) to independent teams and components is a familiar one. Many mobile teams working on a single app start out as one unit that relies on a shared data source. But as they grow larger, well-established client application organizations often splinter into smaller, cross-functional teams dedicated to a particular feature set or functionality. 

For example, I once worked on a mobile team that was primarily responsible for activating and managing connected devices in the home. The six of us were evenly split between iOS and Android, and we all worked on every part of the app, from authentication and login to device management. As the app gained users and feature requests increased, our team expanded, too. Once we reached about 12 engineers, things began to slow down: It took more effort to keep track of incoming changes, dividing work required more coordination, and meetings—even daily stand-ups—ran long. Eventually, we considered splitting into smaller teams, with certain developers working on specific parts of the app.

There are many advantages to this approach. Having more specialized teams can reduce communication overhead and enables engineers to develop deep expertise and increased ownership over their domain. For example, I currently work on activation within the Xfinity app, which means my main development focus is only a subset of the app’s features. This affords me a deep understanding of all app logic within my scope of work and more ownership over the features I build and maintain. I can be an expert on activation because I don’t have to be an expert on everything else.

But this decreased scope can come at a price. Having smaller, more specialized teams requires strong cross-team relationships so engineers know when and how to collaborate on overlapping features. If my team is only responsible for the activation process but we also need to display the device’s activation status on the app’s landing page, we’ll need to know whether the team responsible for that component can support the change, and how their priorities and delivery timeline might differ. 

Unlike a web application, a mobile feature can’t be released independently from the app as a whole, so cross-team coordination and regression cycles must be especially thorough. Clearly documenting changes in a given app release, making pull requests available for anyone to review, implementing a weekly platform stand-up (one for iOS, one for Android), and scheduling shared design reviews for all client engineers can help keep communication flowing across teams without bogging developers down in day-to-day details.  

Well-reasoned architecture

If your end goal is a testable app with components defined by responsibility, how do you get there? Being intentional about app architecture is essential. Code should be structured to enable work in isolation and establish clear boundaries between components. There’s no one-size-fits-all solution here: Your goals—testable code separated into units of shared responsibility, along with any app- or team-specific requirements—should inform your choice of architecture. 

The most common and well-documented mobile architectures are MVC (model–view–controller), MVP (model–view–presenter), MVVM (model–view–viewmodel), and VIPER (view, interactor, presenter, entity, router). Each has its own advantages and disadvantages. MVC, for example, is often used in documentation, educational resources, and example apps, since it provides a simple, straightforward app implementation: The view contains UI elements displayed to the user, while the controller implements business logic and acts as a mediator between the model and the view. However, using MVC for an app with more complex navigation, data that requires significant manipulation, or multiple backend services can lead to the massive view controller problem: As the view controller is burdened with more responsibility, it becomes increasingly difficult to isolate components and limit dependencies. 

In contrast, MVVM and VIPER lend themselves well to larger codebases because they break components down beyond the MVC pattern. MVVM provides the ability to separate UI logic—not just the UI elements—from business logic by introducing the concept of a view model. VIPER goes one step further, with individual components for view, interactor, presenter, entity, and router. As the component names suggest, VIPER designates specific objects to handle navigation and the flow of data between screens or components.

Though these four dominant mobile architecture patterns provide varying levels of flexibility and modularization, they all tend to focus on the UI and business logic components of the code while glossing over responsibilities outside the user interface. But the data driving your app has to come from somewhere. Most of the apps I’ve worked on have been broken down into layers representing the user interface, business logic, storage and caching, and networking. It’s helpful to think of these as layers, rather than components or sections of the app, because a single component or feature may travel through each layer to retrieve the appropriate data to display in the UI, but adding a new feature shouldn’t require code changes to each one.

Splitting your app into separate layers in the architecture design helps teams modify and test each one independently, allowing feature teams to work in tandem with less risk of merge conflicts. A developer should be able to write automated tests for the UI layer by mocking out the business layer; similarly, they should be able to make changes to the networking layer without affecting other parts of the app. 

Though many projects I’ve worked on have taken this approach, it’s worth mentioning that each was at its own stage of maturity with respect to architecture. Some apps had extremely well-defined architectures because we’d spent years improving upon them, while some were more of a work in progress. What’s most important about your app architecture, no matter how robust, is that your team has defined the end goal, and works toward it with every pull request.