Mobile App Maintenance Services: Keeping an App Shippable After Launch

Updated November 2026 · Written and maintained by the Progression Agency strategy team

An app can work perfectly for a year and still be unable to ship a one line fix. Google Play has required new apps and updates to target Android 16 since August 31, 2026, and Apple has required uploads built with Xcode 26 since April 28, 2026. Mobile app maintenance services keep an app ahead of those dates, along with crash fixes, library updates and store reviews, so the next urgent change can go out the day it is needed. Progression’s team is based in New York and maintains iOS and Android apps for businesses across the US, including apps another developer built.

The one line fix the store would not take

A hypothetical retail app shipped in spring and has not been touched since. In September someone needs to change a phone number on the contact screen, a change that takes a minute to type. The upload is refused.

The refusal has nothing to do with the phone number. The project still targets an older API level and was built with an older Xcode, and each store has since raised its minimum. Maintenance is what keeps the next small change small.

Why does a finished app need work?

Because the ground under it moves. Phones get new operating systems, stores raise their build rules, libraries release security fixes and certificates reach their renewal dates. An app that ignores all of that keeps running for current users and quietly becomes impossible to update.

What mobile app maintenance services cover

The work falls into four kinds, and a plan names all of them. Corrective work fixes crashes and bugs. Adaptive work follows the platforms: new operating system versions, SDK and API level rules, and new device sizes.

Preventive work updates libraries and dependencies, applies security patches and renews certificates and keys before they lapse. Perfective work makes small improvements that reviews and analytics point to. For platform detail, see iOS app development and Android app development.

• Corrective: crashes, bugs and broken flows found by users or reports.
• Adaptive: new OS versions, SDK and API level rules, new screen sizes.
• Preventive: library updates, security patches, certificate and key renewals.
• Perfective: small improvements taken from reviews and analytics.

Which kind of work does an app need most?

In a first year after launch, adaptive and corrective work dominate. Later, preventive work grows because libraries age. Perfective work stays small by design; anything bigger is scoped as its own project.

Two store rules that move every year

Each store sets a minimum for what a build must be made with. The rules in force now are below, and the plain advice is to put both requirement pages on the calendar and schedule the SDK or API level work months before each date, not weeks.

Google Play’s target API level

Since August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play. Wear OS and Android Automotive OS apps need Android 15 (API level 35) and Android TV and Android XR apps need Android 14 (API level 34). See Google Play’s target API level page for the current wording.

Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running a newer Android than the app’s target. Apps that target lower levels are only available on devices running the same or a lower Android version. Google offered an extension to November 1, 2026, and that window has closed, so the plan treats the level as a fixed requirement.

Apple’s minimum Xcode and SDK for uploads

Since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26. Apple’s Upcoming Requirements page also lists earlier minimums, such as Xcode 15 for iOS 17 from April 29, 2024, which shows how the rule moves every year.

A maintenance year on one calendar

The table puts the recurring work in order across twelve months. Triggers that depend on an outside date, such as a new OS release, sit beside the fixed months so nothing waits for a surprise.

• Put both stores’ requirement pages on a shared calendar with named owners.
• Raise the SDK or API level at least a quarter before its date.
• Keep a list of third party libraries and who watches their releases.
• Record every renewal date the day an account or key is created.

What happens in the quiet months?

The monthly triage and the quarterly updates still run. A quiet month is the cheapest time to do the work a busy month would force into a hurry.

Support tiers after launch

App maintenance and support comes in three shapes, and the tier follows what an hour of downtime costs the business, not the size of the code. A quiet brochure app and a booking app of the same size need different levels of cover.

No response time appears on this page, because a target only means something when it is written into a contract for a specific app. The proposal sets it.

• Pick the tier from the cost of an hour of downtime.
• Ask for response targets in writing, not on a web page.
• Move up a tier before a seasonal peak, then back down.
• Review the tier once a year against the logs.

Can the tier change later?

Yes. Tiers are reviewed against how often the app actually needed help, and the proposal says when and how a change is made.

Taking over an app another developer built

Many maintenance clients arrive with an app they did not write. The first paid task is a build and an audit, not a feature, and it starts with five things in your hands.

• The full codebase and every build script.
• Signing keys and certificates, stored where you control them.
• Store accounts in the business’s own name.
• Accounts for third party services: analytics, push, payments, maps.
• A build from a clean machine before any change is made.

Only a clean build proves the project can be rebuilt without the original developer’s laptop. The audit that follows lists what is out of date and what will block the next store upload. Adding people to a team is a separate matter, covered by hire app developers.

Who should own the store accounts?

The business. An app published under a former developer’s account is hard to move and easy to lose, and the fix is a transfer done before anything else changes.

Pricing mobile app maintenance

Pricing depends on scope, is subject to change and is set in the written proposal. Store and developer program fees are set by Apple and Google and sit outside any agency fee.

For the full guide to what apps cost, see app development cost.

• Ask which tier the proposal assumes and what it includes.
• Ask what counts as a fix and what counts as a new feature.
• Ask who pays for store accounts and third party services.
• Ask how unused hours in an allotment are handled.

When apps maintenance turns into a rebuild

Apps maintenance across a portfolio shows a pattern: some apps stay healthy for years, and some reach a point where each update breaks something else. Three signs point toward a rebuild.

• The framework or toolkit is past its support window.
• The original language is no longer accepted by the stores.
• Every update breaks at least two features.

The plain advice: put a written comparison of another year of maintenance against a rebuild on the table before buying either. For a rebuild on one codebase, see cross-platform app development.

How do you compare the two options?

List what each year of maintenance has delivered, what it has blocked, and what the rebuild would deliver in the same period. The comparison is arithmetic on your own history, not an industry rule.

Mobile application maintenance for apps that take payments

An app that takes money carries extra upkeep. In-app purchase and payment libraries get updates, receipts and subscriptions need checks, and each store’s policy needs a review before a release goes out.

• Update payment and in-app purchase libraries on a fixed schedule.
• Check receipt and subscription handling after every OS release.
• Review store policy changes before each submission.
• Test a real purchase path on a device before shipping.

Payment features added later are scoped as their own project; the app development agency page explains how new builds are scoped.

Which release needs the most care?

The first release after an operating system update, since payment sheets and permissions are the places where a new OS tends to change behavior.

A monthly note on store dates and fixes

App maintenance is easier to trust when it is visible. A one page note each month lists what was fixed and what is coming, so the owner never learns about a store date from a refused upload.

• Crash and review summary for the month.
• Updates shipped and what each changed.
• Store requirement dates ahead.
• Open risks that could block an upload.

Who reads the note?

The app’s owner and one technical contact, so a decision and the person who can act on it see the same page.

Crash reports and reviews: the monthly triage

Most bad reviews trace to a handful of crashes and broken flows. A monthly pass through crash reports and recent reviews sorts them into fix now, fix next release and watch.

Maintenance removes the crashes and broken flows behind most low ratings. It does not promise a rating, because ratings depend on far more than stability.

What do reviews tell you that crash reports do not?

Reasons. A crash report says where the app failed. A review says what the person was trying to do.

Renewals that lapse without warning

Certificates, push keys, store accounts and third party subscriptions carry renewal dates, and a lapse often looks like a mystery bug. Notifications stop arriving, a build will not sign or an upload is refused.

• Record each renewal date and the person who owns it.
• Set reminders well before the date, not on it.
• Keep renewal emails going to a shared inbox, not one person.
• Test notifications and sign in after every renewal.

These renewals are the cheapest part of maintenance and the most embarrassing to miss. They also tie back to the handover document, which lists where each key and account lives.

Where do the keys live?

In a store the business controls, with at least two people able to reach it. A key held by one former developer is a single point of failure.

Frequently asked questions