Mobile app maintenance is the regular work that keeps a live app running on new phones and new operating system versions, compliant with app store rules, and free of known security holes. If a website is not maintained, it slows down or looks dated; if a mobile app is not maintained, at some point it stops working or the store makes it invisible. In this article we explain why maintenance is unavoidable and how to plan for it.
Everything changes, even if you touch nothing
Operating system updates. Every year Apple and Google release a new major version of iOS and Android, with many point updates in between. New versions sometimes remove old methods, tighten permission rules or change screen behavior. A feature that worked yesterday may behave differently the day a user's phone updates.
New devices. Different screen sizes, notches, foldable screens... If the app's layout does not adapt, buttons spill off the screen or text becomes unreadable.
Third-party libraries. Apps contain libraries built by other companies (SDKs, or software development kits) for things like maps, payments, notifications and analytics. Old versions of these libraries lose support or need updating because of security vulnerabilities.
The server side. When the server, ERP or payment system the app talks to changes, the app has to adapt too.
App store target version requirements
The most concrete factor that makes maintenance mandatory is app store rules. Under Google Play developer policies, apps must be updated within a set period to "target" a recent version of Android. Apps that do not meet this requirement may not be shown in the store to people using newer Android versions, and publishing new updates may be blocked.
Apple has a similar arrangement. Apple's developer policies periodically require new versions submitted to the store to be built with current development tools. So even a small change to an app that has not been updated in a long time may first require moving the whole foundation onto current tools.
The dates and details of these rules change every year; the current versions should always be followed in Google Play and Apple developer policies. What matters is knowing that this is work you will face at least once a year and putting it in the budget from the start.
The cost of postponing maintenance
Picture an app that has not been updated for two years. The day you want to make a small text change, you may run into:
- Development tools that no longer open the old project
- Libraries whose support has ended and that need to be replaced with new ones
- The store refusing the new version because of the target version requirement
- Accumulated changes triggering one another, turning a small job into a big project
Small, regular maintenance is almost always cheaper and less risky than large, postponed maintenance.
What should a release plan look like?
In a well-run app, releases come out on a set rhythm, not at random:
| Release type | When | Content |
|---|---|---|
| Hotfix | Immediately, when needed | A bug that blocks use, a security vulnerability |
| Maintenance release | Every few months | Library updates, small fixes |
| Annual compatibility release | After new operating system versions | Target version upgrade, testing on the new system |
| Feature release | Planned, based on business needs | New screens and functions |
Beta versions of new iOS and Android releases are usually made available to developers before the official launch. Testing the app during this period is the best way to avoid surprises when users update their phones.
What should maintenance cover?
- Testing and compatibility on new operating system versions
- Tracking and meeting app store target version requirements
- Library and security updates
- Regular monitoring of crash and performance reports
- Keeping app store privacy declarations up to date
- Monitoring the server side and API connections
- Tracking the expiry of app store accounts and certificates
The last item is often forgotten; notification certificates and developer account memberships are renewed at intervals, and when they expire, notifications can silently stop.
How we do it at Globya
In app projects, we do not leave maintenance as something to think about after delivery; we discuss it as a separate, clear line item at the proposal stage. We test live apps on new operating system versions in advance, follow the calendar of store requirements and plan the necessary compatibility releases before you even notice. Since the server and integrations the app talks to are handled by the same team, problems are solved through a single point of contact; we monitor the server side as part of our hosting and maintenance service. We can also review apps built by other companies and take over their maintenance. The general framework is on our mobile app page.
Frequently asked questions
Our app has not been updated for years. Can it still be saved?
Often, yes. We first review the source code and store accounts, then tell you plainly whether updating the existing structure or rewriting it would be more efficient.
We don't have our source code. What can we do?
Even if the app is live in the store, it cannot be updated without the source code. Getting the code from the previous developer is the first step; if that is not possible, redevelopment comes into play. In new projects, we write handover of the source code to you into the contract.
How much budget should we set aside for maintenance?
It depends on the size of the app, the number of integrations and how often it is updated. Pricing follows in a written proposal after we review the app; for information, see our contact page or call +90 850 432 55 13.
The Globya assistant is online 24/7; it answers right away and passes your question to the team if needed.