Every app needs upkeep after launch: updates for new phone operating systems and app store rules, security patches for the code libraries it is built on, hosting and monitoring for the server side, repairs when a connected service changes, and fixes for the bugs real users find. Agree who does what, how quickly, and how it is paid for before launch, in writing. An app with no maintenance plan does not stay the same. It slowly stops working.
Owners are often surprised by this. The building work is finished, the app does what it should, so why would it need more? Because the world around it keeps moving. The phones update, the stores change their rules, the services it connects to release new versions, and the people using it find things nobody tested. This guide explains what that upkeep involves so you can plan and budget for it from the start.
Why apps do not stay finished
- Phone operating systems change. Apple and Google each ship a major release of iOS and Android roughly once a year, plus security updates in between. Features change behaviour, permissions tighten, and older code paths are retired.
- App store rules move. Google Play requires apps to target a recent Android version, and the bar rises each year; apps that fall behind can become unavailable to new users on newer devices. Apple periodically requires apps to be built with recent versions of its development tools before updates can be submitted.
- The building blocks get patched. Most apps are built on open-source libraries and frameworks. When a security flaw is found in one, the fix has to be applied, tested and shipped.
- Connected services change. Payment providers, calendars, CRMs and mapping services release new versions of their interfaces and retire old ones on a schedule.
- Browsers change too. Web apps need checking against new browser versions, though far less often than phone apps break.
- Users find things. Real people on real devices do things no test plan imagined.
The four kinds of maintenance
| Type | What it is | Example |
|---|---|---|
| Corrective | Fixing bugs | The booking screen freezes on one model of tablet |
| Adaptive | Keeping up with changes outside the app | A new iOS release changes how notification permissions work |
| Preventive | Work that stops problems before they happen | Updating libraries, renewing certificates, testing backups |
| Perfective | Improvements based on how people use the app | Adding a filter that staff keep asking for |
The first three keep the app running. The fourth makes it better. Budget for both, separately, so improvements do not get starved by upkeep or the other way round.
A maintenance calendar
Every month
- Review crash reports and error logs.
- Apply security updates to libraries and the server.
- Check that backups ran, and restore one to prove they work.
- Review the support requests and bug reports that came in.
Every year
- Test the app against the new iOS and Android releases, ideally on the beta versions before they reach the public.
- Meet the new Google Play target version and any Apple build requirements.
- Renew the Apple developer programme membership, which is annual, and check the Google Play developer account is in good standing.
- Renew domains, and confirm security certificates renew automatically. Certificate lifetimes are getting shorter, so manual renewal is a risk.
- Update the privacy information in the app store listings if what the app collects has changed.
- Review who has admin access to everything, and remove anyone who has left.
Whenever a connected service announces a change
- Read the notice, note the retirement date, and schedule the work well before it.
Hosting and the server side
Most apps have a part you never see: the server that stores data, handles sign-in and talks to other systems. It needs hosting, monitoring that alerts someone when it fails, backups, logs and occasional upgrades of its own. Hosting costs usually grow with use, so a successful app costs more to run than a quiet one. Decide who holds the hosting account and who receives the alerts. At FiberX, ownership, licensing and hosting are set out in the agreement before work starts, so this is settled before launch rather than discovered after.
What belongs in the support agreement
Whoever maintains your app, get these points in writing:
- Scope: which apps, platforms and servers are covered.
- Severity levels and response targets: how quickly each kind of problem is acknowledged and worked on.
- Bug or change request: how the two are told apart, since one is usually covered and the other is usually new work.
- How work is paid for: a set amount of time each month, work quoted as it comes up, or a mix.
- Operating system updates: whether the yearly iOS and Android work is included.
- Accounts: developer accounts, domains, hosting and the code repository, and whose name each is in.
- Documentation: how to build, deploy and restore the app, kept up to date.
- Security incidents: who is told, how fast, and what happens next.
- Exit: what you receive if you change developers, and how the handover works.
| Severity | Example | What to agree |
|---|---|---|
| Critical | App down, nobody can sign in, payments failing | The fastest response, including outside office hours if the app is customer-facing |
| High | A core feature broken for many users | Work starts promptly, with regular updates |
| Medium | A problem with a workaround | Fixed in the next planned update |
| Low | Cosmetic issues, wording | Batched into routine releases |
A worked example
Hypothetical: the business and the hours are invented to show how a year of upkeep adds up. Real effort depends on the app.
A physiotherapy group with six clinics runs a booking app on iOS and Android, a web version, and a small server that connects to its calendar system and payment provider. Its first year after launch plans out like this:
- Monthly preventive work (updates, log review, backup test): 4 hours a month, 48 hours a year.
- Yearly operating system release (testing on betas, fixes, resubmission to both stores): 20 hours.
- Payment provider interface change announced mid-year: 10 hours.
- Bug fixes reported by staff and patients: about 2 hours a month, 24 hours a year.
- Improvements requested by clinic managers: 40 hours, chosen from a list.
That is 102 hours to keep the app running and 40 to make it better, 142 in total. The useful part is not the total. It is that roughly two thirds of the effort was upkeep the group did not choose, and would have happened whether or not anyone planned for it. Planning means it happens on a schedule, not during a Monday morning outage.
Signs an app is not being looked after
- Emails from Apple or Google about deadlines that nobody acts on.
- Crash reports that nobody reads.
- Nobody can say who holds the hosting login or the developer account.
- Libraries several major versions behind.
- Store ratings slipping, with reviews mentioning the same bug.
- Simple changes taking weeks because nobody remembers how the app is built.
Inheriting an app someone else built
Plenty of businesses arrive at this question because the original developer has moved on. Before anyone promises to maintain an inherited app, the first job is an audit, and it is worth asking for one as a separate, small piece of work:
- Get the code. All of it, including the server side, in a repository you control. An app store listing is not the code.
- Prove it builds. A developer should be able to take that code and produce a working version of the app from scratch. If they cannot, something is missing.
- Find every account: Apple and Google developer accounts, hosting, domain, email sending, payment provider, analytics and any paid services the app depends on. Move each one into the business's name.
- List the dependencies and how far behind current versions they are. That list is the first year's preventive work.
- Check the deadlines. Store requirements, interface retirements and certificate expiries that are already close.
The audit tells you whether the app is worth maintaining as it is, needs a period of catch-up work, or would be cheaper to rebuild in stages. All three are legitimate answers, and a developer who gives one before looking at the code is guessing. The same thinking about when to keep, replace or build around software appears in custom software vs off-the-shelf.
Questions to ask your developer
- What does ongoing support cover, and what counts as new work?
- Is the yearly iOS and Android update work included?
- What are the response targets for each severity level, including nights and weekends?
- Whose name are the developer accounts, domain, hosting and code repository in?
- How are security updates to libraries handled, and how often?
- How are backups tested, and how long would a full restore take?
- If we part ways, what do we receive and how does the handover work?
Our guide to what drives the cost of a business app covers how these running items sit next to the build cost, and native vs cross-platform vs web apps explains why the platform choice changes how much yearly upkeep there is. If the app holds sensitive data, the network around it matters too; see our cybersecurity page.
How FiberX handles it
Our App Development service builds mobile apps for iOS and Android, web apps, internal dashboards, customer portals and booking apps, and looks after them once they are live. Support is the fifth step of every project: fixes, updates and new features after launch, on terms set out in your agreement and agreed up front. The specifics of your app, including platforms, timelines and support terms, are confirmed in your consultation, and you get a written estimate before you commit to anything. Phil Morales is your point of contact from the first call through launch and support. The consultation is free with no obligation. Book a time, call 478-758-8091 or text (347) 870-0965, and we usually reply the same day.
