Keeping a mobile app working after iOS and Android updates

A mobile app keeps working after iOS and Android updates when someone looks after it on a schedule: testing each new OS version while it is still in beta, keeping the SDK, build tools and libraries current, meeting the stores' target requirements before they apply, and shipping small maintenance releases several times a year. The server side matters as much: the API has to keep serving older app versions that people have not updated. An app left alone for a year or two usually still runs, until an OS change breaks a feature or the store stops accepting its updates.

#Why apps break when nothing in them changed

Your app's code may be frozen, but the platform it runs on is not. Apple and Google release a major OS version every year and smaller updates in between, and each one can change behavior your app depends on.

• OS behavior changes. New versions tighten what apps may do in the background, how they start services, how they read files and how notifications are delivered. Code that worked yesterday can silently stop working, for example a background sync that no longer runs.
• Permission changes. Permissions are regularly split, narrowed or made explicit. Recent Android versions turned posting notifications into a permission the user must grant, and both platforms let users share only selected photos or an approximate location. An app that assumes the old, broader access can crash or show empty screens.
• Deprecated and removed APIs. Platform functions are first marked as deprecated and later removed or changed. The warning appears in the build log long before the failure appears on users' phones.
• Store target requirements. Google Play requires new apps and updates to target a recent Android API level, and raises that level on a regular schedule. Apple periodically raises the minimum Xcode and SDK version for uploads and adds requirements such as privacy manifests. Miss one, and the app may keep running for existing users while you are unable to publish any update, including an urgent fix.
• SDK and library updates. Payment, analytics, maps, login and push notification SDKs have their own release cycles and end support for old versions. Cross-platform frameworks such as React Native and Flutter also need upgrading to support new OS versions, and their plugins have to follow.
• New devices and screens. New screen shapes, display cutouts, larger text settings and foldable or tablet layouts expose layout assumptions that held on older phones.

The current requirements change every year, so check the official Google Play and Apple developer documentation for the levels and versions that apply now. Our guide to publishing an app to the App Store and Google Play covers the store side in more detail.

#Testing on beta OS versions

Both platforms publish developer betas of the next major OS version months before the public release. Apple usually announces each new iOS version at its developer conference in early summer and ships it in the autumn. Google publishes Android betas for supported Pixel devices and for the emulator. That window is when compatibility work is cheap.

A sensible beta routine:

1. Read the platform's "what's new" and behavior-change notes for the release and list the items that touch your app: permissions, background work, notifications, storage, networking.
2. Install the beta on at least one test device or simulator per platform. Never put a beta on a phone someone depends on.
3. Run your automated tests and a manual pass through the core flows: sign-up and login, payments, push notifications, camera or file uploads, deep links, and anything that runs in the background.
4. Test with the new target level as well, because some behavior changes apply only once the app targets the new version.
5. Fix and release before the public OS update, so users who update on day one find an app that already works.

Keep a small set of real devices that covers old and new OS versions, and small and large screens. Emulators catch most problems, but not all of them, especially around cameras, notifications and performance.

#A maintenance release rhythm

Apps that stay healthy tend to follow a predictable rhythm instead of waiting for something to break. One workable pattern:

When	What happens
Monthly	Review crash reports and store reviews, apply security patches, update libraries with known issues.
Quarterly	A maintenance release: library and SDK updates, deprecation warnings fixed, a regression test on current devices.
When OS betas appear	Beta testing as described above, then a compatibility release before the public OS launch.
Yearly	Raise the target and minimum OS versions, upgrade the framework, review which old OS versions are still worth supporting.

The exact intervals depend on the app. A banking or health app with many users needs a tighter rhythm than a simple internal tool. What matters is that the work is planned and small. An app that skips two or three years of updates often needs a large, risky upgrade of the framework and every plugin at once, under pressure from a store deadline.

Use crash reporting and analytics to see which OS versions and devices your users actually have. That data tells you when it is safe to drop an old OS version and which devices deserve testing time. If you are still choosing a framework, the upgrade path is one of the factors in our comparison of React Native and Flutter.

#Keeping the API compatible with older app versions

On the web, everyone gets the new version when they reload the page. In mobile, many users run an old version for months, and some never update. Your API has to keep serving all the versions still in use.

• Make changes additive. Add new fields and endpoints. Do not rename or remove fields, or change their meaning, while old app versions still read them.
• Version the API when a breaking change is unavoidable, and keep the old version running until its usage has dropped to a level you have decided you can accept.
• Send the app version with every request, for example in a header, so the server can log it, measure usage per version and adjust behavior where necessary.
• Have a minimum supported version. Build an update prompt into the app from the first release, so you can ask users of very old versions to update, and require it when an old version is unsafe or can no longer work.
• Use feature flags controlled by the server, so a new feature can be switched off without a store release, which takes time.
• Test old app builds against the new API before deploying server changes. Keep the last few released builds available for exactly this purpose.

#Who should own this work

Maintenance falls through the cracks when nobody is responsible for it. Make sure someone has access to the developer accounts, the signing keys, the source code and the build setup, and that they are in your company's name. Agree in writing what maintenance includes: OS compatibility, library updates, store requirement changes and how quickly critical fixes are released.

#How PN Scripts can help

PN Scripts builds iOS and Android apps in React Native, Flutter, Swift and Kotlin, together with the API behind them, and handles store releases. Support and updates continue after launch for as long as the client wants, with the store accounts in the client's name. To plan an app or its upkeep, see our iOS and Android app development page.