How AppCurrents estimates

• iTunes RSS charts — Top Free / Paid / Grossing across the full genre & sub-genre tree (US), the trend time-series.
• iTunes Lookup API — name, developer, price, category, release & update dates, average rating, and total rating count.
• App Store listing — screenshots (the Lookup API omits them for many new apps).
• Google Play install buckets — public lifetime-install ranges, used only to calibrate (see §5).

Android downloads are measured; iOS downloads are modeled. Google Play exposes each app's precise lifetime install count, so for Android we use it directly. Apple exposes none, so for iOS we model downloads from rating activity (a wider ± range). Both are worldwide, anchored on each app's own global signal. In priority order:

• Measured Play installs (Android). The precise lifetime install count, and its day-over-day change (Δinstalls ÷ days) as a measured monthly download rate — the strongest download signal we have. Apple has no equivalent.
• Rating velocity (iOS). Once day-over-day history exists, Δratings/day ÷ 0.012gives current worldwide monthly downloads directly — the most accurate iOS signal.
• Rating count → installs (iOS lifetime). Lifetime ≈ total ratings ÷ 0.012 (the ~1:83 ratings-to-installs ratio). Monthly ≈ lifetime ÷ app age, nudged by current chart presence (×1.5 if charting now, ×0.6 if not).
• Chart rank as a floor — for new/viral apps whose ratings haven't caught up, a power-law rank curve provides a floor. Genre-only ranks are translated to an equivalent overall position using a power law fit from our own data (real genre↔overall rank pairs), since a #50 in Finance ≠ a #50 in Games.
• Cross-store floor (iOS). When the same product is linked to an Android edition with a measured Play install base, that base — scaled by the category's typical iOS:Android install ratio (measured from apps listed on both stores) and amortized over the iOS app's age — sets a conservative floor under the iOS estimate, so a mature app whose rating velocity has decayed below its installed base isn't undercounted. It only ever raises the estimate, is capped, and stays a modeled figure.

Figures approximate worldwide store-IAP gross revenue — the App Store + Google Play in-app-purchase spend an app captures across 12 storefronts, before the platform cut (the standard worldwide-gross convention), so they're directly comparable. Each app is priced by the best revenue signal it actually has — one of three tiers. (App-store grossing charts are revenue-ranked, so a chart position is the strongest public signal of how much an app makes; but chartdepth matters — an overall #5, a category #5 and a sub-genre #5 are very different dollar amounts.)

• 1 · Grossing — on the overall chart. An app on the broad overall grossing chart (the one revenue-ranked list every app competes in) is priced off that rank as marketWeight × rank^−0.75 summed across markets, trusted in proportion to how much of the world it charts in. (Google Play's overall chart excludes games, so Android games use the top-level Games chart.) An app charting only a narrow sub-category but never the overall chart is notpriced like a top earner — it drops to a lower tier.
• 2 · Category-rank. An app absent from the overall chart but charting its category in a major market is priced off that rank, with a curve fit to that specific category — its own monetization signal, rather than a category-average download estimate. The rank is clamped to the range we have anchors for, so a large app whose overall rank simply isn't captured reads bounded (and low-confidence), never an extrapolated mega. We also require the app to chart its category consistently (over a trailing two-week window), not just for a day — an app that briefly flickers onto a shallow category chart is treated as download-flow, so its estimate stays steady instead of swinging day to day. Most niche subscription apps land here.
• 3 · Download-flow. An app with no grossing presence at all is sized as worldwide downloads × a per-category revenue-per-download. New & rising apps read small and realistic here. We deliberately do not read an app's posted IAP prices — testing showed the sticker price is a near-noise signal (price and conversion trade off, so a $90 tier doesn't mean more revenue).
• The three tiers have independent parameters, so re-tuning or re-anchoring one can never move another. Every dollar constant is fit to a ground-truth panel of known-revenue apps, and each tier's published ± band is its own measured error — tight where the model is accurate, wider on the modeled tail.
• Paid apps → price × downloads × 70% (developer share).
• Off-store revenue is flagged, never fabricated. Ad-funded, web-subscription, and external-billing revenue is structurally invisible to store-IAP data. An app with real downloads but no store IAP and no grossing presence is labeled ad-/off-store-unmodeled rather than given a confident number — so a web-billed giant (e.g. Spotify on iOS, which removed in-app billing) correctly reads near $0 of store-gross, not a fabricated figure from its download size.

Conversion rates are seeded from a published industry subscription-benchmark report. The per-category revenue-per-download multiplier, the grossing-curve exponent, the per-category scales, and the storefront weights are all fit empirically (see §5) and live in data/revenue-calibration.json, which this page reads from directly.

Every assumption is measured against ground truth, not left to faith:

• Downloads are calibrated against Google Play's public install buckets for cross-listed apps → global scale ×1.03.
• Revenue is fit empirically — not hand-picked — against a 54-app ground-truth panel whose revenue is publicly reported (press coverage, company disclosures, and public app-intelligence estimates), spanning both ends of every well-covered category: top earners (ChatGPT, Disney+, Tinder, …) and the tail/emerging end. A coordinate-descent harness fits the curve exponent, per-category scales, and storefront weights, with empirical-Bayes shrinkage so sparse categories lean on a prior instead of over-fitting one data point.
• A validation gate guards every recalibration. Before any new fit ships it must clear, per app-size class, ≥70% of estimates within 3× and no anchor off by more than 5×, plus a corrupt-anchor integrity check — otherwise the harness refuses to write. Categories with only one grossing anchor revert to a prior and are surfaced at low confidence rather than shown as precise.

The category conversion rates are seeded from a published annual industry subscription-benchmark report (a public benchmark, refreshed when new data is published) — and the calibration above corrects whatever bias those seeds introduce. So they start as documented snapshots and become data-fit.

The model improves on four axes, in priority order:

• More revenue anchors — every reliable (app, revenue) pair added to the calibration set tightens accuracy. This is the highest-leverage lever.
• Rating-velocity history — as daily snapshots accrue, current-month downloads come straight from Δratings (no lifetime-÷-age approximation).
• Real billing periods — the one input Apple's public listing hides; sourcing it (e.g. the storefront API) would remove our biggest revenue assumption.
• More countries — multi-storefront charts replace the worldwide approximation with measured per-country data.

A 0–100 composite used for the Trending lens, weighting newness 35%, momentum 30%, monetization 20%, and reach 15%. It deliberately favors recent, monetizing risers over established incumbents — the opportunity window.

• Not official Apple figures, and not panel/SDK-measured like enterprise tools. Directional — most figures land within ~2–3× of actual, but roughly one in four can be further off. We don't hide that: every estimate carries a low / medium / high confidence tag and a band, and thinly-anchored categories read low.
• Store-IAP scope only. We model what flows through App Store / Play in-app purchases. Revenue billed on the web, through ads, or via external processors is invisible to this data — we flag those apps rather than guess, so a number here is a floor on a web-heavy business's total revenue, not its whole.
• The tail is the hardest part. An app that charts its category is sized off that category rank; one that charts nowhere is sized as downloads × a per-category revenue-per-download — so a specific app can monetize well above or below its category, and these read at low confidence with wide bands. A large app whose overall rank isn't captured reads bounded at the top of its category's validated range (it could be larger), and an app that monetizes off-store (web, ads, external billing) is flagged rather than guessed. We deliberately don't use posted prices to narrow any of this (they don't predict revenue). This is the largest remaining source of per-app error.
• Monthly ≈ lifetime ÷ age. Worldwide downloads are anchored on global ratings, but amortizing lifetime installs over app age understates fast-growing apps and overstates declining ones until we have enough rating-velocity history to measure the current month directly.
• Best for relative comparison and finding opportunities — not for treating any single number as exact.