App maintenance
App maintenance services: repair or rebuild a broken app
When to repair a broken app and when to rebuild it, using a decision table built from 13,904 real complaint clusters found across 6,634 audited mobile apps.
Short answer
Repair when the failures sit in the listing, copy, notifications, or one isolable subsystem — most of those are days of work. Rebuild when crashes, device-wide incompatibility and billing plumbing fail together on an unmaintained codebase. Across 6,634 audited apps, 10.3% show crash clusters and 28.4% show device-compatibility clusters.
First, separate the app from its listing
A large share of "my app is failing" cases are not code problems at all. 84.1% of the 6,634 apps we audited have no preview video, the average app uses 13.1 screenshots, and the average title uses 21.5 of the 30 characters available. The average ASO score is 77.6 out of 100, and 22.7% of apps sit at grade C with a further 4.0% at D or F.
If installs are the complaint, fix that first — it costs hours and touches no code. If retention and ratings are the complaint, the problem is in the app, and the rest of this article is the triage. Run a listing through /app-audit before you commission any engineering work; it is the cheapest way to find out which of the two you are dealing with.
The repair-or-rebuild table
This is the framework I use. Percentages are the share of the 6,634 audited apps carrying that complaint cluster. Depth is a judgement about where the fix usually lives, not a quote.
| Complaint cluster | Share of audited apps | Where the fix usually lives | Verdict |
|---|---|---|---|
| Notifications | 5.8% | Permission prompts, token refresh, scheduling logic | Repair — days |
| UI or UX | 25.4% | Copy, navigation order, empty states, contrast | Repair — days to weeks |
| Missing features | 10.3% | Roadmap, not defect | Repair — scoped as new work |
| Customer support | 15.2% | Support inbox and review replies, not code | Repair — immediate |
| Login | 17.2% | Auth provider config, recovery paths, token handling | Repair unless auth is homegrown |
| Slow performance | 8.7% | Network calls, list rendering, image sizing | Repair if profileable, else deeper |
| Location or GPS, camera, upload | 7.2% / 4.4% / 4.4% | Permission handling and platform API drift | Repair — usually one subsystem |
| Payment, subscription, refund | 28.6% / 21.8% / 6.5% | Receipt validation, entitlement state, server logic | Deep — rebuild the billing layer, not the app |
| Device compatibility | 28.4% | Layout system, min-SDK, deprecated APIs | Deep — often signals an aged codebase |
| Crash and freezing | 10.3% / 5.8% | Memory, threading, unmaintained dependencies | Rebuild candidate if combined with staleness |
The cheap fixes, ranked by how often they are the real problem
Listing work comes first because it is measured in hours. Then review replies: 3,143 audited apps (47.4%) have never replied to a single review, and 1,009 (15.2%) carry a customer-support complaint cluster — which is users saying publicly that private support did not answer. Turning that around requires an inbox and a person, not a sprint.
After that come notifications (388 apps, 5.8%), which are almost always permission-prompt timing or a stale push token rather than anything structural, and UI or UX complaints (1,684 apps, 25.4%), which are frequently copy and navigation order. UI is the largest cheap cluster in the set and the one most often misdiagnosed as needing a redesign.
The expensive ones, and why they cluster together
Device compatibility (1,885 apps, 28.4%, 7,894 matching reviews) is joint-largest with payment — fifteen apps apart, which is a tie — and it is rarely fixable in isolation. When users report the app failing on specific hardware, the cause is usually an ageing layout approach, a minimum SDK chosen years ago, or platform APIs that were deprecated and then removed. Fixing one device fixes one review.
Billing is the other deep one, and the one that edges device compatibility for the top row: payment complaints on 28.6% of apps, subscriptions on 21.8%, refunds on 6.5%. The fix normally means rebuilding entitlement handling end to end — server-side receipt validation, restore purchases, and correct grace-period behaviour — because patching one symptom on top of broken entitlement state produces the next symptom.
Crashes (686 apps, 10.3%) and freezing (387, 5.8%) are smaller clusters by count and the most decisive. On their own they are a debugging job. Combined with a codebase nobody has shipped in a year, they usually mean the dependency tree cannot be upgraded without a rewrite of whatever sits on top of it.
My rebuild threshold: three of these five
I default to repairing. Rebuilds are expensive, they throw away working behaviour nobody documented, and they reset the store listing's review history in practice even when they do not in principle. But I stop defending repair when three of the following five are true at once.
- No release in 365+ days — true of 622 audited apps (9.4%), and of 302 (4.6%) for two years or more
- Crash or freezing clusters present alongside device-compatibility clusters
- The billing layer cannot be reasoned about — entitlement bugs reappear after each fix
- The dependency tree cannot reach a currently supported target API or SDK level without breaking changes
- No original developer, no build documentation, and no reproducible release pipeline
When the app stopped working after an update
Two different situations get described the same way. If your app broke after you shipped a release, the answer is a staged rollout and a rollback: both stores support phased release, and the fastest correct move is to halt the rollout before triaging. Check crash and ANR rates in Android vitals rather than reading reviews for diagnosis — reviews lag by days.
If your app broke after an OS update and you shipped nothing, it is usually a removed API, a permission model change, or a background-execution restriction. That is a repair, and it is the exact failure mode the staleness numbers predict: an app last updated 18 months ago has sat through at least one major release on each platform without anyone checking.
What app maintenance services should actually cover
A maintenance plan that only fixes reported bugs is a support desk, not maintenance. The recurring work that prevents the deep failures above is scheduled, not reactive.
- Dependency and SDK upgrades on a schedule, ahead of store target-API deadlines
- Crash and ANR monitoring with a triage threshold, not a monthly report
- A device matrix re-run before each release, including one low-RAM Android device
- Billing regression tests covering restore purchases, reinstall, and expiry
- Review triage and replies — the average audited app replies to 28.0% of its reviews, and 47.4% reply to none at all
- Store listing refresh on a cadence, since 84.1% of apps still have no preview video
Where these figures come from
Every percentage above uses the method set out under "How this data was collected" in /blog/mobile-app-development-tips, and in full at /methodology. Clusters are keyword-classified public 1-3 star reviews with a two-review minimum: user-reported signals, not confirmed code defects — a crash cluster means several users described a crash, not that we reproduced a stack trace. Sample: 6,634 apps, 6,144 with stored reviews, 13,904 clusters of which 1,741 (12.5%) are high severity — a snapshot taken on 3 August 2026, and the catalog grows continuously, so live totals are higher. Published reports at /app-reports, and repair work at /services.
Clear answers
Frequently asked questions
Should I repair or rebuild my app?
Repair by default. I only argue for a rebuild when at least three of these are true: no release in over a year, crash clusters alongside device-compatibility clusters, unreasonable billing entitlement logic, a dependency tree that cannot reach a supported target API, and no reproducible build pipeline.
My app is not working after an update — what do I check first?
If you shipped the release, halt the staged rollout before triaging, then read crash and ANR rates rather than reviews, which lag by days. If you shipped nothing and an OS update broke it, look for removed APIs, permission model changes, and background-execution restrictions.
Which app problems are cheapest to fix?
Store listing gaps, unanswered reviews, notification permission and token handling, and UI copy or navigation order. Notifications affect 5.8% of audited apps and UI or UX 25.4%, and both usually resolve without structural change. Listing fixes take hours and require no code at all.
Which problems usually mean deep work?
Device compatibility, which appears on 28.4% of audited apps across 7,894 reviews, and anything in the billing layer — payment 28.6%, subscription 21.8%, refund 6.5%. Both tend to indicate a structural cause rather than a single defect, so patching individual symptoms produces the next symptom.
Does a rebuild lose my ratings and reviews?
Not if you ship into the same store listing rather than a new one, which is what I recommend. What you do lose is undocumented behaviour that current users depend on, so a rebuild should start by cataloguing what the existing app actually does, including the parts nobody wrote down.
What does an app maintenance plan include?
Scheduled dependency and SDK upgrades ahead of store deadlines, crash and ANR monitoring with a triage threshold, a device matrix re-run each release, billing regression tests, review triage, and periodic store listing refreshes. Reactive bug fixing alone is a support desk, not maintenance.