“iOS users spend more” is the most repeated and least examined sentence in mobile marketing. It gets quoted as a vibe. It is actually a division problem — and the answer is much larger than the number people quote.
Here is the version everyone knows. In 2025, the Apple App Store generated roughly $117 billion in consumer spend. Google Play generated roughly $49 billion. That is about 2.4× more money, and it is where most decks stop.
Here is the version that matters. Across both stores, users downloaded roughly 142 billion apps in 2025, and close to three times as many of those downloads happened on Google Play. Which means the App Store earned 2.4× the revenue from roughly a third of the volume.
Do the division and the picture stops being a 2× story.
01The two numbers that define mobile
Two aggregates, both public, both for 2025:
$117B
App Store consumer spend
$49B
Google Play consumer spend
~3×
Play downloads vs App Store
The temptation is to reach straight for the revenue ratio, call it 2.4×, and move on. But revenue ratios describe stores. Acquisition teams do not buy stores. They buy users, one at a time, at a price. To price a user you need the per-unit number — and neither Apple nor Google publishes it.
02The derived number neither store publishes
So derive it. If Play took roughly three downloads for every one on the App Store, and the two together came to about 142 billion, the split lands near 106 billion for Play and 36 billion for the App Store. Divide each store's consumer spend by its own downloads:
| Metric (2025) | Apple App Store | Google Play |
|---|
| Consumer spend | ~$117B | ~$49B |
| Downloads (derived from the ~3:1 split) | ~36B | ~106B |
| Consumer spend per download | ~$3.30 | ~$0.46 |
| Ratio | ≈ 7× in the App Store's favour |
→ HOW FIRM IS THIS NUMBER
It is an estimate, and we would rather say so than round it into a headline.
The $117B, $49B and ~142B figures are published aggregates. The 36B/106B split is derived from a stated “close to three times” relationship, not from two separately published download counts, so the per-download figures carry that imprecision. Move the ratio to 2.5:1 and the gap narrows to about 6×; move it to 3.5:1 and it widens past 8×. The conclusion is robust across that whole range, which is the only reason we are willing to build on it. Treat “roughly 7×” as an order of magnitude, not a decimal.
This is the number that should be sitting at the top of your acquisition model, and for most teams it is nowhere in the building. It reframes the central question of iOS buying. The question is not “why is my iOS cost per install so much higher than Android?” The App Store install is a different unit of value. Paying the same for both would be the anomaly.
~7×
Estimated consumer spend per download, App Store versus Google Play, derived from 2025 published aggregates. The revenue gap everyone quotes is 2.4×. The per-user gap is the one you bid against.
03Where the gap is widest
Store-level averages hide the interesting part. The Q2 2025 category splits are sharper than the blended figure:
| Q2 2025 | App Store share of downloads | App Store share of revenue | Divergence |
|---|
| Mobile games | 14.5% | 63.2% | 4.4× |
| Non-gaming apps | 28.3% | 73.0% | 2.6× |
Games are the extreme case: fewer than one in seven downloads, and close to two-thirds of the money. If you run a games portfolio and your media mix is weighted by install volume, you have systematically underweighted the platform that produces almost all of your revenue. The mechanism is the same one we described in the iOS versus Android ROAS comparison — install parity and revenue parity are not the same target, and optimising toward the first actively moves you away from the second.
04Why search intent compounds the audience effect
If the story ended at “iOS users spend more,” every iOS channel would be equally attractive. They are not, and the reason is placement.
The App Store is not a feed. It is a search engine that happens to sell software. Apple's own published figures put the storefront at over 800 million weekly visitors, with more than 85% of visitors downloading at least one app per visit, and nearly 65% of downloads happening directly after a search. Ads in the premium top-of-search position convert at approximately 60%.
Sit with that last figure for a moment. A 60% tap-to-install conversion rate is not a performance-marketing number. It is a distribution number. There is no other paid placement in mobile where the majority of people who touch the ad complete the conversion, and the reason is that the user typed the query. They arrived having already decided what category of thing they wanted.
A high-spending audience gets you a good ARPU. A high-spending audience caught at the exact moment of stated intent gets you a good ARPU and a good conversion rate. The two multiply, and that product is the entire economic case for Apple Ads.
This is also why a broader, lower-intent expansion of Apple's inventory would not inherit these economics — a point we go into in our read of the July 2026 terms change. Abundant inventory and scarce intent are not the same product, whoever is selling it.
05What you can therefore afford to bid
Here is where the arithmetic becomes operational. Most teams set an Apple Ads bid ceiling by looking sideways at a benchmark. That is backwards. Your ceiling is a function of your own economics, and it only needs three inputs:
| Input | Where it comes from |
|---|
| R — revenue per install at your payback horizon | Your own cohort data at day 30, 60 or 90. Not LTV. Not a projection. |
| C — tap-to-install conversion rate | Apple Ads reporting, per ad group. Top-of-search runs far above account average. |
| M — target payback multiple | Your finance function's number, not marketing's. Commonly 1.0–1.5× at the chosen horizon. |
Then: max cost per tap = (R × C) ÷ M
Worked through: an app earning $9.00 per install by day 30, converting at 55% on an exact-match branded cluster, against a 1.2× payback target, can afford (9.00 × 0.55) ÷ 1.2 = $4.13 per tap. That is roughly double the highest published US average cost per tap — and it is a perfectly rational bid, because the average is describing a different app with different economics.
The same formula run on a discovery cluster converting at 18% gives (9.00 × 0.18) ÷ 1.2 = $1.35. Same app, same day, same store, ceilings three times apart. Any single account-level bid cap you set is simultaneously overpaying on one of those clusters and underbidding the other into invisibility. This is the failure mode our 10-point ROAS audit finds most often, and it is nearly always worth more than any creative change.
→ FREE 10-POINT AUDIT
Find out what you can actually afford to bid
We take your day-30 revenue per install, your real conversion rates by cluster, and your payback target, and hand you the ceiling for each. One hour. Senior strategist. No pitch.
Book my free audit →
06Why the public cost datasets disagree
If you go looking for “average Apple Ads cost per tap,” you will find three respectable vendors publishing three different answers for overlapping periods. Published US cost-per-tap figures from Adapty, AppTweak and SplitMetrics span roughly $1.58 to $2.25.
None of them is wrong. They are measuring different populations:
- Panel composition. Each vendor's number is an average across its own customer base. A panel weighted toward finance and dating apps prices differently from one weighted toward utilities and casual games.
- Category mix. Cost per tap varies by more between App Store categories than it does between these three vendors' headline figures.
- Match-type mix. Panels heavy on branded exact-match traffic report lower costs and higher conversion rates than panels running broad discovery.
- Recency. The March 2026 multi-slot expansion changed auction density mid-year. Any dataset spanning that boundary is averaging across two different markets.
→ THE FIX
Use benchmarks to detect anomalies, never to set bids.
A published average is useful for one thing: if your cost per tap is 4× the range, something is broken and you should go look. It is useless for deciding what to pay, because it contains no information about your revenue per install. The formula in section 05 contains nothing but information about your revenue per install.
07Proving it inside your own account in 30 days
You do not have to take the store-level arithmetic on faith. Run the comparison on your own data, and design it so it cannot be won by the cheaper channel on a technicality.
Step 1 · Fix the denominatorReport revenue per cohort, not cost per install
Pick a horizon — day 30 is the usual compromise between signal and patience — and build one table with a row per acquisition source and exactly two columns: spend, and revenue from the cohort that source delivered. No installs. Removing the install count from the report removes the metric that has been doing the misleading, an argument we made at length in the death of CPI.
Step 2 · Match the windowHold creative and season constant
Compare a 30-day Apple Ads window against the same 30 days on your largest Android source. Do not compare a summer iOS test against last winter's Android baseline, and do not run the test through a major creative refresh on one side only.
Step 3 · Separate the clustersSplit brand, category and discovery
Blending branded and discovery keywords into one Apple Ads number will make the channel look artificially cheap and artificially high-converting, because branded traffic is neither. Report all three separately or the test tells you nothing you can act on.
Step 4 · Read the right signalExpect both numbers to be higher
The result you are looking for is the one that feels contradictory at first glance: Apple Ads showing a higher cost per install and a higher day-30 revenue per install at the same time. That combination is not a problem to be solved. It is the store-level arithmetic showing up in your own account, and it means your install-denominated reporting has been mispricing the channel for as long as you have been running it.
Everything else — bid strategy, match types, Custom Product Pages, whether to trust Maximize Conversions — follows from getting this one comparison right. If you are still deciding budget splits on cost per install, you are allocating against a unit that is worth roughly seven times more on one side of the ledger than the other, and calling the two numbers comparable.