App Development
App maintenance and ongoing releases
Apps rot without maintenance: OS updates break features, store rules change, crashes creep in and ratings slide. We keep your app updated, monitored and releasing on a steady rhythm, so launch day is the start, not the peak.
Who it is for: Businesses with a live app and no ongoing developer, or whose agency shipped version one and disappeared.
Everything in this service
- Compatibility updates for each iOS and Android release
- Crash and performance monitoring with alerts
- Dependency and security updates
- Store policy compliance, so the app is never delisted
- A release pipeline for scheduled fixes and features
What to expect
- An app that keeps working through every OS update
- Crashes caught by monitoring, not by one-star reviews
- A steady release rhythm users and stores both reward
How app maintenance actually works
Operating system churn: the clock that never stops
Apple and Google each release a major operating system version every year, with smaller updates throughout. Every one of those releases is a chance for something in your app to change behaviour without you touching a line of code.
The changes that bite are rarely dramatic. A permission that used to be granted once now needs re-requesting. A background capability gets restricted. A system control changes size and your layout breaks around it. A default appearance shifts and your colours no longer have enough contrast. An interface your app relies on is deprecated, works for a while with warnings, then stops. Alongside that, both platforms set minimum build requirements for new submissions, so an app that is not rebuilt against a recent version eventually cannot be updated at all, which turns a routine bug fix into a modernisation project.
The way to stay ahead is to work with the beta cycle rather than the release cycle. Both platforms publish previews months before release, and testing your app against those previews turns a live incident in September into a planned task in July. The cost is a few days a year. The alternative is finding out from reviews, at the worst moment, when a large number of users have just updated at once.
- Test against each platform beta, months before the public release
- Watch deprecation warnings, they are a deadline with a long fuse
- Rebuild against current tooling annually to stay submittable
- Check layout against new system controls and default appearance changes
- Re-verify permissions and background behaviour after every major release
Dependencies and SDKs: the part that ages fastest
A typical app depends on a considerable amount of code written by other people: analytics, crash reporting, payments, authentication, mapping, notifications, plus the framework itself and dozens of smaller libraries. Every one of those is on its own release schedule and its own path to obsolescence.
Left alone, a dependency set decays in predictable ways. Security issues are found and patched upstream, and an app that never updates keeps the flaw. Vendors retire old versions of their services and stop accepting requests from clients that have not upgraded, which can break a live feature on a date decided by someone else. Libraries get abandoned. And the longer you wait, the harder the eventual upgrade, because you are jumping several major versions at once and absorbing every breaking change together rather than one at a time.
Regular small updates are much cheaper than occasional large ones. A monthly or quarterly pass, applied on a branch, run through the test suite and checked on real devices, keeps everything close to current with manageable risk. Pay particular attention to anything with a server component, since those can be retired on the vendor timetable regardless of whether your app is ready, and to anything security related. It is also worth reviewing the dependency list itself once a year, because apps accumulate libraries added for features that no longer exist, and removing one is the cheapest possible maintenance.
- Update on a regular schedule rather than only when something breaks
- Prioritise security patches and anything with a vendor server component
- Watch for abandoned libraries and plan replacements before you are forced
- Small frequent upgrades are far cheaper than one giant jump
- Review the dependency list annually and remove what is unused
Crash and performance monitoring: seeing problems before your users report them
Without monitoring, the first sign of a serious bug is a one-star review, and by then it has affected everyone who hit it and told you nothing about why.
Crash reporting gives you the technical detail: what failed, on which device and operating system version, in which release, how many users are affected, and the sequence of events leading up to it. That turns a vague complaint into something reproducible. Alongside crashes, watch non-fatal errors, since an app that catches a failure and shows an empty screen never crashes but is still broken from the user point of view. Watch startup time and screen load times too, because performance decays gradually as features are added and nobody notices from the inside.
What matters is what you do with it. Set an alert threshold so a spike after a release reaches you within hours rather than at the end of the month. Watch the crash-free user rate as a trend rather than a number, since the direction after each release is the useful signal. Prioritise by how many users are affected and how badly, not by how interesting the bug is. And correlate with releases, because a crash rate that jumps on the day a version rolls out has told you exactly where to look. Phased rollout makes this far more useful, since a problem caught at a small percentage of users is a very different event from one that reached everybody.
- Track crashes, non-fatal errors and performance, not crashes alone
- Alert on spikes so a bad release is caught in hours
- Follow the crash-free user rate as a trend across releases
- Prioritise by affected users, not by technical interest
- Use phased rollout so problems surface while they are small
Store policy changes and staying compliant
Both stores update their rules regularly, and those changes apply to apps that are already published, not just to new submissions. An app that was fully compliant at launch can become non-compliant without changing at all.
The recurring areas are privacy and data handling, where disclosure requirements have expanded repeatedly and must stay accurate as the app changes; permissions, where justification requirements have tightened; account handling, including requirements around deletion; payment rules for digital goods; advertising and tracking disclosures; and content and age rating rules. Both stores also remove apps that have not been updated in a long period, so inactivity itself is a compliance risk.
Practically, this means someone has to watch developer communications rather than waiting for a notice. Deadlines are usually announced with reasonable warning, and the cost of acting early is small. The cost of missing one is disproportionate: updates blocked until it is resolved, or in the worst case removal from the store, which takes your app away from new users and, once removed, is a slower process to reverse than most people expect. Keeping your privacy declarations accurate is the highest-value habit here, because it is the thing most likely to drift as features are added and the thing most likely to be checked.
- Read developer communications, changes apply to published apps too
- Keep privacy declarations accurate as features change
- Review account deletion, permissions and payment rules periodically
- Act on announced deadlines early, they are not usually extended
- Inactivity itself risks removal, so keep releasing
How an unmaintained app degrades
Neglect does not break an app on a specific day. It erodes it, and the erosion is easy to ignore right up to the point where the fix is a rebuild.
The sequence is fairly consistent. First, small visual problems as system versions change: cropped layouts, awkward spacing, colours that read badly in a new default appearance. Then features that fail quietly, usually where an external service has changed or retired something. Then a rising crash rate on newer devices, and reviews that mention it. Then the store blocks new submissions because the build targets an outdated version, at which point you cannot even ship a small fix without a modernisation effort first. Then a security issue in an unpatched dependency becomes a real exposure. Eventually the app is removed for inactivity or non-compliance.
Ratings track this the whole way down, and ratings are hard to recover. Store visibility is influenced by rating and by recent activity, so a neglected app becomes less discoverable at the same time as it becomes less usable, and the two reinforce each other. Recovering an app that has been left for two or three years usually costs more than maintaining it would have, because the work arrives all at once and often includes a framework upgrade, a dependency overhaul and a compliance catch-up in the same project. The steady modest cost is not a subscription to nothing. It is what keeps the eventual bill from arriving in one piece.
- Visual breakage first, then quiet feature failures, then crashes
- Outdated build targets eventually block you from shipping any fix
- Unpatched dependencies turn into real security exposure
- Ratings fall as this happens and are slow to recover
- A neglected app costs more to revive than to maintain
A maintenance rhythm that works
Maintenance goes best as a routine rather than a reaction. A predictable rhythm keeps the work small, keeps costs level, and stops everything landing at once.
Monthly suits the recurring checks: review crash and performance data, apply dependency updates on a branch and test them, clear small bugs, and check for any store communications that need action. Quarterly suits the larger passes: a dependency and framework review, an audit of what is actually installed and used, a look at store listing performance, and a check that privacy declarations still match what the app does. Annually suits the bigger commitments: rebuilding against current tooling, planning for the next operating system release, and reviewing whether any part of the app needs modernising rather than patching.
Alongside the schedule, keep a release path that is ready to use. If shipping a fix requires half a day of remembering how the build works, urgent fixes get delayed for the wrong reason. A working pipeline, current certificates and credentials, and a tested submission process mean an emergency is a few hours rather than a scramble. And keep a short prioritised list of known issues, so when there is time for a release, the decision about what goes in it is already made rather than being reconstructed from memory each time.
- Monthly: crash review, dependency updates, small fixes, store notices
- Quarterly: deeper dependency audit, listing review, privacy check
- Annually: rebuild against current tooling and plan for the next OS release
- Keep the release pipeline and credentials ready before you need them
- Maintain a prioritised issue list so each release plans itself
A clear path, step by step
- 01
Take stock
Code review, crash data and store status, so we know exactly what we are maintaining.
- 02
Stabilise
Outstanding crashes, outdated dependencies and store warnings cleared first.
- 03
Maintain the rhythm
Scheduled releases for updates and small improvements, tested before every submission.
- 04
Report and plan
Monthly summary of stability, ratings and usage, feeding a prioritised roadmap.
Why choose us for this
We maintain apps we did not build, after an honest review
Store policy changes tracked, so compliance is never a surprise
Fixed monthly cost instead of emergency invoices
Common questions
My app still works. Why pay for maintenance?
Because it works until an OS update breaks it, a store policy delists it, or a library vulnerability forces a rushed fix. Steady small updates cost far less than the emergency rebuild, and stores favour actively maintained apps.
Can you take over an app another agency built?
Yes. We review the code and store accounts first and tell you plainly what shape it is in. Most handovers are routine; where the codebase has real problems, you get options and costs, not surprises.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase