No app publisher will disclose what they earn, and the App Store keeps that number to itself. Analysts, investors, and competitors still put a figure on it every day. They work from public signals and a little arithmetic, and the credible ones acknowledge how wide the margin runs. Three approaches stand up to scrutiny, ranked below by how much weight each can bear.
- Downloads times revenue per download: fast, rough, and only as good as your download estimate.
- Third-party estimators (Sensor Tower, Appfigures, AppTweak): convenient, though they disagree with one another more than their dashboards let on.
- Store-signal triangulation: slower, and it catches the errors the first two miss.
None of them hands you the true number. Only the company's own finance team has that. What they give you is a defensible range, and a defensible range is usually enough to decide with. One signal outperforms all three, because it removes the estimation entirely. We'll come back to it before the end.
Your own app versus everyone else's
When the app is yours, revenue is no mystery: you open the dashboard. Ask what a competitor earns and every dependable number disappears, leaving only what the store publishes, rank, ratings, review counts, price, and the occasional download band. Estimating revenue is the discipline of turning those public signals into a figure and knowing how far to trust it.
Which tool you reach for depends on that split. Forecasting your own future earnings is better served by a calculator built on your own users, churn, and price, a genuinely different task with its own revenue estimator. What follows is the harder case, where the store's public signals are the only inputs on offer.
Method 1: Estimate revenue from download counts
The oldest approach is also the most direct. Estimate how many downloads an app pulls, multiply by what each download yields, and a revenue number appears. Revenue per download, or RPD, folds in in-app purchases, subscriptions, and ad income, less whatever Apple or Google keeps.
Take an app with an estimated 100,000 downloads a month, monetizing at roughly $0.20 each. That points to about $20,000 in monthly revenue, before the stores deduct their 15 to 30 percent. The arithmetic is simple and the answer is quotable.
Both inputs are loose. Download estimates are modeled rather than measured, so each carries its own margin. RPD varies enormously by category, since a mobile game and a habit tracker monetize along entirely different curves. Multiplying two uncertain figures compounds their error instead of cancelling it, and the result can land at half or double the truth.
So instead of leaning on this method for precision, use it for scale. It will tell you whether an app is a ten-thousand-dollar business or a ten-million-dollar one. Ask it to separate forty thousand from fifty-five and it will mislead you.
Method 2: Third-party app revenue estimators
The convenient route is to delegate the modeling. Sensor Tower, Appfigures, and AppTweak estimate downloads and revenue from device panels, store rankings, and years of historical data. Enter an app, receive a number in seconds. Each has its strengths, whether breadth of coverage or a developer-friendly read on your connected apps, and none of them is out to deceive you.
One caveat before you trust any single dashboard: data.ai, once the best known name here, was absorbed by Sensor Tower in 2024, so the genuinely independent cross-checks now come down to Sensor Tower, Appfigures, and AppTweak. And they diverge. Query the same app in two of them and the revenue estimates rarely match, sometimes landing twice as far apart as their confident interfaces suggest. The gap traces back to a single assumption: what share of downloads converts to paying users, and in which countries, since a paying install in the United States yields many times one from a low-ARPU market.
The vendors are candid about the limits. Appfigures reports its own estimate error at 5 percent in the best case and 25 percent at worst, measured by median absolute percent error, and revenue is harder to model than downloads. In practice the misses run wider. One developer publicly reported Sensor Tower listing their app at $40,000 in monthly revenue when the real number was $90,000, under half the truth.
None of that makes the tools worthless. It means one number from one tool isn't a fact. Run two of them and treat the gap between their estimates as your error bar. If you're choosing a tool for a particular job, this rundown of app pricing and monetization tools is a reasonable place to start.
Method 3: Triangulate the store's own signals
The method seasoned analysts rely on is triangulation: read several public signals and force them to agree. Top-grossing rank within a category maps roughly to revenue, provided you know what the top of that category earns. Review velocity, the number of new reviews arriving each week, stands in for download momentum. And the in-app purchase price list shows what an app charges and where, which anchors the estimate to something firm.
One of those signals needs no estimating at all. An app's price in every storefront is public and exact, pulled straight from the stores, so mapping a competitor's full price list takes seconds. The Spotify pricing audit shows what that looks like in every country at once. Prices reveal how much of a category is tuned for US wallets versus local buying power, often a sharper signal than a fuzzy revenue total. For the deeper read, these competitor pricing metrics and this guide to tracking competitor in-app purchase prices go further.
Triangulation is slower, and it wants a category benchmark you may not have on hand. The payoff is a check on the other two: a revenue estimate that contradicts an app's rank, its review pace, and its posted prices is one to discard.
The three methods side by side:
| Method | How it works | Where it fails | Best used for |
|---|---|---|---|
| Downloads times RPD | Download estimate multiplied by revenue per download | Two loose inputs compound into a wide error | Order-of-magnitude scale |
| Third-party estimators | Panels, rankings, and historical models | Tools disagree, usually on the paid-conversion assumption | A second opinion and an error range |
| Store-signal triangulation | Cross-check rank, review velocity, and live prices | Needs category benchmarks, and it's slower | Catching the other two when they go wrong |
The one number you don't have to estimate
Revenue is always a guess. Price is not. What a competitor charges, in each market, is public and precise, and it often reveals more about their strategy than a revenue total could: where they discount, where they hold the line, which countries they treat as premium and which they have written off. A free pricing audit reads that from public App Store data and shows where any app is priced high or low, country by country, with no signup. When the revenue range refuses to narrow, price is the one reference point you can fix in place.
How to sanity-check any revenue estimate
- Use two sources. Run at least two methods and let the spread between them define your error bar.
- Subtract the store cut. A gross number isn't what the developer keeps. Deduct 15 to 30 percent before quoting it.
- Weight by country. A US install can yield several times one from a low-ARPU market, so a download total with no country mix is half an answer.
- Distrust round numbers. "A million a month" is usually a headline rather than a measurement.
- Anchor to price. When the revenue range stays wide, pricing is the one input you can verify instead of model.
Frequently asked questions
Can you check an app's exact revenue?
No. Only the publisher and the app stores hold the true number. Everything public is an estimate built from downloads, price, category, and benchmark conversion rates.
How accurate are third-party app revenue estimators?
Directional. Appfigures reports its own error between 5 and 25 percent by median absolute percent error, and revenue is harder to model than downloads. Two tools will often disagree on the same app, so the spread between them is a better confidence interval than either estimate alone.
How do analysts estimate app downloads?
Downloads are modeled from store rankings, panels of opted-in devices, and historical patterns, then calibrated against the few known data points. Measured for your own app, modeled for everyone else's.
Is it legal to check a competitor's app revenue?
Estimating from public signals is ordinary competitive research. It draws on data the stores publish, ratings, rankings, and prices, not anything private.
A more answerable question
A revenue number is only a means to a decision, and that decision is almost always about pricing or positioning. Once the range is defensible, narrowing it further reaches diminishing returns. So before spending another afternoon refining a competitor's revenue, the smaller and far more answerable question underneath deserves to go first: what is their price doing in each market that yours is not?
