MARKET RESEARCH
Mobile App Market Size: Build a Bounded Bottom-Up Estimate
Learn how to estimate mobile app market size using bounded bottom-up cohorts, public store catalogs, and transparent hypothetical scenario models.
Estimating mobile app market size is often distorted by macro reports that lump entire app categories into giant revenue totals. For an indie developer or focused product team, a realistic market size requires a bounded bottom-up estimate built from observable store competitors, explicit coverage boundaries, and defensible scenario modeling.
At a glance
| Sizing component | Observation source | Analytical boundary |
|---|---|---|
| Sampled competitor cohort | iOS and Google Play store search and category listings | Captures visible specialized peers but misses unlisted, private, or web-only competitors |
| Gross in-app spend | Modeled store estimates and visible public in-app purchase tiers | Excludes external web checkouts, corporate billing, and mobile advertising revenue |
| Install volume proxy | Store download estimates and historical ranking trajectory | Uses the provider’s download definition; it does not establish unique users, active devices or retention |
| Scenario expansion multiplier | Explicitly stated hypothetical coverage assumption | Serves as an analytical boundary test rather than an empirical census of all niche apps |
Why top-down market sizing misleads app builders
Industry reports cite multi-billion-dollar figures for broad categories like Health or Productivity, aggregating brands, games, and enterprise software into a single number. For a team building a specialized mobile app, such macro numbers offer no practical guidance.
A useful estimate of mobile app market size answers a narrower question: what volume of demand and gross in-app spend flows through direct alternatives addressing your target problem? Grounding research in observable competitor data prevents assuming that capturing a small fraction of a giant category represents an achievable baseline.
Defining a bounded cohort of observable competitors
A defensible bottom-up model begins with a strictly defined cohort of observable competitors. Rather than pulling every app in a broad category, researchers identify titles a customer encounters when searching for specific solutions.
In AppGazers, builders query keyword results and category rankings across iOS and Google Play to assemble a documented sample of visible alternatives; search discovery alone does not make it representative.
When constructing this sample, record specific attributes to establish boundaries:
- Select eight to fifteen active peer applications solving the exact target problem.
- Verify cross-platform availability across both the Apple App Store and Google Play.
- Document visible monetization formats, separating one-time purchases from recurring subscriptions.
- Exclude broad incumbents whose mobile revenue primarily reflects external enterprise contracts.
Translating catalog estimates into bottom-up revenue ranges
Once the cohort is assembled, researchers extract observable signals. AppGazers provides modeled gross in-app spend estimates derived from public store rankings and catalog data. These figures represent gross in-app spend before platform fees, not audited corporate revenue, net profit, or advertising earnings.
Gross in-app spend excludes web checkouts, direct invoicing, and mobile ad networks. Summing compatible, deduplicated estimates yields a sample subtotal. It is not a verified floor: model error can overstate spend, overlapping editions can be counted twice, and relevant apps may be missing.
To explore sensitivity, apply explicitly hypothetical coverage assumptions and vary the underlying estimates as well. Search position does not reveal the percentage of niche spend represented by the sample; any proposed coverage share needs separate evidence.
Worked example: sizing a hypothetical specialty habit tracker niche
Consider an explicitly hypothetical market sizing exercise for a specialized habit tracker designed for rotating shift workers. Through store research, a team identifies exactly ten active competitors.
In this hypothetical scenario, observed monthly performance estimates break down across three tiers: two category leaders generate an estimated combined gross in-app spend of $45,000 monthly ($540,000 annualized); three mid-sized challengers generate an estimated combined gross in-app spend of $25,000 monthly ($300,000 annualized); and five niche utilities generate an estimated combined gross in-app spend of $10,000 monthly ($120,000 annualized).
Summing these tiers produces an observed sample gross spend of $80,000 monthly ($45,000 plus $25,000 plus $10,000), totaling $960,000 annually across the ten observed titles. Next, the team defines two explicit hypothetical scenarios:
In hypothetical Scenario A (conservative coverage), the team assumes these ten visible leaders account for eighty percent of niche spend. Total niche store spend is $80,000 divided by 0.80, yielding $100,000 monthly, or $1,200,000 annually. In hypothetical Scenario B (moderate coverage), the team assumes the cohort captures fifty percent of the niche due to unranked regional titles. Total niche store spend is $80,000 divided by 0.50, yielding $160,000 monthly, or $1,920,000 annually.
The $1,200,000 to $1,920,000 annualized range follows only from these invented inputs and a constant-month assumption. It is a sensitivity exercise, not a validated market boundary or forecast. Varying model error, seasonality and coverage could produce a materially different range.
Distinguishing catalog spend from TAM, LTV, and active users
Equating store catalog subtotals with total addressable market (TAM) or reach is a common error. Store downloads and gross in-app spend do not measure active users, sessions, retention, lifetime value (LTV), or customer acquisition cost (CAC).
Download, acquisition, install, redownload and update metrics have different definitions. Do not assume that an estimate includes or excludes a particular event unless its documentation says so. Developer consoles track active device counts, but external tools cannot access private telemetry. Active users and retention must be measured in your own console post-launch.
Using AppGazers to maintain a living market size model
Market sizing is not a static calculation. Competitors launch pricing tiers, release major updates, and shift rankings over time. To maintain an accurate model, save your competitor cohort into the AppGazers Your apps watchlist after signing in with Google.
Tracking this watchlist enables teams to monitor ongoing shifts in estimated gross in-app spend and rankings. When a new entrant ranks for primary keywords, add their metrics to your quarterly review to keep your model aligned with market reality.
Official sources reviewed
- Apple Developer In-App Purchase — Official documentation on store digital commerce and in-app purchase product types.
- Google Play Console Help: View app statistics — Official guidelines on first-party app statistics, install events, and active device tracking.
RESEARCH YOUR NEXT APP
Start with a niche. Leave with evidence.
AppGazers is free during beta. The research workspace opens after Google sign-in.
Explore rising apps