Mobile apps

App maintenance after launch

Bug icon, circular update arrows and a shield with a check mark

An app has been running for a year without a single change, and everyone is happy with it. Then a new version of iOS comes out and some customers start complaining about a screen that gets cut off or a button that does nothing. Or the team tries to publish a small fix on Google Play and the store rejects it because the app targets an old version of Android. Apps run on operating systems that change every year, and an app nobody maintains falls behind them.

Why does an app need maintenance if it already works?

Because everything around it keeps changing. Apple and Google each release a major new version of their operating system roughly once a year, and each one brings new behavior for permissions, notifications and background activity. The libraries the app was built with, such as payment and map libraries, ship security updates and drop support for old versions. The servers and databases behind the app also need updates, backups and monitoring.

What do Google Play and Apple require for app updates?

Google Play requires new apps and updates to target a recent version of Android, and it raises that bar on a regular schedule. Right now, from August 31, 2026, new apps and updates must target Android 16. An existing app that falls far behind the requirement stops appearing for new users whose phones run a newer Android version than the one the app targets.

Apple also raises, from time to time, the minimum version of the development tools that any app or update sent to the App Store must be built with. In both cases the outcome is the same. An app that hasn't been updated in a long while may need a lot of work before you can publish any change to it, even a typo fix. Small, regular updates cost far less than one large overdue update.

  1. Beta releasesTest the app on beta versions of the operating systems
  2. New OS releaseReview screens, permissions and notifications
  3. Library updatesPayments, maps, notifications and analytics
  4. Store requirementsTarget version and required build tools
  5. Update publishedTesting and review, then a staged rollout
The maintenance cycle that repeats roughly every year

What does an app maintenance contract cover?

  • Compatibility updates for new iOS and Android versions and for both stores' requirements.
  • Bug fixes, with a written response time for urgent and non-urgent issues.
  • Updates to libraries and dependencies, especially anything related to security and payments.
  • Server monitoring, backups and certificate renewals.
  • A number of hours for small changes per month or per year.
  • Renewing the yearly Apple Developer account on time.

Anything outside the contract, such as large new features, should be priced separately so it doesn't get mixed up with maintenance.

How do you find a problem before customers complain?

Use crash reporting inside the app, such as Firebase Crashlytics, which sends a report for every crash along with the device model and OS version. Add server monitoring that alerts you when responses slow down or stop. Read the reviews in both stores every week, because many problems show up there first. A sudden jump in crashes after an OS update is the first sign that something needs fixing, and knowing which devices are affected cuts down the time it takes to find the cause.

What about users who never update the app?

There will always be people who stay on an old version. The app needs a way to ask for an update when one becomes necessary, and a backend that can serve at least two versions at once without breaking either of them. Set a minimum iOS and Android version that you support, and review it every year based on the devices your customers really use.

How do you estimate a yearly app maintenance budget?

It depends more on the size of the app and the number of systems it connects to than on how many screens it has. An app that talks to a payment gateway, an accounting system and a maps service has more points that can change, and each of them needs watching. The number of users affects the cost of servers and monitoring.

The arrangement we find clearest for both sides is a fixed yearly fee that covers compatibility, monitoring and bug fixes, plus an agreed hourly rate for other changes. Ask your provider to tell you in advance about changes they know are coming, such as the date of a new Google Play requirement, so you can plan for them instead of being caught off guard.

What should you own as the app's owner?

You should have the source code in a repository you can access, App Store and Google Play accounts in your company's name, the accounts for servers and cloud services, the app signing keys, and short documentation that explains how the app is built and published. With these in hand you can move maintenance to any provider without starting from scratch. If the app runs on servers we manage, that falls under our hosting and server service.

When you work out the app's budget at the start, put yearly maintenance next to the build cost, as we explain in what drives the cost of building an app.

We maintain apps we built and apps other teams built, as part of our mobile app development service. Send us your app's store name and the date of its last update, and we'll tell you what it needs to stay compatible.

Questions our partners ask

Will my app stop working if I don't update it?

Usually not right away. Over time, though, compatibility problems show up on newer operating systems, Google Play stops showing the app to people on newer Android versions if it misses the target level requirement, and you won't be able to publish any update until the build tools are brought up to date.

What should an app maintenance contract include?

Compatibility updates for new iOS and Android versions, bug fixes with a stated response time, server monitoring, library updates, and a set number of hours for small changes. Ask for all of it in writing.

Can I move my app's maintenance to another company?

Yes, as long as you own the source code, the store accounts, the servers and the signing keys, along with documentation that explains how the app is built and published.

Written by the Visual Innovate team, the people who build, host and follow up systems, websites and apps for our clients in Jordan, Saudi Arabia, Oman and Egypt.

Are you our next Success Partner?

Tell us the problem as you see it. Within one working day we'll come back with how we understand it and a clear first step.