What does app maintenance include after launch?

Key points

• An app that nobody touches does not stay the same. The OS, the stores, the libraries and the services it calls all keep moving.
• Both app stores raise their build requirements over time. Fall behind and you cannot ship even an urgent fix until you catch up.
• Third-party SDKs, APIs and AI models are retired on published dates. Track them and migrate before the shutdown.
• Monitoring and crash reporting tell you what is broken before reviews do. On Google Play, stability also affects how visible the app is.
• A backup you have never restored is a hope, not a backup. Test the restore.
• Decide who owns maintenance before launch: someone in-house, a retainer with a team, or help as needed.

Why a finished app still needs work

Launch is the start of the app’s life, not the end of the work. The code you shipped stays the same, but almost everything it depends on changes: new versions of iOS and Android, new app store rules, security fixes in the libraries inside it, and changes to every outside service it calls. Left alone, an app slowly falls out of step, first in small ways and then in ways users notice.

Security updates and dependencies

Most of the code in a modern app is not written by its team. It comes from libraries and SDKs, which come from other libraries in turn. When a vulnerability is found in one of them, the fix only reaches your users when someone updates it and ships a release. OWASP’s current Top 10 lists software supply chain failures among the leading web application risks, including not tracking the versions of every component, nested ones included, and not patching in a timely, risk-based way.

• Keep an inventory of every component and its version, often as a software bill of materials, and include the ones your dependencies pull in.
• Subscribe to security alerts for those components, or use a tool that scans for known vulnerabilities.
• Remove dependencies you no longer use. Fewer components mean fewer things to patch.
• Upgrade on purpose, starting with security fixes, and plan a migration when a library is no longer maintained.
• Roll out updates in stages where you can, so a bad release reaches fewer people.

Mobile app security best practices covers the rest of the security side.

OS and app store requirement changes

Both stores raise the bar on a published schedule, and both apply it at the moment you upload. That is what catches teams out: an app that has not been updated in a while cannot ship an urgent fix until it first meets the current requirements.

• Google Play’s target API level policy: from August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher. Existing apps must target Android 15 (API level 35) or higher to remain available to new users on newer Android versions; below that, they stop being discoverable to those users, though people who already installed them keep them. Google lets developers request an extension to November 1, 2026.
• Apple’s SDK minimum: from April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK or the matching SDK for other Apple platforms.
• Other store changes arrive between the big ones. Apple has required approved reasons for certain APIs in a privacy manifest, covering third-party SDKs too, and has rotated the server certificate for its push notification service, which the servers sending notifications had to trust to keep them working.

Moving to a new target SDK is rarely just a version number. New OS versions change permissions, background work and privacy rules, so the app needs testing on the new version before release. Apple and Google publish these changes ahead of time on their developer news and policy pages; someone should be reading them. An over-the-air update can ship some fixes between store releases, but it does not change the SDK the app is built with.

Third-party API and AI model deprecations

Every outside service an app calls, from payments and maps to sign-in, analytics and AI, has its own release cycle. Versions are deprecated, then shut down, on dates the provider publishes.

• Google Play Billing Library: by August 31, 2026, all new apps and updates to existing apps must use version 8 or later. Existing apps keep working, but the next update has to move to a supported version first.
• AI models: OpenAI, for example, retires older models and gives each deprecated model or endpoint a shutdown date, after which it is no longer accessible. It tells developers to migrate to the recommended replacement before that date. A replacement model can behave differently, so prompts and outputs need testing again; AI model deprecation walks through it.

Keep a list of every service the app depends on, the version it uses and where that provider announces changes. Make sure the provider’s emails go to an address someone on your side reads, not only to the developer who set the account up.

Monitoring, crash reporting and backups

Crash reporting shows you which crashes happen, on which devices and versions, with enough detail to fix them. On Android it also matters for visibility: Google Play’s Android vitals tracks the user-perceived crash rate and ANR rate, and if an app exceeds a bad behavior threshold, Play may reduce its visibility and show users a warning on the store listing. The backend needs the same care: error rates, slow requests and uptime, with alerts that reach a person. Mobile app crash reporting explains how to set it up.

Backups are only useful if they restore. The UK’s National Cyber Security Centre advises backing up all the data the business needs to operate, knowing how to restore it and checking that the backup holds what you need, keeping a backup device disconnected when it is not in use, and protecting online backups with two-step verification.

1. List what must be backed up: the database, uploaded files, configuration and anything else the app cannot be rebuilt without.
2. Restore a recent backup into a separate environment, not production.
3. Check that the app runs against it and that recent records are there.
4. Write down the steps, so someone other than the person who set it up can repeat them.
5. Repeat the test on a schedule you set, and after any change to how data is stored.

Small fixes, performance and new features

Maintenance keeps the app you have working. New features change what the app does. Mixing the two in one bucket is how maintenance gets skipped: features are more visible, so they win every argument for attention.

Performance sits in between. Fixing a slow screen that users already complain about is maintenance; redesigning a flow to be faster is product work. Either way, measure first, so the work goes where users feel it. Postponed maintenance does not disappear; it turns into technical debt that makes every later change slower.

Who does it, and how to plan for it

1. Before launch, name the person or team responsible for maintenance, and put it in writing.
2. Keep the repository, store accounts, cloud and third-party accounts in your company’s name, so whoever maintains the app can be given access and changed later.
3. Keep a dependency list: libraries, SDKs, outside APIs and AI models, with the versions in use.
4. Put known deadlines in a shared calendar: store requirement dates and announced retirements.
5. Set up crash reporting, error monitoring and alerts, and agree who responds.
6. Test a backup restore, and repeat it on a schedule.
7. Review all of the above regularly, and keep a small, steady share of engineering effort for upkeep rather than waiting for a deadline.

At BYD Tech the code lives in the client’s GitHub from day one, and AI-assisted work is reviewed by an engineer before it ships. We price by the project or by the week, never by the hour, with a written estimate after scoping. Mobile app development covers how we build apps.