App maintenance after launch: what needs looking after, and when

The short answer

After launch an app needs ongoing care: updates for new phone operating systems, upgrades to the libraries it depends on, security fixes, monitoring, server upkeep, store policy changes and user support. Plan the work as a regular routine with a named owner and budget it as part of owning the app, not as a surprise.

Why an unchanged app still needs work

An app is not like a printed brochure. It runs on devices whose software changes every year, it uses code written by others that gets updated, and it connects to servers and services that can change or close. Even if you add no features, the world around the app moves.

The result is that a finished app, left alone, slowly stops fitting. A screen may look wrong on a new phone, a login service may retire an old method, or a store may require a newer setting before it accepts updates. Maintenance is the work of keeping pace so that users never notice.

The main kinds of maintenance

Separate these from new feature work in your planning. Features add value, but maintenance protects what is already there, and it is often the work that gets dropped when time is short.

Phones and operating systems

Apple and Google release major operating system versions regularly, usually with developer previews months ahead. Each can change how permissions, notifications, background work or layouts behave. Ask your developer to test the app on the new versions during the preview period, not after users have upgraded.

The stores also change what they require from developers, for example the minimum software version used to build an app, or the information they ask for in listings. These requirements have deadlines, and missing one can block new releases. Subscribe to the developer news from Apple and Google, and check the current documentation when a notice arrives. Reasons updates get turned away are summarised in why apps get rejected.

Dependencies, security and the back end

Most apps contain libraries from other authors, and each has its own updates and its own security fixes. A dependency left untouched for years becomes harder to upgrade, and may contain known weaknesses. Schedule regular reviews, and update in small steps. The basics are in mobile app security basics.

The same applies to what sits behind the app. Servers, databases, certificates, domain names and third-party services all have renewal dates and versions. Our guide to what an app backend does explains why neglecting it can break every copy of the app at once. List every service the app depends on, with the account owner, renewal date and what happens if it lapses; APIs and third-party integrations shows why each is a dependency to track.

Monitoring, support and feedback

Someone needs to watch crash reports and store reviews and answer users. Set up a crash tool as described in crash reporting and monitoring basics, and review analytics regularly using what to track as a guide.

Reply to reviews politely and specifically. A rating can often be lifted by fixing the issue and saying so. Make sure there is a working support email or form, and that someone reads it. For more on reviews, see how to get app reviews and ratings.

Releases, versioning and ownership

Plan releases on a rhythm rather than ad hoc: a regular maintenance release, plus urgent fixes when needed. Each release needs testing, a version number, release notes and store submission, as explained in app updates and versioning. For larger changes, run a short beta first using TestFlight or Google Play testing tracks; see app beta testing explained.

Make sure the business owns the essentials: the developer accounts with each store, the source code, signing keys and certificates, server and domain logins, and third-party accounts. If these sit in a former developer's name, you can be locked out of your own app. Keep documentation current so another team could take over.

When to rebuild instead of patch

Sometimes maintenance stops being the sensible answer. Signs that a rebuild deserves discussion include:

• Key libraries are no longer supported and cannot be upgraded without changing large parts of the app.
• Each small change takes far longer than it used to, because the code is hard to understand.
• The app can no longer meet a store requirement without major rework.
• The original design no longer fits the business or its customers.
• Developers who know the code are no longer available.

A rebuild is a large decision, so ask for an assessment first. A good review lists what can be kept, what must change and the risks of each path. Compare it with the cost of continuing to patch, in both money and delay. Do not rebuild only because the app looks old; a clear refresh of the interface may be enough.

A simple maintenance calendar

• Weekly: check crash reports, new reviews and support messages.
• Monthly: review analytics, check server health and backups, and look at dependency alerts.
• Quarterly: update libraries, run a full test on current phones, review the store listing and privacy declarations, and check renewal dates.
• Yearly: test on the new major operating systems, review the security approach and re-examine whether the app still fits the business.

Decide up front who does this: an in-house developer, the original agency or a maintenance agreement. Ask what the response time is for urgent faults and what is included. If you build a cross-platform app, remember that some dependencies come from the framework itself; see cross-platform app development. For help planning and carrying out maintenance, see our mobile app development service.

Related guides

• Mobile app development
• App Crash Reporting and Monitoring Basics
• Cross-Platform App Development: Pros and Cons
• How to test a mobile app before launch
• Mobile app development process from idea to launch
• Ecommerce website vs mobile app for your store

Questions and answers

Does an app need maintenance if I add no features?

Yes. Phones, store rules, libraries and servers keep changing. Without updates the app can break on new devices, fall behind store requirements or carry known security weaknesses.

What should be in an app maintenance plan?

Monitoring and fixes, operating system compatibility, dependency and security updates, server and service upkeep, store requirement changes, user support and a release routine. Add a named owner and response times for urgent faults.

How often should an app be updated?

There is no single rule. Many apps have a regular maintenance release plus urgent fixes when needed, and a review each time a major phone operating system is released.

Who should own the developer accounts?

The business. Register the store developer accounts, domain and server logins in the company's name and add developers as users, so you are not locked out if a supplier changes.

What happens if I stop maintaining the app?

It may stop working on new phones, fall below store requirements or be removed from the stores, and security weaknesses may go unfixed. If you plan to retire an app, tell users and handle their data properly.