Shopify does not publish what its apps earn — but you can estimate it. Every app on the store exposes two public numbers that, together, are enough to reverse-engineer a credible revenue range: its review count and its pricing. This article gives you the formula, applies it to a real app, and benchmarks low/high monthly revenue across the biggest categories. None of the numbers below are official. All of them are estimates — and that is exactly why they are useful before you decide what to build.
Short answer: the revenue distribution is brutal
Before any formula, internalize the shape of the market. App Store revenue follows a punishing power law, and review count is the cleanest public proxy for where an app sits on it:
- Under 100 reviews — hobby zone. The vast majority of apps live here. Most never clear a few hundred dollars a month. Some are abandoned; some are deliberately tiny.
- 100–1,000 reviews — ramen to real business. This is where a focused solo developer or small team starts earning a living. Estimated revenue spans roughly four figures to low five figures monthly.
- 1,000–10,000 reviews — serious business. Category contenders. These apps fund teams, and the better ones throw off mid five to low six figures a month.
- 10,000+ reviews — top 1%. A handful of category kings per vertical. Seven-figure-plus annual revenue, often acquisition targets.
The takeaway: most apps make little, a few make a fortune, and the gap between them is decided long before launch — in the choice of category and the gap they attack. Browse any vertical at AppAnalizer sorted by reviews and the cliff is obvious within seconds.
The formula: estimate any app's revenue
Two public inputs, three multipliers, one rule: always produce a range, never a single fake number.
Step 1 — installs from reviews. Only a small fraction of merchants ever leave a review, so reviews undercount installs by a large factor:
installs ≈ reviews × R (R = 50–100)
Step 2 — revenue from installs. Not every install pays, and those that do pay somewhere between the entry plan and the average plan price:
MRR ≈ installs × P × price (P = 20–40%)
Step 3 — discount for churn. Reviews are cumulative — a merchant's review survives even after they uninstall — so an old app's review count still includes customers who left long ago. We discount toward the active base using a directional ~30%/year revenue churn, applied to the average customer's age (≈ the app's age ÷ 2):
active ≈ paying × 0.70^(app age in years ÷ 2)
Let's run it on a real, small app: Vario ‑ Variation Swatches by SeedGrow Apps, in the Product variants category. Public data: 36 reviews, a 4.9 rating, two paid plans at $9 and $19 per month (its only free plan is for development stores, so real merchants pay). Entry-to-average price ≈ $9–14, and it has been live since 2021.
- Installs ≈ 36 × (50–100) = 1,800 – 3,600
- Paying, before churn ≈ installs × (20–40%) × ($9–14) ≈ ~$3k – $20k / month
- Vario has been live ~5 years, so we keep ~41% of that base (0.70^(5÷2)): ≈ ~$1k – $8k / month
- That is roughly $16k – $99k per year — from an app with only 36 reviews.
The range is wide on purpose. A point estimate would be dishonest — but a range is enough to tell a hobby project from a business worth competing with.
Revenue benchmarks by category
Run the same formula across categories using each one's typical paid price, and the differences are stark. The table below estimates monthly revenue for an established-small app at roughly 100 reviews — a common milestone — using a conservative blended price per category. These are illustrative ranges, not quotes.
The lesson is not "always pick the most expensive category." High-price verticals are also the most crowded and the hardest to win. The point is that price per merchant is a structural lever: a niche where merchants happily pay $30/month needs a fraction of the installs to match a $5/month app. Weigh estimated revenue against how contested the category is — explore the field for any vertical under categories.
Why the pricing model changes everything
Two apps with identical review counts can earn wildly different amounts, because the pricing model decides what share of installs actually pays:
- Free apps — review count tells you nothing about revenue, because the answer is roughly zero (or it monetizes elsewhere). Exclude them from any earnings estimate.
- Paid apps (like Vario, whose only free plan is dev-store-only) — almost everyone who stays past the trial pays, so the paying share P sits at the high end. Fewer installs, but each one counts.
- Freemium apps — huge install and review counts, but a free tier that most merchants never leave. P collapses to the low end, so headline reviews badly overstate revenue.
When you estimate, always check the model first. Filter by it directly in paid apps versus freemium apps to see how differently the two monetize at the same scale. A freemium app with 5,000 reviews may quietly earn less than a paid app with 300.
Run the numbers yourself
You do not need our estimates — you need the method. Here is the workflow inside AppAnalizer:
- Open AppAnalizer and filter to the category you are researching.
- For each app, read the two public inputs: the review count and the paid plan prices.
- Apply the formula: installs ≈ reviews × (50–100), then MRR ≈ installs × (20–40%) × price, then discount for age with ×0.70^(app age ÷ 2) to reach the active base.
- Note the pricing model — discount freemium apps hard, trust paid-only ranges more.
- Export the filtered category to CSV and compute the range across the whole field in a spreadsheet to see where the revenue actually pools.
Treat every output as a range, sanity-check it against the review tiers above, and you will read the App Store the way an operator does — by the money, not the marketing. Start your free research session →