The app shipped. The invoice was paid. Six weeks later the usage numbers are flat and somebody in a meeting asks what went wrong.
The instinct at this point is to buy something. Store optimisation, some advertising, a push notification strategy, a redesign. Every one of those is a real service that fixes a real problem. The difficulty is that "nobody is using it" is at least four different problems wearing the same symptom, and buying the fix for one of them while suffering from another is the most reliable way to spend money and change nothing.
This article is the diagnostic. It uses numbers you already have, in consoles you already have access to, and most of it takes an afternoon.
Four problems, one symptom
Nobody knows it exists. Impressions and product page views are low or flat. The problem sits upstream of your app entirely.
People install and never open it. Downloads look reasonable but active devices and sessions do not follow. Something between the store page and the first useful moment is losing people.
People open it and cannot finish. Sessions happen, but everyone stops at the same step, or the crash numbers spike around it.
People finish once and never come back. The first session goes fine and the cohort simply does not return.
The order matters, because each check rules a cause in or out before any money is spent. Check impressions and conversion rate first, in the console, in five minutes. Then check whether installs turn into active devices. Then build one funnel from first open to the action that matters. Then look at return behaviour.
The expensive mistake is skipping to step four's fix while sitting on step two's problem.
It is worth being concrete about what each looks like in a console, because the numbers are adjacent to each other and easy to misread. A discovery problem shows a small impressions figure with a perfectly respectable conversion rate: the people who see it install it, there just are not many of them. An onboarding problem shows healthy impressions, healthy installs, and an active-devices line that never rises to match, which is the single most diagnostic gap on either platform. A completion problem shows sessions happening normally while a specific step in your own funnel drains, often with raised crash numbers around it. A retention problem shows a clean first session and a cohort curve that falls to near zero within a week or two.
Only the third of those requires anything beyond the store console. The first, second and fourth are all answerable tonight with the access you already have.
What the stores actually tell you
Both platforms publish precise definitions of their own metrics, which is worth far more than any third-party estimate of the same thing.
Apple counts an impression as your app being viewed for more than one second across the Today, Games, Apps and Search tabs, with product page views tracked separately, and defines conversion rate as total downloads and pre-orders divided by unique device impressions [1]. On the usage side it counts a session as the app being used for at least two seconds, and active devices as devices with at least one session in the period [1]. Retention is a separate cohort report: rows are everyone who installed on the same day, columns are days since install, and people who installed but never opened are excluded from the calculation entirely [2].
Google Play separates three things that are easy to conflate. Its acquisition report gives you store-listing visitors, first-time installers, and retained installers, and Google is explicit in its own documentation that retained installers measures people who kept the app on a device, and that installation does not mean the app was opened [3]. That is a kept-installed metric, not an opened-again one. For opened-based retention on a non-game app you need Google Analytics or Firebase, which tracks returning users across the first forty-two days [5]. Separately, Android vitals gives you technical quality, including a user-perceived crash rate with a published bad-behaviour threshold of 1.09 per cent that affects store visibility [4].
One honest limit worth stating: neither store publishes what a healthy retention curve looks like for any category. Every industry benchmark in circulation traces back to an analytics or app-marketing vendor that sells retention tooling. We are not repeating one. Your useful comparison is your own curve this month against your own curve last month.
If impressions are fine, do not buy marketing
This is the single most common expensive mistake, so it gets its own heading.
If your impressions are healthy, and your conversion rate from impression to install is reasonable, and the flat line is active devices, then discovery is not your problem. Buying a store optimisation retainer at that point improves a number that was never the constraint. You will get more installs, those installs will behave exactly like the previous ones, and the usage graph will not move.
The store's own conversion rate is the fast way to rule discovery in or out before you spend on it. If impressions genuinely are the flat line, our app store optimisation guide covers the mechanics with the platform citations.
Onboarding is where most apps quietly lose
This is the least discussed of the four and, in our experience, the most common.
Three specific patterns account for most of it, and all three are things Apple and Google explicitly advise against in their own published guidance.
Permission dialogs at launch. Android's documentation is direct about this: prompt only when a specific feature requires it, because people are more likely to allow a permission they were expecting [8]. Apple's guidance matches, asking developers to request access when the app clearly needs it for a specific feature, with a short and specific purpose string [6]. A stack of permission requests before anything has happened reads, correctly, as an app taking before it gives.
Forced account creation. This one is store policy, not just design advice. Apple's review guidelines state that where an app does not include significant account-based features, people should be able to use it without logging in, and that apps may not require personal information to function except where it is directly relevant to core functionality or required by law [7]. So a sign-up wall in front of an app that does not genuinely need accounts is a review risk as well as the reason your installs never became sessions.
A first-run flow that teaches the wrong thing. Apple's onboarding guidance asks for a flow that is fast and optional, that teaches your app rather than the operating system, and that prefers short contextual tips over one long tutorial, on the reasoning that people grasp and retain more when they are actually performing the task rather than reading about it [6]. It also recommends making tutorials skippable on first launch but findable later, and providing sensible defaults so setup asks for as little as possible.
None of these are edge cases. They are the default outcome of building onboarding last, after the real features, with whatever time and budget is left. That is the unbudgeted work this article is naming.
One more detail from Google's guidance that matters for the third diagnosis: when somebody denies a permission, the app should degrade gracefully and let them keep using everything else [8]. Blocking the whole experience because one permission was declined turns a minor limitation into an uninstall.
When people finish once and do not come back
Before treating this as a marketing problem, ask the harder question. Does this product give somebody a real reason to open it a second time?
Some categories obviously do. A delivery app, a fitness tracker, a messaging tool all have a natural repeat occasion built into what they are. Many products do not, and for those, the retention curve is not broken. It is describing the product accurately.
A one-time enquiry form, a static price list, a single-use booking flow: none of these needed to live behind an install, and putting them there added a download step to something with no repeat-use case. Our guide on native apps versus progressive web apps covers where that line sits and is worth reading before commissioning a retention fix for a product that has nothing to retain people with.
Read your own curve, not somebody else's
Since no benchmark you can trust exists, the comparison that actually works is internal.
Take three cohorts: people who installed in your first week, people who installed a month ago, and people who installed last week. Put their curves side by side. If the newer cohorts are holding better than the older ones, whatever you have changed since launch is working, and you should do more of it. If every cohort looks identical regardless of what you have shipped, your changes are not touching the thing that decides whether people stay.
That second finding is more useful than it sounds, because it tells you the problem is structural rather than incremental. Teams in that position usually respond by shipping more small improvements, which is exactly what the flat cohorts have already told them will not work.
Segment one more way if you can: people who reached your core action in their first session against people who did not. On almost every product these two groups behave completely differently afterwards, and the gap between them puts a number on what onboarding is actually worth. If the people who get through cleanly do come back, and the ones who do not never return, then your entire retention problem is an onboarding problem in disguise, and you now have the evidence to say so before anybody commissions a push notification strategy.
None of this needs a vendor tool. Apple's cohort grid and a GA4 retention report both support it directly, and the segmentation only needs the events you should already have.
The possibility nobody raises
Sometimes the build is fine, discovery is fine, onboarding is fine, and usage is still flat, because the thing being offered does not solve a problem enough people have.
That is a demand problem, not a distribution problem, and the two are easy to confuse because they produce an identical symptom and require completely different responses.
Here is how to separate them without any special tooling. A distribution problem means that when somebody actually reaches the core action, they complete it, and where relevant they come back. The failure is in getting them there. A demand problem means that even the people who did everything right, found it, installed it, got through onboarding cleanly, reached the core action and completed it, still do not return, do not pay, and do not tell anyone. The funnel completes at every step and the outcome is still flat.
Businesses spend heavily on the distribution side when the actual problem is demand, because distribution spend is legible and demand is not. There is an invoice for advertising and an invoice for store optimisation. There is no invoice for not enough people wanting this. So the money goes where the receipts are.
If the people who reach the counter still do not buy, the question is no longer how to get more people to the door.
The launch work that gets skipped
Not marketing. The mechanical work both platforms built tooling for, which a "we shipped it, now we launch" plan usually omits entirely.
Google Play provides internal testing for up to a hundred testers, closed testing for larger targeted groups, and open testing as a public pre-release, and its own guidance is to move through those in order before a full production release [9]. Apple provides TestFlight, with internal team testing plus up to ten thousand external testers and a structured feedback channel back to the developer [10].
For updates, both platforms let you release gradually. Google Play's staged rollouts release to a percentage of users that you increase manually [11], and Apple's phased release for automatic updates follows a fixed seven-day schedule you can pause at any point [12]. Neither applies to a first submission, which is exactly why the testing tracks matter more for a first launch than the rollout controls do.
Apple's custom product pages, which let you show a different pitch to different audiences through separate links, are a tool for re-engaging lapsed users rather than a discovery tool [13]. Apple publishes an average lift for apps using the feature, though that average is drawn from apps that chose to adopt it, so treat it as directional.
The genuinely unbudgeted item, though, is instrumentation. Events need to exist before launch, not after usage looks flat, because you cannot diagnose anything from numbers nobody collected. Our product analytics guide covers what to instrument and how to name it.
What this costs
A diagnostic engagement with us starts from around AED 2,500. That covers pulling and reading your store console numbers, checking whether your event model can actually answer the question, building the one funnel that matters, and giving you a plain finding of which of the four problems you have.
Fixing onboarding, once diagnosed, starts from around AED 4,000, covering first-run flow, permission timing, and account and sign-in requirements. Final pricing depends on scope. These are our own figures rather than a market survey, since no official body publishes rates for this work.
They are deliberately separate engagements, because there is no sense redesigning onboarding if onboarding was never the problem. And before you spend either figure, open your console and answer two questions: how many people saw the listing, and of the people who installed, how many have opened it since. Five minutes, no cost, and it eliminates at least half the possible answers.
References
- Apple, App Store Connect Analytics metric definitions
- Apple, App Store Connect Analytics app retention
- Google Play Console Help, measure your app's acquisition and retention
- Google Play Console Help, Android vitals
- Google Analytics Help, GA4 retention overview report
- Apple, Human Interface Guidelines, onboarding
- Apple, App Store Review Guidelines
- Android Developers, app permissions best practices
- Google Play Console Help, set up an open, closed or internal test
- Apple, TestFlight
- Google Play Console Help, release app updates with staged rollouts
- Apple, App Store Connect phased release for automatic updates
- Apple, custom product pages on the App Store
- SKIMBOX, app store optimisation in the UAE
- SKIMBOX, product analytics and event tracking
- SKIMBOX, native app versus progressive web app
Platform metric definitions and thresholds accurate as of 23 August 2026. Apple and Google revise this documentation without version history, so check the linked page before relying on a specific figure.
