Why working apps stop working
An app that runs perfectly today can develop problems without a single change to its code. The phone around it changes: a new operating system version alters how permissions work, a new device has a different screen shape, a library you depend on stops being maintained. This is normal, and the aim is not to prevent change but to notice it early and respond in a measured way.
What tends to change
The details vary by platform and year, but the types of change are fairly predictable:
- Permissions and privacy rules. New versions often tighten how apps may use location, notifications, photos, background activity or tracking. Behavior you relied on may require a new prompt or may be limited.
- Interface and display. New screen sizes, cutouts, rounded corners, gesture navigation and display modes can make a fixed layout look wrong. System-wide dark mode and text-size settings are further examples.
- Background behavior. Systems regularly become stricter about what an app may do when it is not in use, mostly to protect battery life.
- Deprecated and removed features. Older programming interfaces are marked as deprecated for a time and eventually removed.
- Store requirements. The stores themselves occasionally require apps to target a recent version of the operating system, and apps that do not may become harder to find or update. Check each store’s developer pages for current rules.
Test early, not on release day
Both major platforms typically publish preview or beta versions of the next operating system months before the public release. If you can spare a spare device, or use an emulator or simulator, install the preview and run through your app’s main paths. You are looking for crashes, layout problems, broken sign-in, and prompts that behave differently.
You do not need to test everything. Choose the five or ten things users do most often, write them down as a checklist, and repeat it each cycle. Over time you can add to it. This sits alongside regular app testing tools and your beta testing group, who may be willing to try a preview build too.
Read the release notes meant for developers
Platform makers publish notes about behavior changes and deprecations. Reading them takes some time, but you only need to look for what touches your app. If your app uses push notifications, check the notification section. If it uses the camera, check the camera permission and capture sections. Make a list of anything you are unsure about and test those items first.
Keep your own dependencies healthy
Many compatibility problems come from the libraries and tools your app uses, not from your own code. Good habits include:
- Use version control so you can try an update on a branch and undo it if it fails.
- Update dependencies regularly in small steps instead of rarely in a big jump.
- Note which libraries are no longer maintained, and plan to replace them before they cause a crisis.
- Keep your development tools reasonably current, since new store submissions may require recent ones.
If you use a no-code builder or a cross-platform framework, you depend on its maintainers to adapt to new operating system versions. That is a trade-off worth knowing in advance. Check how quickly the tool you use has historically supported new releases.
Decide which versions to support
You cannot support every version forever. Each older version you keep adds testing effort and limits the newer features you can use. Platform dashboards and your own usage data can show what versions your users actually run; if you collect usage analytics, the operating system version is a reasonable thing to include since it does not identify a person. Raise your minimum supported version carefully, because some users have older phones and may not be able to upgrade. Dropping them is sometimes justified, but it should be a choice made knowingly, and it is kind to announce it in advance in your release notes.
It is also wise to test on older and smaller phones occasionally. Compatibility is not only about the newest software; it also covers the long tail of devices people still use.
Ship updates with care
When a compatibility fix is needed, release it promptly but not recklessly. A small, focused update is easier to verify than a large one. Use a gradual rollout if the store offers it, and watch crash reports for the first few days. The article on handling app updates without breaking things covers this in more detail.
Tell users what you are doing
You do not have to write a long essay. A line such as “Improved compatibility with the latest operating system version” is honest, though more specific notes are better when you can manage them. If a feature is temporarily unavailable on a new version, say so in the app or the listing instead of leaving people to guess.
A yearly rhythm
A simple pattern for a small app:
- When the preview appears, read the developer notes and install it on a test device.
- Run your checklist and fix what breaks.
- Update dependencies and tools.
- Submit an update before or soon after the public release.
- Review which versions you support.
None of this guarantees a trouble-free year, since new phones do sometimes surprise developers. But a regular routine turns surprises into manageable tasks.