What App Store Download Estimates Actually Tell You
App Store download estimates are modelled numbers, not measurements. No third party has access to Apple's actual per-app figures, so every download and revenue number you see about a competitor is an inference produced from observable signals. That does not make them useless. It makes them a specific kind of instrument — reliable for some questions, actively misleading for others — and the difference is learnable in about ten minutes.
This article covers what an App Store download estimate actually is, why it will never match what the developer sees, and how to make a confident call when the number in front of you might be off by a quarter. It is the first post in the Data & Insights pillar.
The Short Answer
- Nobody outside a company has its real per-app numbers. Apple reports those only to the app's own developer, inside App Store Connect. Every public competitor figure is modelled.
- "Downloads" is not one quantity, even at the source. Apple itself publishes several download-shaped metrics that count different events. Store-wide, Apple's own data shows redownloads running roughly 2.2x first-time downloads — so which metric you mean changes the answer by more than double.
- Gross or net is not a safe assumption. Vendors differ on whether a revenue estimate is customer spend or developer proceeds. Appfigures states its estimates are already net of Apple's fee. Never compare a revenue estimate across two tools without checking.
- Estimate error is systematic, not random. That is good news: apps pulled from the same source in the same query share most of their bias, so ratios and rank-ordering survive even when absolute values do not.
- No independent audit of estimate accuracy exists. The only published accuracy figures are vendor self-reported.
Nobody Outside the App Has the Real Number
Apple gives per-app download and revenue reporting to the developer of that app, in App Store Connect. It does not publish per-app counts for anyone else to read.
That single fact created the entire estimates industry: real demand for competitor numbers, no authoritative public supply. Vendors fill the gap by modelling from what is observable, and they say so themselves. Sensor Tower draws on "our proprietary panel, first party data, and publicly available data, like earnings releases," built on "a panel of more than 10 million consumers," and states the limit plainly: "Since no dataset represents 100% of all digital user behavior, we model our data to estimate how the global population engages online." (Sensor Tower, Responsibly Sourced Data) Appfigures is blunter about what modelling means: "Modeling means making assumptions. Because we're estimating, we have to make assumptions." (Appfigures Help, 25 March 2026)
One consolidation worth knowing before you seek a second opinion: Sensor Tower acquired data.ai — formerly App Annie — in a deal announced 18 March 2024. Two estimates that appear to corroborate each other may now come from one vendor.
The correct posture is not "this number is wrong" or "this number is right." It is this number carries a certain class of information, and I will only ask it questions from that class.
Even Apple Reports Several Different "Download" Numbers
Before arguing about whether an estimate is accurate, it is worth knowing that the thing being estimated is ambiguous. Apple's own reporting contains several download-shaped metrics that deliberately count different events. These are Apple's definitions:
| Apple metric | Counts | Excludes |
|---|---|---|
| App Units (Sales and Trends) | First-time purchases — counted when a customer taps Buy or Get for the first time | App updates, downloads to different devices under the same Apple Account, redownloads to the same device. Family Sharing counts for free apps, excluded for paid apps |
| First Time Downloads (Analytics) | First-time downloads on iOS, macOS, tvOS or visionOS devices | Repeat downloads by the same customer |
| Redownloads (Analytics) | Counted when a customer clicks the redownload button | Auto-updates and device restores |
| Total Downloads (Analytics) | The sum of First Time Downloads and Redownloads | — |
| Installations (Analytics) | Completed installs, including redownloads on the same device, downloads to multiple devices sharing one Apple Account, and Family Sharing installations | Failed or incomplete installations |
Sources: Apple, View units, proceeds, sales, and pre-orders and App Store Connect Analytics metric definitions.
These nest inside one another: App Units ⊂ First Time Downloads ⊂ Total Downloads ⊂ Installations. App Units is the narrowest — one human, one first purchase. Installations is the widest, and the only one that counts the same person installing on a second device.
How wide is that spread in practice? Apple answers this itself. Its 2025 App Store Transparency Report gives store-wide weekly averages of 929,754,061 app downloads and 2,053,461,208 app redownloads. Redownloads run about 2.2 times first-time downloads across the whole store.
Sit with that. Depending on which metric you mean, the same app's "monthly downloads" can differ by a factor of three — before anyone starts estimating anything. When a tool says a competitor did 40,000 downloads last month, the first honest question is not how accurate is that but which of these is it approximating. Usually it is closest to first-time acquisition, which is the number you want for competitive research. But the ambiguity is structural, and it puts a floor under how precise any estimate can ever be.
Practical consequence: stop treating a single-digit-percentage gap between two competitors as meaningful. The metric definitions alone are wider than that.
Check Gross vs Net Before You Compare Anything
There is a widespread belief that revenue estimates always show gross customer spend. That is not safe to assume, and getting it wrong distorts every comparison you make.
Apple distinguishes two things explicitly. Sales is "the total amount billed to customers," inclusive of taxes Apple collects. Proceeds is "the Customer Price minus applicable taxes and Apple's commission." Apple states plainly that "sales totals are not the same as your proceeds."
Vendors do not treat this uniformly. Appfigures documents that its figures are already net: "Revenue estimates are after Apple's and Google 30% (or 15% for subscriptions) fee, so they aren't what the customer spent but rather what the developer earned." (Appfigures Help, 20 January 2026) Other vendors conventionally report gross consumer spend — a ~30% difference in meaning attached to identical-looking numbers.
The commission that separates the two, as Apple frames it:
| Situation | Developer receives | Implied commission |
|---|---|---|
| Standard rate | 70% | 30% |
| Subscription, before one year of paid service | 70% | 30% |
| Subscription, after one year of paid service | 85% | 15% |
| App Store Small Business Program | 85% | 15% |
The Small Business Program applies the 15% rate to developers who earned no more than 1 million USD in total proceeds in the previous calendar year and no more than 1 million USD in the current one, plus developers new to the App Store. For most indie developers, 15% is the rate that applies.
The rule: find out whether your tool reports gross or net before you benchmark anything against your own targets, and never compare a revenue estimate from one tool against one from another without checking both.
Estimate Error Is Systematic, Not Random
This is the property that makes estimates usable, and almost nobody states it explicitly.
If estimate errors were random noise, you could average them away. They are not random. They are systematic, driven by how much signal an app throws off — which is itself driven by things you can observe:
- Rank tier. Highly ranked apps generate far more observable signal than long-tail apps. Appfigures states outright that apps below a minimum download threshold — ranging from 1 to 100 depending on country and category — get no daily estimates at all.
- Storefront. Coverage varies by country, and estimates "aren't available for all countries or may exclude regions where apps lack sufficient adoption."
- Platform and model. Appfigures notes that for iOS it currently models downloads "on iPhones and not on iPads," and that it does not produce estimates for paid apps at all. Coverage gaps like these are specific and checkable — read your vendor's documentation for the equivalents.
- Recency. Current partial-month figures rest on less settled data than closed historical periods.
Systematic error sounds worse than random error. For decision-making it is much better, because apps observed under the same conditions share most of their bias. Pull the top five apps for one keyword, one storefront, one period, one source, and whatever distortion the model applies lands on all of them in roughly the same direction.
That gives you the operating principle for the entire discipline:
Estimates are far more trustworthy as a relative instrument than an absolute one. Compare within a query, not across contexts.
"Is app A roughly five times bigger than app B?" is answerable. "Does app A do exactly 41,300 downloads?" is not.
On published accuracy: Appfigures reports using "the industry-standard MAPE or Median Absolute Percent Error" with "an error rate between 5% (best case) and 25% (worst case)" — the most specific figure any major vendor publishes, and self-reported with no disclosed test set. Sensor Tower publishes no margin of error at all. No independent audit of app-estimate accuracy exists that stands up to checking, so treat any confident third-party accuracy percentage as unsourced until proven otherwise.
What Estimates Can and Cannot Answer
| Question | Answerable? | Why |
|---|---|---|
| Is this category big, medium, or dead? | Yes | Order-of-magnitude judgement — exactly what estimates support |
| Which of these five competitors is largest? | Yes | Relative comparison under shared conditions |
| Does this audience pay at all? | Yes | A revenue-to-download ratio, so bias largely cancels |
| Is the leader 10x the size of position five? | Yes | Ratio within one query |
| Is position three ahead of position four? | Weak | Small gaps sit inside the error band |
| What will my app earn? | No | Different app, different conversion, different retention |
| What is this competitor's exact monthly revenue? | No | Absolute precision is the one thing estimates cannot give |
| Did this app grow 4% last month? | No | Small deltas are indistinguishable from model noise |
The pattern is consistent. Questions about shape — magnitude, ranking, ratio, direction — are answerable. Questions about precise level are not.
The Halve-and-Double Test
Here is the decision rule that turns all of the above into something you can run in thirty seconds.
Take the estimate you are about to rely on. Halve it. Double it. Ask whether your decision changes at either end.
- Decision holds at both ends → the estimate is good enough. Act on it and stop researching.
- Decision flips → the estimate cannot carry this decision. You need a different input, a narrower question, or a bigger margin of safety.
Illustrative arithmetic, using round numbers rather than any real app: suppose you are deciding whether to build in a niche where the leading app shows an estimated 8,000 monthly downloads. Halve it to 4,000, double it to 16,000. If your plan works at 4,000 and is still sane at 16,000, uncertainty is not your problem — go build. Now suppose your plan needs the leader to be at 30,000 for the category to be worth entering. Even doubled, 8,000 does not reach your threshold, so the answer is clear in the other direction and you have saved yourself the build.
The uncomfortable case is the middle one, where halving kills the plan and doubling saves it. That is the data telling you the decision is genuinely marginal — real information, and a signal to go find a better keyword rather than to hunt for a precision that does not exist.
Ratios Beat Levels: Revenue per Download
The most useful thing you can compute from an estimate is not either number alone. It is the ratio between them.
Divide estimated monthly revenue by estimated monthly downloads and you get a rough revenue-per-download figure. Because both inputs come from the same model, storefront and period, much of the bias cancels — the ratio is more robust than either number that produced it.
Again with deliberately round illustrative numbers, not a real app: 5,000 downloads and $50,000 revenue implies roughly $10 per download — an audience that pays, and pays well. 50,000 downloads and $5,000 revenue implies roughly $0.10 per download — a free-forever audience, monetised thinly or by ads. Those describe two completely different products, and the conclusion survives even if both underlying estimates are wrong by half, because halving both leaves the ratio untouched.
That is the highest-value calculation in competitive research, and the one most resistant to estimate error. What to do with the answer — which monetisation model a category will actually support — is covered in how to price an iOS app.
How to Pull the Numbers
Everything above is interpretation. You still need estimates in front of you for the top apps in your target keyword, without an afternoon of tab-switching.
App Store Operator is an MCP server that puts App Store competitive data directly inside Claude — estimated monthly downloads, estimated monthly revenue, rating count, rating score, publisher country and top markets. Register it with one command:
claude mcp add --transport stdio app-store-operator -- npx -y app-store-operator@latest
Then ask for a keyword's competitors in plain language:
Research the top rivals for "habit tracker" in the US App Store.
Because the whole point of this article is that ratios beat levels, the follow-up is where the value is:
For each of those apps, compute estimated revenue per download and tell me which ones suggest an audience that actually pays.
Two of the four tools — search_app_store and prepare_iae — need no account at all. The two analytics tools, research_rivals and get_app_details, open a browser window once for a one-time sign-in to a free SensorTower account, then reuse that saved session locally. Results cache for 24 hours, so sweeping a full keyword list in one sitting is cheap. Setup detail is in the Claude Desktop and Claude Code setup guide, and the use cases page shows what each tool returns.
Frequently Asked Questions
How accurate are App Store download estimates?
There is no independently audited accuracy figure. The most specific number any major vendor publishes is Appfigures' self-reported Median Absolute Percent Error of 5% at best and 25% at worst. Treat estimates as order-of-magnitude accurate — reliable for telling a 1,000-download keyword from a 100,000-download keyword, unreliable for distinguishing 41,000 from 46,000. Accuracy is better for highly ranked apps in large storefronts than for long-tail apps in small ones.
Why do download estimates never match App Store Connect?
Two reasons. They are modelled from observable signals rather than measured, so a gap is structural rather than a bug. And "downloads" is ambiguous inside Apple's own reporting — App Units, First Time Downloads, Total Downloads and Installations count different events, so an estimate can be close to one and far from another at the same time.
Do revenue estimates show customer spend or developer earnings?
It depends on the vendor, and you must check. Apple separates Sales (billed to customers, gross) from Proceeds (customer price minus taxes and Apple's commission). Appfigures documents that its revenue estimates are already net of the platform fee; other tools conventionally report gross consumer spend. Comparing one against the other introduces a roughly 30% error.
Can I use download estimates to forecast my own revenue?
No, and this is the most common misuse. A competitor's estimate reflects that app's conversion, retention, pricing and brand, none of which transfer to you. Use estimates to size the opportunity and judge whether a category monetises. Forecast your own revenue from your own funnel assumptions.
What is the most reliable thing to compute from an estimate?
A ratio between two figures from the same query — most usefully estimated revenue divided by estimated downloads. Because both carry the same model bias, much of the error cancels, so the ratio is more robust than either input.
Does Apple publish download numbers for individual apps?
Not per app. Apple reports per-app analytics only to that app's developer in App Store Connect. It does publish store-wide aggregates in its annual App Store Transparency Report — the 2025 edition gives weekly averages of 929,754,061 downloads and 2,053,461,208 redownloads across 175 countries and regions. That is exactly why third-party estimates exist, and why every public per-app number is an inference.
Decide With the Number You Have
The instinct when you first see a modelled number is to ask how wrong it is. That question has no answer and no payoff. The better question is which class of decision the number can carry — and the answer is consistent: magnitude, ranking, ratio and direction, yes; precise level, no.
If your decision survives the halve-and-double test, you have enough. If it does not, the problem is not your data source — it is that you are asking a question the data was never built to answer.
Set up the data pull:
claude mcp add --transport stdio app-store-operator -- npx -y app-store-operator@latest
From there, the framework for turning these numbers into an enter-or-avoid call is in the competition analysis guide, the full checklist to run before you submit is in the pre-launch competitive research guide, and if you are weighing a lightweight scan against a full ASO platform, App Store Operator vs. SensorTower covers where each one earns its place.
Run your first competitive research in 60 seconds.
App Store Operator connects Claude to App Store and SensorTower data — no browser, no API keys, no manual copy-paste.
View setup guide →