Most mobile developers never get the chance to touch platform engineering. These roles typically exist only at larger companies that have reached the scale where developer productivity becomes a bottleneck rather than feature delivery.

Because platform engineering roles are still relatively rare, most developers don’t really understand what the work involves or whether it might be right for them. I want to change that by sharing what I’ve learned from four years in the trenches as a mobile platform engineer.

A bit of background first:
Not too long ago, I spent up to four years as a mobile platform engineer at ING, where the iOS team grew from a dozen to 60+ developers (Android had similar growth). I’ve led migrations dealing with breaking Swift changes and annual OS releases across large teams, led company-wide architectural migrations from monolithic to modular apps, was involved in migrating everyone to new UI systems, written low-level shared libraries that entire teams depend on, mentored developers, raised quality bars, and navigated the version-controlled hellscape of dependency releases.

So I’ve been in the trenches as a platform engineer. I’ve made a lot of mistakes, but also made good decisions (or at least I’d like to think so). And all this has given me insight into what this role demands and how it differs from traditional feature development work. And now, I want to share it with you.

In this article, I will cover in-depth what a platform engineer does, roles, responsibilities, and expectations. Then you have an idea if this is something you would actually like doing.

Even if this type of work doesn’t immediately appeal to you and you’d rather focus on building user-facing features, I’d encourage you to consider platform engineering if the opportunity arises. The experience can significantly accelerate your technical growth and can challenge you in ways that help in many factors, such as architecture, CI, communication, and even diplomatic abilities. At the end of this article, I’ll share my thoughts to help you decide whether it’s the right fit for you.

Ready to dive in? Let’s start with the basics.

1. What is a Mobile Platform Engineer?

Platform engineers build and maintain the foundational tools, services, and infrastructure that enable development teams to ship software efficiently. Think of them the guardians of developer experience within your organization.

If you become a platform engineer, your core mission is simple: make life easier for other developers so they can focus on shipping great features, and make sure the app stays stable for users.

But I wouldn’t blame you if this sounds a bit generic. That’s because platform engineers can be involved in almost anything that affects how software gets built and delivered.

In simpler terms: A platform engineer helps developers ship. Done well, you alleviate developers, and (if done right) users will be happier, too.

1.1. Your Coworkers Are Now Your “Users”

To think of it differently: As an app developer, you build features for end users. In contrast, as a platform engineer your fellow developers become your users, or “customers”. Your success is measured by how well you enable their success.

It can be challenging work that requires a different mindset, but it can also be incredibly rewarding.

For me, this realization was the tipping point. It’s a weird balance, because on one hand you’re here to serve other developers. On the other hand, you are also kind of an authority figure since you’re part of the decision making; such as setting standards on which tooling or architectures to use, as well as ensuring the quality stays high (e.g. making sure people write tests).

1.2. When Do Companies Need Platform Engineers?

So you might wonder, when a company needs platform engineers.

Personally I either was part of a small team, or I already joined companies that had a platform team (ING, Twitter). Having said that, there is way to figure out if you need one.

The hard decision for companies is taking productive feature developers off their current work and moving them to platform engineering. It feels like asking chefs to clean the kitchen.

If your team is small, there is some communication overhead, but nothing too crazy.

But, at one point, you will notice some bottlenecks. Probably around 10–20 developers.

It can become quite messy to manage all communication, and handling the situation where all devs are working in the same shared codebase.

Even with 8 developers, you can see how much more complex the communication layers become. Not to mention, all sharing code.

So placing all developers in a single app quickly becomes unsustainable.

A couple things happen:

Teams start diverging or stepping on each other’s toes too much. Team A updates a shared component, and accidentally breaks Team B’s feature. Meanwhile, Team C wants to use a different navigation pattern because they read a Medium article, and Team D is still using the old testing framework while everyone else moved to something new.

Releases start becoming too difficult. At first, it’s easy to make a build from the main branch. But for larger teams, missing translations sneak into release builds, there is more communication overhead internally, as well as during releases (E.g. dealing with Apple, for iOS devs), there are too many checklists to ensure the apps are stable and there is an increasing amount of merge conflicts.

Knowledge silos become a problem. There are “hero” developers who know everything about the legacy authentication system, the handful of build scripts that glues everything together, and why the app crashes if you launch it on a Tuesday. But if they go on vacation (or, heaven forbid, quit), productivity grinds to a halt while everyone frantically Slacks them asking “Wait, how does the release process work again?” A company needs fewer heroes and more systems that don’t require a PhD in “Dave’s Custom Framework” to understand.

1.2.1. How platform engineers help

When the team (and app) scales up, a platform engineer can help streamline all work.

By using a modular setup, devs can work on their own feature module, without having to focus on the entire app.

Now, feature devs are still working inside the app. But in a much more limited fashion. They would spend time in the app connecting their feature to the navigation, for example. But the majority of the time, a dev would work on its own module. Then, a platform engineer can oversee the architecture for the entire app, for example. It can ensure dependencies are properly set up. They can ensure that app-wide navigation is working for all feature devs. They can offer deep linking mechanics for other devs to use. Just to name a few examples.

1.2.2. More warning signs

There are just a few indicators. But there are more warning signs to look out for.

One is that features take too long to get released. If a simple change requires touching too many files, and developers are too afraid to touch code, that’s usually a sign something needs to change.

You’re also ready for a platform engineer when the same infrastructure problems keep derailing multiple teams. E.g. you’re having weekly meetings about build failures, dependency conflicts, or architectural inconsistencies. Then you’re spending more time managing technical debt than creating actual value.

Another tell-tale sign is when your senior developers become firefighters instead of feature builders. If your most experienced people spend their days helping others navigate the codebase rather than building new capabilities, you desperately need someone whose actual job is making the system easier to work with. And if it takes a month to get new developers productive in your codebase, the complexity has definitely outgrown informal knowledge transfer.

1.2.3. Consider giving it a trial run

It’s not an exhaustive list. But, if your team is doubting, why not give someone the role of helping the team for a few sprints as a platform engineer. It might be worth giving it a shot.

Pulling one productive developer off features to work on platform engineering can absolutely increase your total team output within a few months.

If one person improves everyone’s build times, simplifies architectural patterns, and creating better tooling, this can multiply the effectiveness of your entire team.

2. Developer Tooling & Infrastructure

Now that you understand when companies need platform engineers and the problems they solve, let’s dive into the actual work. What does a platform engineer spend their time doing day-to-day?

The most visible part of platform engineering is building the tools and infrastructure that make everyone else’s job easier.

When I worked as a platform engineer, our challenges evolved as the team grew. One day you’re writing a tool to prevent stray files slipping into builds, the other day we are dealing with flakey tests. Later, we focused on memory leak detection. As our project scaled, constant merge conflicts in project files became our biggest time sink, so we shifted attention to reducing those.

It’s better to prevent fires than to put them out, which is why tooling is super important. Let’s go deeper into what this tooling actually looks like.

2.1. Platform Engineers Work on Foundational Tooling

Platform engineers create and maintain the foundational tools that feature teams use every day:

Shared libraries and frameworks that encapsulate common functionality. Instead of every team implementing their own networking layer or error handling, you build robust, well-tested libraries that provide these capabilities consistently across the app.

Project templates and scaffolding tools that help teams start new features or modules with the right structure from day one. Rather than copying and pasting from existing code (and potentially copying bugs or outdated patterns), developers can use templates that include current best practices, proper testing setup, and correct dependency configurations.

Automated quality gates that catch common mistakes before they reach code review. This includes linters for coding standards, build checks that flag missing localization strings, and CI configurations that detect potential performance issues.

Custom build scripts and automation that handle complex build processes automatically. This might include code generation for data models, automated asset optimization, or build configurations that adapt based on the target environment.

The goal is making the “right way” also the “easy way.” When good practices are built into the tools, developers naturally follow them without extra effort.

2.2. Platform Engineers Maintain Shared Libraries

A major part of platform engineering work involves making shared libraries for all feature engineers to use.

They might, for example, work on low-level networking-response-caching libraries or libraries that offer custom formatters and logging.

A good engineer hides complexity behind simple interfaces.

For example, integrating with your company’s analytics system might involve configuring multiple SDKs, handling different event formats, and managing privacy compliance. If done well, however, a feature engineer might just write logger.logWarning(“Uh oh the button broke”), and continue with building their feature, blissfully unaware of the hard work you did.

Conversely, feature engineers do occasionally write shared libraries, typically for their domain area. For example, a feature engineer handling In-App Purchases will likely create a Payments module for use across features. But they won’t build the memory-leak-util module that helps find issues across the entire app.

From a dependency perspective, feature developers work primarily in their domain modules, depending on the shared libraries platform engineers maintain. As a result, platform engineers focus on the lower-level libraries: the SDKs, frameworks, and app-level infrastructure that everything else depends on.

2.2.1. Your code lives longer

One big difference from being a feature engineer, is that your code probably lives longer.

A new feature can be released, but also be deleted at one point. The impact will be relatively small. However, if you’re writing a shared library, (such as a custom logging library or A/B testing library), having to delete it, touches all features and feature teams.

By default, assume your code will live longer, and will be maintained longer. These shortcuts you took when making this shared library? It’s now gonna haunt you for years.

But that’s part of it. You’re supposed to write mediocre libraries, but then you will become a better developer and your next library will be much better.

2.3. Security & Compliance Integration

Platform engineers also handle the less visible but critical aspects of app security and compliance. Someone needs to make sure that your production app doesn’t accidentally ship with API keys embedded in code.

Code signing, in particular, becomes a platform responsibility because it’s both absolutely critical and sometimes temperamental. Every iOS developer has experienced the special joy of provisioning profiles that mysteriously stop working overnight, certificates that expire during a critical release, or builds that fail because someone’s local keychain is set up differently than CI. Platform engineers become the people who actually understand how certificates, profiles, and entitlements work together, instead of just clicking “Fix Issue” in Xcode and hoping for the best.

Many companies also have compliance requirements that sound boring but can shut down your entire operation if ignored. Security scanning (checking code for vulnerabilities), license compliance checking, ensuring that your logging doesn’t accidentally log user passwords. Basically all the fun stuff that keeps lawyers happy.

Rather than expecting every feature team to become experts in regulatory requirements (spoiler: they won’t), platform engineers build these checks into the development pipeline so they happen automatically.

The common thread is that platform engineers handle all the tedious, complex stuff that keeps the app secure and shippable, so feature teams can focus on building things users actually care about.

3. Quality and Release Management

Building great tools is half the battle. In the end, it’s important a stable app is released (usually at the end of every sprint).

In a small company, you probably do everything from building features to releasing the app. But as companies grow, platform teams often take ownership of the release process, which means platform engineers become the people coordinating releases across multiple feature teams.

One way companies do this, is by running a “release train”. During this “train”, platform engineers take the latest commit from the main branch, containing the latest feature work, and make a release branch that defines the new build. Then a release team (not just developers, usually a mix of stakeholders) will ensure the build is good for release.

During the release train, the release build is then heavily tested and verified. If done right, a feature team can lean back, and give occasional support to the platform engineers.

Conversely, during issues, feature teams need to quickly scramble and make hot fixes, or else the release train will “crash”, and the release can’t continue.

Note that anything here can halt a release. If translations aren’t correct, or wrong icons are used, or worse, a crash is introduced, then teams need to quickly act to get the release build stable again.

During the release process, it’s “go time” for the platform engineers. There is a lot to ensure thousands, or millions of users, don’t get a faulty app build.

This means that the involvement for an app release is quite different between a feature developer and platform engineer!

As a platform engineer, this means you’re tracking critical bugs that could block releases, coordinating with different teams about their readiness, and joining post-mortems when things inevitably go wrong. When feature teams are scrambling to meet deadlines, you become the gatekeeper who has to make the hard calls about what ships and what doesn’t.

It can be a thankless job until something goes wrong, and then suddenly everyone remembers why having someone focused on release quality matters.

3.1. Becoming the Release Gatekeeper

This role also requires you to be strong, yet diplomatic. Because what happens when a release is starting, but a feature team isn’t ready? Are you going to tell them to wait until the next release, potentially delaying a critical business milestone? Or are you accepting a rushed feature just to make the deadline, risking stability for millions of users? Do you override a team lead who insists their feature ‘just needs one more day’?

These are the kinds of high-stakes decisions you don’t face when your biggest concern is fixing a UI bug.

3.2. Taking on the App-store Responsibilities

Dealing with app stores might be a weekly occurrence if you’re an indie dev, but in larger companies, platform engineers handle the app store communication. This is actually great news for feature developers, who get to focus on building things instead of supplying screenshots so that Apple accepts your changes, or trying to figure out why Google suddenly decided your app needs a different privacy policy.

When Apple inevitably rejects your iOS build because of some obscure guideline interpretation, or when Google Play flags your Android app for a policy violation you’ve never heard of, you’re the one who gets to play detective, figure out what went wrong, coordinate the fix with the right team, and then politely explain to the app stores why your app definitely deserves to be published.

It’s not exciting work, but it means your feature teams can stay focused on what they do best.

4. Dependencies and Architectures

As you take on more responsibility for releases and quality, you quickly discover that the biggest challenges aren’t technical, they’re organizational. This becomes especially clear when dealing with the coordination nightmare of dependencies and architectural decisions across multiple teams.

Once teams scale beyond a certain size, they typically move to a modular setup where different features live in separate modules. This creates a coordination challenge that platform engineers are uniquely positioned to solve.

While feature teams own their specific areas of the app, platform engineers become the stewards of everything that connects those pieces together. You’re responsible for shared dependencies, dependency injection patterns, module releases, and all the architectural plumbing that multiple teams rely on. Those critical libraries that everyone depends on but nobody wants to maintain? That’s your job now.

You’ll also find yourself creating tools, templates, and checklists to help teams set up their own modules properly. Because left on their own, developers will create module structures that make perfect sense to them and zero sense to anyone else who has to work with it later. When the shared networking layer starts throwing mysterious errors, or when the analytics SDK decides to stop working after an OS update, you’re the one people come to for answers.

4.1. Third-party Dependency maintenance

There are many things that can halt development. But I’d like to share a common example of how feature engineers are happily updating their feature, but cause an app-wide problem that platform engineers should try to prevent.

Image, you have feature module A and feature module B, depending on Analytics version 2.3.0. So far so good.

Later, that SDK releases a major version with breaking changes, feature teams will want to update.

Now imagine feature team B updating their module to the latest version, 3.4.0. So far so good, their module compiles. Their feature is updated and ready. Go team.

However, the app now can’t build! Because there is a clash between two major versions.

If you’re not careful, your team ends up in so-called Dependency Hell. This can even block releases! Because teams tend to release their module, but then aren’t always aware that app-wide it can cause issues.

Nothing says ‘fun Friday afternoon’ like discovering your app won’t build because Team A and Team B are having a silent war via package versions.

Platform engineers can make tools to detect this. But, this isn’t just a technical challenge, it’s more of an organizational one.

This is where a platform team can help. To coordinate third-party dependencies for the entire team, across the app and its modules.

They evaluate the new version, understand what changes are required, plan the migration strategy, and work with each team to update their code. This might involve creating pull requests, scheduling the work with different teams, or even helping teams implement the changes themselves.

This is just one example, another common one is where developers are manually updating lock files, basically bypassing a package manager’s resolver, causing dependencies not be able to resolve, later on. That’s an article for another time.

5. Leading Large-Scale Changes

Managing dependencies is just one example of the coordination challenges platform engineers face.

But it’s the large-scale changes that affect every team where platform engineering becomes less about coding and more about organizational leadership.

If there’s one thing that separates platform engineers from feature developers, it’s that you become the person responsible for changes that affect everyone. While feature developers work within existing systems, platform engineers redesign the systems themselves.

I’m not talking about local refactoring efforts. We’re talking about changes that touch dozens of modules, require coordination across multiple teams, and can take months to complete. The kind of changes that, if done wrong, can bring development to a standstill.

I’ve led migrations that affected every single team at ING. Moving from a monolithic app to a modular one meant extracting features into separate modules, getting teams ready to manage their own repositories and dependencies, and coordinating the whole effort so that nobody’s work got blocked. This required strategically blocking git commits, convincing product managers that maintenance work was actually important, and countless diplomatic conversations about timing and priorities.

Another big one was introducing dark mode support, which sounds simple until you realize it means migrating every color, background, and text style across dozens of modules and hundreds of files. Instead of hardcoded colors, everything had to use semantic color tokens that could adapt to light and dark themes. Every team had to update their UI, and someone had to make sure it all happened in a coordinated way. It was months of work, but worth it when millions of users finally got the dark mode they’d been requesting.

Then there was completely revamping navigation across all features. That migration took months of effort and buy-in from teams who were perfectly happy releasing new features with the current navigation. We had to build the new system, create migration guides, help teams update their features, and ensure everything still worked together. It was something the platform team had to orchestrate from start to finish.

Whatever it is, when something needs to be updated across all features, you’ll likely be the one orchestrating it. A feature developer might see this as “just update the navigation library for my feature.” A platform engineer sees it as an organizational challenge that happens to involve code.

5.1. The Diplomacy Game

These are technically exciting challenges, but there’s a lot of diplomacy involved. You’re essentially asking other teams to pause their feature delivery work and help migrate their code to something new. That’s a hard sell when those teams have their own deadlines and priorities.

This requires communication, negotiation, and careful planning. Having goodwill with other teams helps enormously. You can’t be the grumpy engineer who just announces “everyone must migrate by Friday.” You need to build relationships, understand other teams’ constraints, and work together to find solutions that work for everyone.

People skills matter as much as technical skills. You’ll spend time in team meetings explaining why the migration is necessary, helping teams understand the benefits, and sometimes just listening to their concerns. The most successful platform engineers I know are the ones that other teams actually enjoy working with.

5.2. The People Problem in Disguise

Leading large-scale migrations teaches you that technical problems are usually people problems wearing technical masks. The hardest part isn’t writing the code, it’s getting dozens of developers to change their habits, learn new patterns, and trust that the new system will actually be better than what they’re used to.

You become part technical architect, part project manager, part change management consultant. You spend as much time in Slack channels explaining the migration as you do writing code. You field questions like “Why can’t we just keep doing it the old way?” or “This new system is worse than the old one!” convincing teams that ultimately it will get better.

6. Shaping Engineering Culture

As a platform engineer, I literally had people lining up at my desk with their laptops open (this was before COVID when everyone worked in-person). They’d show up with architectural questions: “How should I structure this feature?”“Where does this logic belong?” “What’s the right way to handle state here?”

At first, I loved these conversations. It felt great to be the go-to person for technical guidance. But I quickly realized this approach didn’t scale. I was becoming a bottleneck, the very thing platform engineering is supposed to eliminate.

The breakthrough came when I started turning every recurring question into documentation. Instead of explaining the same architectural pattern for the fifth time that week, I’d write it down properly and point people to the docs.

One nice side effect is that when developers read the documentation first, they came to me with much more specific, higher-level questions. Instead of “How do I implement MVVM here?” it became “I’m following the MVVM guide, but in my case I have a lot of nested views, each with their own viewmodel, how should I set it up?”

The questions became more difficult and gave more insights and nuance. As a result, they made us all better engineers.

The key was making the documentation practical and example-driven. Abstract architectural principles don’t help developers in the moment; they need to see working code that solves problems similar to theirs. I learned to write docs the way I’d explain things in person: start with the specific problem, show the solution, then explain the underlying principles.

6.1. The Architecture Diplomat

You won’t be surprised to hear that mobile developers have strong opinions about architecture. And to be honest, when a mobile dev says “architecture,” they usually mean UI architecture.

Developers can debate endlessly about what’s superior: MVVM vs MVI vs MVP, Reactive vs Combine vs async/await, React Native vs KMM. The discussions never end, and that’s fine for online forums or coffee breaks.

But as a platform engineer at a company with dozens of developers, you can’t have a mix of everything. Consistency matters more than perfection when you’re coordinating across multiple teams and maintaining shared codebases.

This means your team usually has the final say on architectural decisions. And that means you need to learn how to diplomatically disappoint people.

When I was at ING, I received new architectural proposals almost every other week, usually from people who’d just joined: “Hey, reactive architecture is the future!” or “I just read Clean Code, that book says all functions should be max 3 lines!”

Every developer who read a blog post or attended a conference and was convinced they’d found the silver bullet. (Spoiler alert: there is no silver bullet, and your 500-line view controller isn’t going to magically become maintainable just because you rename the pattern.)

Someone has to be the bad guy and say: “We’re standardizing on MVVM, not adopting MVP” or “The main app follows architecture X, but individual modules have more flexibility.” You have to find ways to say no while keeping people engaged and explaining the reasoning behind constraints.

The key is being transparent about trade-offs rather than claiming your chosen approach is objectively superior. And also being open to new ideas. You don’t want to be known as the grumpy “no-saying” person. Sometimes you can allow experimentation on a smaller scope, like letting a team try a new pattern in a single feature module before deciding whether to adopt it company-wide.

6.2. Making Quality Everyone’s Job (Not Just Yours)

At one point I was assigned the task of increasing the code quality. But, I quickly learned that becoming code police isn’t the way to go. Nobody likes the colleague who only shows up in pull requests to nitpick variable names and complain about missing comments.

The secret is that developers don’t mind hearing tools complain nearly as much as they mind hearing humans complain. A compiler error saying “this function is missing a return type” feels neutral. That same feedback from a coworker feels like a personal attack if you’re not careful.

So instead of becoming the person who manually enforces standards, you build systems that enforce them automatically. Set up linters that catch architectural violations, configure CI to fail builds with insufficient test coverage, or create templates that scaffold new modules with the right patterns by default.

The goal is making the “right way” also the “easy way.” When good practices are built into the tools, developers naturally follow them without feeling micromanaged.

6.3. Building a Learning Culture

As a platform engineer, you become responsible for knowledge transfer across the entire team.

New developers need to understand not just how to write code, but why the system works the way it does. Senior developers need to stay aligned on evolving standards. Everyone needs to know what’s changed when you roll out new tools or processes.

This means creating onboarding materials that don’t suck, maintaining architectural decision records that explain the reasoning behind major choices, and writing runbooks that help people debug problems when you’re not around.

The best part about good documentation is that it scales your impact. Instead of answering the same question twelve times, you write it down once and point people to the answer. This frees up your time for more complex problems while making the team more self-sufficient.

I also used my own runbooks. Every year I had to perform some Xcode server updates. It’s not particularly difficult, but remembering all commands and folder structures etc became time consuming. So instead I wrote it down, and my future self had an easier time, as well as other coworkers.

6.4. Developers Don’t Like Writing Tests, Who Knew?

Not all developers joining a team have extensive testing experience, or they’ll be reluctant to write tests.

You can’t force people to love testing, but you can make it easier. Provide testing frameworks that make it easier to test the app. Write examples that show how to test common scenarios. Make the test suite fast and reliable so that running tests feels productive rather than like waiting for paint to dry.

Most importantly, show concrete examples of how good tests have prevented bugs or enabled confident refactoring. When developers see the value rather than just hearing about it, they’re more likely to adopt testing practices.

And yes, sometime you have to give teams “gentle reminders” that their testing isn’t up to par (e.g. extremely low test coverage, or flakey tests that need to rerun to pass, so instead of fixing, they just rerun the test).

6.5. Setting the Tone

Remember, as a platform engineer, you shape the engineering culture of your entire organization. The patterns you establish, the standards you set, and the way you interact with other developers will influence how dozens of people work every day.

Your job isn’t to be the smartest person in the room. It’s to make everyone else in the room more effective at their jobs.

7. Ready for the Next Step?

This article can’t cover everything. Because there is a lot to cover. (e.g. such as dealing with legacy code, migrations, dealing with compiler warnings, supporting multi-app solutions, such as white labeling, etc)

But I hope you’ve gotten a good impression of what it means to be a mobile platform engineer.

If you’ve read this far and the challenges sound interesting rather than intimidating, then platform engineering might be worth pursuing.

Even if you’re not sure, I think it’s a great career booster to either join, or sometimes help, a platform team, and get a taste of what it’s like. Because it’s mobile engineering-adjacent. It’s similar, yet a different type of work.

Now, the next question becomes: how do you actually land one of these roles? How do you develop the skills that platform teams are looking for?

That’s exactly what I’ll cover in an upcoming guide to transitioning into a platform engineering role.

Keep an eye out for that! It will be available for paid subscribers on Substack. Alternatively, consider getting the Mobile System Design book.