The foundations of a mobile platform - Scott Berrevoets

In larger teams or companies, most people agree that the mobile platform is the<br>shared infrastructure an app and its features are built upon. In earlier stages,<br>that might simply mean "shared code and helper functions", but when the app and<br>team start scaling, the platform deserves a lot more investment and<br>consideration. The scope of the platform broadens very quickly, and its<br>foundations have a big influence on the engineering velocity of all product<br>teams and the overall reliability of the app in the hands of users.

For a good, scalable platform, a more complete definition is the underlying<br>systems that enable product teams to build, run, observe, and distribute their<br>products . The verbs above do a lot of heavy lifting in terms of what systems<br>they consist of:

Build : architecture, CI/CD, build and lint tools, IDE, developer<br>experience, agent tooling, guidance, and context

Run : networking, persistence, authentication, testing frameworks, and any<br>app/domain-specific systems such as audio playback/voice recording or the user<br>location and mapping frameworks

Observe : analytics, logging, crash/error reporting, general observability

Distribute : release/QA process, experimentation, bug reporting

The size of the platform scales with the size of the codebase, team, and<br>operational complexity. Many apps start simple with very basic functionality to<br>test out an idea, but if the idea catches on and the app scales, the feature set<br>grows, more people start contributing, and distribution and monitoring become<br>more complicated.

Most apps will have some of the systems I mentioned above, however simple, and<br>as the app's complexity or functionality set grows, so does the platform. Even<br>if there's no explicit task to build out some part of the platform, developers<br>tend to extract reusable code so it can be shared across features or even across<br>apps which is the start of the platform.

Mobile is even more complicated

These systems are not uniquely important on mobile, but they are<br>especially important there. Native apps are downloaded once and run on the<br>end user's device, outside of the engineering team's controlled environment.<br>This means network conditions, hardware capabilities, other running apps,<br>and OS versions and settings all vary from user to user. New app versions<br>don't propagate to all users right away, but more gradually over time.<br>Observability into the user's hardware environment is critical, yet more<br>difficult to implement.

Getting the mobile platform right means accounting for all these variable<br>factors as best as possible. It means the design system is implemented in both<br>dark and light mode. It means the error reporting framework attaches relevant<br>context about the user and device to error reports. It means retrying network<br>requests for a reasonable amount of time and then failing gracefully if the<br>network is bad. It means code is easy to test because bugs in production will<br>stay around for a while.

The impact of a good platform

Platform development becomes increasingly important as the app scales. Apps<br>that scale that much usually are popular and have a bigger company built<br>around the app, or there was already a company that's now building an app.

The platform is the foundation of the whole app, which means the quality of the<br>app is, to a large degree, defined by the quality of the platform:

The quality of the design system decides the quality of the UI in terms of<br>consistency, usability, and accessibility

A fast networking layer with good retry and cancelation policies lets the user<br>get their tasks done fast and without network frustration

Architectural patterns decide how testable and reliable the app is

Observability into runtime behavior and edge cases make it easier to catch<br>and fix bugs

The quality of these systems has a compounding effect, both good and bad. A<br>bad platform gets in the way, requires constant maintenance and firefighting,<br>and brings a lot of uncertainty. Engineers spend a lot of time answering<br>questions like:

What networking client do I use?

Is there a way to easily mock the user service?

How do I know my feature works as expected after rollout?

Where in the codebase does my feature fit?

Can I build this UI using existing components?

A good platform has clear answers to these questions:

Use the standard networking client unless you need one of the documented<br>unsupported cases

Mocking services works the same way everywhere

Observability is standardized and built-in; feature-specific observability<br>uses the same logging, analytics, and alerting stack

Module boundaries, naming, and project organization make it easy to<br>navigate the codebase and find relevant code

Feature UI starts from the design system and uses its components directly

Developers have high trust in this platform because it accelerates development<br>and operational velocity while improving feature quality.

In modern-day engineering,...