What are mobile app maintenance services?
Mobile app maintenance services are the planned, ongoing work that keeps a live app available in the stores, working on current phones, secure and connected to its back end. They start the day after launch and never really end while the app has users.
It helps to think of an app in five layers, because each layer ages at a different speed. The platform layer is Android and iOS themselves, which release a major version every year. The store layer is Google Play and the App Store, whose technical and policy rules change on their own calendar. The dependency layer is the framework (Flutter, React Native or native) and the dozens of libraries the app pulls in. The backend layer is your server, database and the third-party APIs you call. The product layer is the screens and features your users see.
Good mobile app maintenance services watch all five. Poor ones only react to the product layer (“the button is broken”) and discover the others when an update is rejected or a payment SDK stops working.
- Platform: yearly Android and iOS releases and their behaviour changes
- Store: target API rules, SDK minimums, privacy forms, policy updates
- Dependencies: framework versions, libraries, SDKs
- Backend: servers, databases, third-party APIs, certificates
- Product: bugs, small changes, content updates
Why does an app stop working when nobody changed it?
Because everything around it changed. An app is compiled against specific versions of Android, iOS and many libraries, and it talks to servers and APIs that keep evolving. When any of those moves, an untouched app can start crashing, lose features or be blocked from updating.
The typical failures we see in neglected apps follow a pattern. A new Android version changes how background tasks or notifications work, and reminders stop arriving. Apple raises the minimum Xcode version, and the next urgent fix cannot be uploaded until the whole project is updated. A payment or login SDK retires an old API version, and checkout or sign-in fails. A server’s SSL certificate expires, and every API call fails at once. An old library carries a known security flaw that a store scan flags.
None of these is anyone’s fault. They are the normal cost of running software on platforms owned by other companies. Mobile app maintenance services exist to spread that cost into small, planned steps rather than a panicked rebuild when three problems land in the same week.
Android updates: the yearly target API cycle in mobile app maintenance services
Every year Google Play raises the minimum target API level for new apps and updates, and every Android maintenance plan has to budget for it. Android’s developer documentation sets the current rule: from 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher.
Existing apps face a softer but still serious rule. They must target at least Android 15 (API level 35) to stay available to new users on devices running newer Android versions; apps targeting older levels become invisible to those users. Developers who need more time can request an extension to 1 November 2026 through Play Console.
Raising the target is rarely a one-line change. Each Android version tightens rules on permissions, background work, notifications, file access and how the app is drawn on screen. The work is to raise the target in a branch, read Google’s behaviour-change notes for the new version, test the flows most likely to break (login, notifications, uploads, payments, location), fix what fails, and ship through a staged rollout.
Android also reports stability through Android vitals, and apps above Google’s crash or ANR thresholds may lose visibility on Google Play. That makes crash monitoring part of Android maintenance, not an optional extra.
iOS updates: Xcode, SDK minimums and Apple’s other deadlines
Apple sets a minimum Xcode and SDK version for every upload, and an app that falls behind cannot ship even a one-line fix until it catches up. Apple’s developer news page states that from 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK such as iOS 26.
Apple lists other requirements on the same page. From 9 September 2026, iOS and iPadOS apps must target iOS 13 or later. Since May 2024, uploads must include approved reasons for certain “required reason” APIs in a privacy manifest, including APIs used by third-party SDKs. Developers were also asked to answer updated age rating questions by 31 January 2026, or risk interrupted update submissions.
For a Flutter or React Native app, keeping current with Xcode also means keeping the framework current, because older framework versions may not build cleanly with the newest Xcode. This is one of the main reasons mobile app maintenance services for cross-platform apps cannot skip framework upgrades for long.
Membership matters too. Apple’s account help says that if your Apple Developer Program membership expires, your apps are no longer available for download and you cannot submit updates, though existing users can keep using them. The program costs US$99 per membership year, according to Apple’s enrolment page, and renewal should sit in someone’s calendar.
SDK and library upgrades: why skipping them piles up
Library upgrades are cheap when done regularly and expensive when postponed, because each skipped version adds breaking changes that must be handled all at once later. A typical business app depends on a framework plus 20 to 60 libraries for payments, maps, analytics, notifications, images and more.
Take a Flutter app left alone for two years. The Flutter version is several releases behind, so the latest Xcode may refuse to build it. Upgrading Flutter forces upgrades to Firebase plugins, which changed their APIs in between. The maps plugin has been replaced by a different package. The payment SDK’s old version is being retired. What would have been four small upgrades spread over two years becomes a two-week project, all needed before the urgent fix you actually wanted can ship.
React Native apps follow the same story, with the added step of native module compatibility on both platforms. Native Kotlin or Swift apps are less exposed to framework churn but still depend on Google and Apple SDKs that change yearly.
Our rule in mobile app maintenance services is a small upgrade pass every quarter and a larger one timed before each store deadline. We read changelogs before upgrading, upgrade in a branch, run the app through its main flows on real and emulated devices, and only then release.
Upgrade every quarter
Minor library versions, security patches, analytics and crash reporting SDKs.
Upgrade before store deadlines
Framework version, Android target API, Xcode and iOS SDK, payment and login SDKs.
Crash monitoring: how mobile app maintenance services catch problems early
Crash monitoring means collecting crash and freeze reports from real users, grouping them by cause, and fixing the ones that affect the most people first. Without it, you learn about problems from one-star reviews.
There are three main sources. Android vitals in Play Console reports crashes and ANRs (“App isn’t responding” freezes) with stack traces and device breakdowns, and Google may reduce an app’s visibility if its user-perceived crash rate goes above 1.09% or its ANR rate above 0.47% overall. App Store Connect and Xcode’s Organizer report crashes from iOS users who share diagnostics. Firebase Crashlytics works across Android, Apple platforms, Flutter and Unity and adds custom logs and breadcrumbs that show what the user did before the crash.
The process matters more than the tool. Each week, sort issues by users affected, check whether a new release caused a spike, and decide which issues go into the next update. Urgent problems, such as checkout crashing for everyone, get a hotfix. Rare crashes on one old device may wait for the next planned release. How fast we respond to each level is agreed in your written quote, not assumed.
- Crashlytics or an equivalent tool installed in every release
- Symbol files uploaded so stack traces are readable
- Weekly review of top issues by affected users
- Staged rollouts, halted if a new crash appears
Server, API and store costs that sit outside mobile app maintenance services
Most of an app’s running cost is not the maintenance fee but the services it runs on: hosting, database, file storage, SMS or OTP, email, maps, push notifications and any paid APIs. These bills go from each provider to you, and they grow with usage.
Knowing where each bill comes from prevents surprises. A cloud server or managed backend is billed monthly by the provider, and its cost depends on traffic and data. SMS and OTP messages are billed per message by the SMS provider. Maps and location APIs are billed by usage beyond any free allowance. Store accounts have their own fees: Google Play charges a one-time US$25 registration fee, according to Play Console help, and Apple charges US$99 per membership year.
Part of our work in mobile app maintenance services is keeping these bills sensible. We check for runaway usage (a bug that calls an API in a loop can multiply a bill overnight), set budget alerts where the provider supports them, clean up unused resources, and suggest cheaper configurations when usage patterns allow. We never move your accounts into our name to resell them; the bills stay transparent and yours.
Billed to you by providers
Hosting and database, storage, SMS/OTP, email, maps and paid APIs, store developer accounts.
Billed by us
The maintenance plan and any quoted development work, nothing else.
How much do mobile app maintenance services cost per month?
With BtechWaleTech, mobile app maintenance services start at ₹8,000/mo (US$120/mo abroad) after the two free months that come with apps we build. Across the market, quotes vary widely, so compare what each plan actually covers rather than the headline figure.
Four things drive the monthly figure. Platforms: one Android app is simpler than Android plus iOS, even with a shared Flutter or React Native codebase, because each store has its own deadlines and review process. Back end: an app that talks only to Firebase is lighter to maintain than one with a custom server, admin panel and several integrations. SDK count: each payment, maps, chat or video SDK is another thing that can break. Change volume: a plan that includes a few small changes a month costs less than one expecting weekly feature work.
For a yearly budget view, including the common percentage-of-build-cost rule and what it misses, read app maintenance cost in India. For the full list of starting prices across services, see the pricing page.
Monthly plan or pay per fix: which suits your app?
Choose a monthly plan if the app earns money, handles payments or bookings, or has more than a few hundred active users; choose pay-per-fix only for a small app that rarely changes and can survive a few days of breakage. The deciding question is how much an unnoticed problem would cost you.
Pay-per-fix looks cheaper because you pay only when something breaks. The hidden cost is that nobody is watching: deadlines are missed until an update is rejected, crashes are found through reviews, and each fix starts with a developer relearning the code. Emergency work also tends to be the most disruptive, because it cannot wait for a planned release.
A monthly plan turns the same work into a calendar. Deadlines are known months ahead, crashes are reviewed weekly, libraries move in small steps, and the same people know the code. The monthly figure buys attention as much as hours.
Monthly plan fits
Revenue-generating apps, payments or bookings, both stores, a custom back end, several SDKs.
Pay per fix fits
Internal tools, event apps, apps with a handful of users and no payments, apps near retirement.
Taking over an app from the original developer: what you need to recover
To move an app to a new maintenance team you need the source code, the signing credentials, admin access to both store accounts, ownership of the cloud and Firebase projects, and the logins for every third-party service. Missing any one of these can block updates, and some are hard or impossible to recover later.
The most critical item on Android is signing. If the app uses Play App Signing, Google holds the app signing key and the developer holds an upload key; a lost upload key can be reset through a request in Play Console. If an older app manages its own signing key and that key is lost, you cannot publish updates to the same listing. On iOS, certificates and provisioning profiles can be regenerated by whoever controls the Apple Developer account, which is why that account must be in your name, not the developer’s.
Ask for the code as a Git repository with its full history, not a zip file of the latest version. History shows what changed and when, which helps a new team understand why things are the way they are. Ask for any environment files, API keys and server access, and for a short written note on how to build and release.
If the original developer has disappeared, much can still be recovered as long as the store accounts are yours. That situation, and the steps to take, are covered in more detail on our page for when you need a freelance mobile app developer to step in.
- Git repository with full history
- Android upload key or Play App Signing details; iOS signing handled via your Apple account
- Google Play Console and App Store Connect admin access in your name
- Firebase, cloud and database projects owned by your account
- Logins for SMS, email, maps, payment and analytics services
- Build and release notes, however brief
What we check in the first week of taking over an app
Before quoting ongoing mobile app maintenance services for an app someone else built, we run a short audit so the quote reflects reality. It answers three questions: can we build and release it, how far behind is it, and what is most likely to break next.
First, the build. We clone the repository, install the recorded framework and tool versions, and try to produce Android and iOS builds. Failures here are common with older projects and tell us how much catch-up work lies ahead. Second, the gap. We compare the target API level, Xcode requirement, framework version and key SDK versions against what the stores and providers currently require. Third, the risk. We read Android vitals and crash reports, scan dependencies for known vulnerabilities, check how secrets are stored, and look at the back end’s hosting, backups and certificate expiry dates.
The output is a plain-language report and an itemised quote in two parts: catch-up work to bring the app current, and the ongoing plan after that. You decide whether to proceed with either.
Green
Builds cleanly, targets current API levels, few crashes: straight into a monthly plan.
Amber
Builds after fixes, one or two deadlines close: a short catch-up phase first.
Red
Does not build, years behind, critical keys missing: we explain options, including a rebuild from ₹40,000.
Security and data upkeep in mobile app maintenance services
Security maintenance means keeping dependencies patched, secrets out of the app bundle, server software updated and data access limited to what the app needs. Apps rarely get hacked through clever attacks; they get exposed through old libraries, API keys embedded in the app and servers nobody updates.
On the app side, we update libraries with known vulnerabilities, move secret keys from the app code to the server where possible, restrict API keys to your app’s package name or bundle ID, and remove permissions the app no longer uses. On the server side, we apply operating system and framework patches, check that backups run and can be restored, confirm TLS certificates renew automatically, and review who has admin access.
Privacy obligations sit with you as the business, and in India the Digital Personal Data Protection Act, 2023 sets the framework. Our part is technical: collecting only the data the app needs, making deletion possible, keeping logs free of personal data, and keeping the store privacy forms accurate when SDKs change. For legal interpretation, ask your own lawyer.
Store policy upkeep: forms, emails and account renewals
Google Play and the App Store both expect you to keep policy declarations accurate as the app changes, and both send warnings before taking action. Maintenance includes reading those emails and acting on them in time.
On Google Play, the Data safety section must reflect what data the app and its SDKs collect and share. Adding an analytics or advertising SDK can change the answers, and an inaccurate form is a common reason for a rejected update. Play also sends notices about policy changes, target API deadlines and account verification steps. On the App Store, privacy details in App Store Connect and the privacy manifest must stay aligned with the app’s behaviour, and age rating answers must be kept current.
Account housekeeping is part of it. The Apple Developer Program renews yearly, and a lapsed membership removes the app from sale. Store accounts should have more than one admin, all belonging to your business, so a single departed employee or developer cannot lock you out.
If a rejection or suspension has already happened, see app rejected by Google Play or Google Play app suspended.
Where maintenance ends and new development begins
Maintenance keeps the existing app working and makes small changes; new features, redesigns and new integrations are development work quoted separately. Drawing this line in writing avoids arguments later.
Typical maintenance work: compatibility updates, library upgrades, crash fixes, security patches, policy form updates, copy and price changes, replacing an image, adjusting a screen layout, and small bug fixes. Typical development work: a new module such as loyalty points, a new payment method, a chat feature, a redesign of several screens, an admin panel, or a new integration with another system.
A grey zone exists. A library upgrade that forces a screen to be rebuilt, or an API retirement that requires a new integration, starts as maintenance but may need extra time. Our approach is to tell you before starting whenever a task is larger than the plan covers, with a separate quote you can approve or defer. The terms page covers the general rules; anything specific to your plan is written into your quote.
Mobile app maintenance services across India
We maintain apps for businesses in every state, remotely, with the same routine everywhere: a calendar of store deadlines, weekly crash review, planned upgrades and a WhatsApp line for urgent issues. What differs by city is the kind of app and its users.
Hospital and clinic apps in Gwalior and Jabalpur need booking and report downloads that never fail. Tourism apps in Shimla, Srinagar and Panaji see seasonal spikes that test servers. Manufacturing and dealer apps in Faridabad and Aurangabad depend on stable order flows. Education apps in Prayagraj (Allahabad) and Kozhikode need video and test features that work on budget phones. Pilgrimage and service apps in Tirupati handle bursts of bookings around festivals.
Distance makes no difference to the work itself: code lives in your repository, access runs through your accounts, and every release is logged.
Worked example: taking over a salon booking app in Kozhikode (hypothetical)
Say a chain of three salons in Kozhikode has a Flutter booking app built two years ago. The original developer has taken a full-time job and replies slowly. Google Play has emailed about the target API deadline, and customers report that appointment reminders stopped arriving. Here is how the takeover would run. This is an illustration, not a client story.
Week one: the owner confirms that the Play Console and Apple Developer accounts are in the salon’s name. The developer shares the Git repository and says the app uses Play App Signing. The audit finds the Flutter version well behind, Firebase plugins several major versions old, and the target API below the new requirement. Reminders fail because newer Android versions tightened the rules on exact alarms and notifications, which the old code does not handle. The rating is an amber: fixable with a catch-up phase.
Weeks two to four: Flutter and plugins upgraded in steps, notification permissions and scheduling rewritten for current Android and iOS rules, target API raised, the app rebuilt with the Xcode version Apple currently requires, and both versions released through staged rollouts after testing on older phones. Crashlytics is added so problems surface before reviews do.
After that, the salon moves to a monthly plan from ₹8,000/mo: weekly crash review, quarterly library upgrades, deadline planning and small changes such as new service prices. The server and SMS bills stay in the salon’s name, as before.
Mobile app maintenance checklist: monthly, quarterly and yearly
Whether you use our mobile app maintenance services or someone else’s, this is the rhythm that keeps an app out of trouble. Share it with whoever maintains your app and ask which items they already cover.
- Monthly: review top crashes and ANRs by affected users
- Monthly: check server, database and API bills for unusual usage
- Monthly: read and act on every Google Play and Apple policy email
- Quarterly: upgrade minor library versions and security patches
- Quarterly: test backups by restoring one to a test environment
- Quarterly: confirm the Data safety form and privacy details still match the app
- Yearly: raise the Android target API level before Google’s deadline
- Yearly: rebuild with Apple’s required Xcode and SDK version
- Yearly: renew the Apple Developer Program and check domain and certificate expiry
- Always: code in your repository, accounts in your name, at least two admins
Growing installs is a separate job from keeping the app healthy; see how to rank an app on the Play Store and app store optimization services when you are ready for it.