Search for what mobile app maintenance costs and nearly every answer lands on the same rule of thumb: budget 15 to 20 percent of what the app cost to build, every year, with the first year running higher. That’s a reasonable place to start a budget conversation, but it only tells you how much to set aside, and it says nothing about what the money buys. If your app is built in React Native, most of what decides the real number never shows up in that rule. It comes from how far behind your Expo SDK is, which native modules your app leans on, and whether a given fix can ship over the air or has to wait for a store review. Below is what a React Native maintenance retainer should contain, month by month, so you can judge any proposal on the table, including ours. If you’re still pricing a new build, our post on what a mobile app costs to develop covers that question; this one starts after launch.

The scope lists you’ll find in most proposals are sensible enough: testing against new operating system versions, keeping up with App Store and Play Store policy, dependency and security updates, fixing defects, managing infrastructure and certificates, and watching the app once it’s live. Each of those means something more specific once the app is React Native.

• Operating system releases. Apple ships a major iOS version every year, and Google raises the target API level the Play Store requires every year, so compatibility work arrives on a schedule whether you planned for it or not.
• Dependency updates. A React Native app has two dependency trees, the JavaScript packages and the native iOS and Android libraries they pull in, and the two drift on different schedules. If your app uses Expo, the SDK version sets the pace for much of both, because each SDK release is paired with a specific React Native version and a set of compatible packages. Falling one SDK version behind is routine, but falling several behind means the upgrade has to step through each version in turn, and some of the native modules you depend on may not have kept up along the way.
• The New Architecture. React Native’s newer system for rendering and native modules changes how native code talks to JavaScript, which means the native libraries your app relies on have to be checked against it. Part of maintenance is knowing which of your dependencies are ready for it before an upgrade forces the question.
• Shipping fixes. Over-the-air updates, through tools such as EAS Update, push changes to your JavaScript and bundled assets straight to installed apps without a store review. A retainer should be explicit about which changes can go out that way and which need a new store build, because that split decides how quickly a security fix reaches the people using your app.
• Store policy and monitoring. Policy changes arrive on Apple’s and Google’s timelines, and an Android app that misses the target API level requirement can become undistributable to new users. Crash and error monitoring covers the rest, so you hear about a broken release from your tooling before you hear about it from your reviews.

A maintenance engagement that starts with code changes on day one is changing an app nobody has looked at yet, so the first weeks should go to an audit. That means checking which React Native and Expo versions you’re on and how far they are from current, which native modules are abandoned or pinned to an old version, when your signing certificates and provisioning profiles expire, and who holds the Apple and Google developer accounts. Anything already overdue gets triaged first, whether that’s an SDK version that has aged out of support, a module whose maintainer has walked away, or a certificate that’s about to lapse.

Our own retained engineering for existing products opens the same way, with audit and triage before anything else, and the page lays out how the weeks after that unfold. The steady monthly work starts once the findings are written down and put in order, so you can see what’s being fixed first and why.

Once the app is stable, a React Native retainer settles into a calendar that Apple and Google mostly set. In a typical month you should see:

• Routine dependency bumps on the JavaScript side, made while each change is small and easy to review.
• Over-the-air releases for JavaScript-only fixes, so a broken screen or a bad API call gets corrected without waiting on a store.
• Store builds for the changes that can’t go over the air, batched where that makes sense and timed around review turnaround.
• Preparation for the next iOS release and the next Play Store target API deadline, starting while the new OS versions are still in beta and well before the public release.
• A written update in plain language covering what shipped, what’s coming next, and what needs a decision from you.

The calendar matters because the annual OS cycle doesn’t care about your roadmap. When a new iOS version ships and a native module you depend on isn’t compatible yet, the work to patch it, replace it, or fork it has to happen whether or not you had anything else planned that month. If that work started during the beta, it’s mostly done by release day, but if it waits for the public release, you’ll usually find out about the problem from crash reports.

Maintenance keeps the app you already have healthy and shippable. Bigger pieces of work, like a major new feature set, a redesign, a ground-up rewrite, or a move off React Native to fully native Swift and Kotlin, are each scoped as their own project with their own estimate. Our retained engagements do include feature development, and that works because the upgrade and dependency work has a protected place in the plan instead of competing with the backlog for whatever hours are left over. When a retainer quietly absorbs feature work, the SDK upgrades are the first thing to slip, and a year later the app is several versions behind even though the invoices never stopped. So when a proposal draws this line explicitly, read it as a good sign.

Sooner or later every app owner asks some version of the same question: if nothing crashed and nobody filed a bug, what did I pay for? Most of the answer is on Apple’s and Google’s calendars. A new iOS version and a new Play Store target API requirement arrive every year, and Expo and React Native keep releasing in between, so every release you skip makes the next upgrade larger. A quiet month is the time to move the next SDK upgrade forward before it’s urgent, and to replace a native module that’s falling behind while there’s still time to test the replacement properly. It’s also when the certificates that expire next quarter get renewed. An app that only gets attention when a store rejects a build tends to need all of that work at once, under a deadline someone else set.

A provider who maintains React Native apps day to day should be able to answer each of these without having to go away and check.

1. Who owns the Apple and Google developer accounts? They should be in your name, with the maintainer added as a user, so you can change providers without losing the ability to ship. We cover the account transfer process itself in our guide to choosing a mobile app development agency.
2. Which changes go out over the air, and which need a store build? A good answer names the tooling and explains how a JavaScript-only fix reaches your users without a review, and which kinds of change still have to wait on one.
3. What happens when a native module falls behind the current Expo SDK? Listen for a process: look for a maintained fork, patch the module, or replace it, and tell you in writing before the upgrade stalls.
4. How quickly do you respond when production breaks, and who covers when the lead engineer is out? You want a response commitment you can hold them to and more than one person who can ship a build.
5. What arrives in writing each month? Named deliverables, like a summary you could forward to a cofounder or a board member, are worth more than a promise of “ongoing support”.

If you’re still deciding who should look after your app, our post on React Native consulting covers the hiring questions in more depth. When you’re ready to measure a real offer against everything above, our existing products page describes how we run retained engineering, with mobile development as one of the service areas alongside bug fixes, dependency updates, code reviews, deployments and rollbacks, and monitoring, all reported in a weekly update. Or book an intro call and bring your current React Native and Expo versions, which is enough for a first conversation about where your app stands.