Both platforms will quote you a cost per install for the same iOS app. Neither number means what the other one means.
This comparison gets written the same way every time: a two-column table, a handful of scraped benchmark figures, and a verdict. The table is the problem. Apple Ads and Google App Campaigns produce numbers that share a label and almost nothing else — not the auction, not the inventory, not the unit being billed, not the definition of an install, and on iOS, not even the count.
What follows is the comparison done honestly: what each platform sells, what each lets you control, what the published numbers do and do not support, and where the evidence runs out. Every figure is attributed with its methodology and vintage, because the methodology is the answer.
One word, two purchases
Start with the billing unit, because everything downstream inherits it.
Apple Ads bills per tap across its App Store placements. Cost per acquisition exists as a target you optimise toward on search results, not as the thing you are charged for. So any Apple Ads “cost per install” is derived: tap price divided by tap-to-install conversion rate. AppTweak’s 2025 dataset makes the arithmetic visible — a global search-results median cost per tap of $0.92 and a 56% conversion rate produce the $1.80 cost per install the same report publishes.
Google App Campaigns works the other way. You set a target cost per install or cost per action as a bid input, and Google buys toward it. The realised number is the outcome of an optimisation across mixed inventory, not a posted price on a placement.
One platform reports the price of a thing you bought. The other reports the average outcome of a target you set. Subtracting one from the other produces a number with no meaning.
This is the same failure that makes install-denominated bidding misleading, which we cover in the case against cost per install as an optimisation target. Here it shows up one level higher, in cross-platform planning rather than in-platform bidding.
What you actually buy in each auction
Google’s documentation is direct about the control surface: “Google Ads will test different ad combinations and serve the best-performing ads.” You supply assets — up to 10 text, 20 image and 20 video assets per ad group, plus 20 HTML5 or playable assets for game marketers — a budget, a target, geography and language. Google assembles the ads, chooses the inventory, and sets the price.
The inventory list is the crux. Google names it plainly: “Search, YouTube, Google Play, Discover on Google Search, the Google Display Network, and AdMob along with many more publishers who host app ads.” The only negative control documented is at account level: “If you want to prevent ads from appearing on specific unwanted sites or apps, use account-level placement exclusion lists.”
Apple Ads exposes a different set of levers entirely: keyword targeting with match types, bids set at the keyword level, opt-in per placement, and pause or activate control down to the individual keyword.
| Control | Apple Ads | Google App Campaigns |
| Keyword targeting | Yes — match types, keyword-level bids | No keyword targeting in App Campaigns |
| Placement selection | Opt in or out per App Store placement | No selection; account-level exclusion lists only |
| Creative control | Ad variations, custom product pages (up to 70 per app) | Assets supplied; Google assembles and rotates the ads |
| Billing unit | Per tap (cost per install available on some placements) | Against a target CPI or target CPA bid |
| Inventory breadth | Four placements, all inside the App Store | Six-plus surfaces spanning search, video, store and in-app |
| Granular pausing | Keyword level | Campaign and ad group level |
The breadth row is where the blended average breaks down. An App Campaigns cost per install is one number averaged across at least six structurally different auctions: keyword-intent Search, store-browse Play, video-interruption YouTube, feed-based Discover, and rewarded or interstitial in-app inventory through AdMob. A user who taps a rewarded video in a puzzle game and a user who searches Google for your category are not the same purchase, and averaging their prices describes neither.
Apple’s four placements sit inside one store, all reached by people already in a buying context. That does not make them better — it makes them comparable to each other, which the Google blend is not.
→ THE PLANNING ERROR
Treating breadth as an efficiency advantage
A lower blended cost per install across mixed inventory is not evidence of a cheaper user. It is frequently evidence of a heavier weighting toward the cheapest and lowest-intent surface in the mix. Ask what the mix was before you ask what the price was — and note that App Campaigns does not report it in a way that lets you decompose it.
The published numbers, and why the table lies
Here is what is actually published, with methodology attached. Read the right-hand column before the middle one.
| Source | Headline figures | Methodology and vintage |
AppTweak Apple Ads |
Global search results: CPT $0.92, CPI $1.80, CR 56%, TTR 7.4%. US: CPT $1.91, CPI $4.06. |
Medians. ~3,500 apps, 50,000 campaigns, $1B spend, calendar 2025, 38 countries, 14 categories, all four placements. Updated 20 Aug 2026 — the data is 2025. |
SplitMetrics figures via Singular Apple Ads |
TTR 9.7%, CR 66.2%, CPT $2.25, CPA $3.76. |
Averages, own-platform data, global, aggregated across 2025. Note these are SplitMetrics’ own numbers carried inside Singular’s index — citing both is citing one source twice. |
Business of Apps cross-platform |
iOS $1.50–$3.50; Android $1.50–$4.00; Google Ads $0.50–$2.50; North America $2.50–$5.00. |
Ranges, not statistics. No sample size, no period, no methodology stated; last updated 27 Feb 2025. Cites other vendors second-hand. |
The Business of Apps row ends up in most comparison posts because it is the only page that puts Apple and Google numbers side by side. It should not be used that way. A page giving iOS a $1.50–$3.50 range and Google Ads a $0.50–$2.50 range is not comparing two things — Google Ads runs on iOS too, so the ranges describe overlapping populations cut on different axes, one by operating system and one by network, with no sample disclosed for either.
Meanwhile the two Apple Ads datasets that do publish methodology disagree by nearly 2.5× on cost per tap — $0.92 against $2.25 — for reasons that are entirely explicable once you read the methods: medians against averages, a broad panel against one platform’s own clients, global mix against a top-markets mix. We took that apart figure by figure in the 2026 Apple Ads benchmark analysis. Neither is wrong, and neither is a bid.
No vendor has closed the other gap. Multi-slot search results — up to two ads per query — completed their global rollout at the end of March 2026. Every dataset above describes a one-ad-per-query auction. Tap-through rate is the metric most exposed, and Apple publishes no slot-level impression share, so a decline cannot be diagnosed as creative fatigue versus second-position delivery.
→ THE RULE
Never compare a median to an average to a range
If three numbers are computed three ways over three panels in three periods, the differences between them measure the methods, not the markets. Before any cross-platform figure enters a plan, write its denominator, its statistic and its date next to it. Most of them will not survive the exercise.
On iOS, Google reports three install counts
This is the part most cross-platform comparisons skip, and it is what makes a like-for-like cost comparison impossible in principle rather than merely difficult in practice.
On iOS, Google App Campaigns produces measurement through parallel systems that do not agree by design:
- Modelled conversions in Google Ads. Google applies “advanced Google modeling to estimate event level performance” for users globally, with reporting delays of up to five days.
- SKAdNetwork postbacks, reported separately and “subject to variable delays,” constrained to 64 conversion values. Google states it uses fine conversion values only: “We currently do not support SKAN version 4’s coarse conversion values.”
- Null postback imputation. Where a postback arrives without a value, Google says: “We predict the conversion values to replace Null values using an inferred value distribution, which is given by a machine learning model, continuously trained on recent SKAN postback data.”
- Your MMP’s number, which is different again — because app attribution partners “don’t receive attribution claims on modeled conversions” at all.
Google’s documentation describes the resulting discrepancies as normal and expected — a fair description, not a criticism. But it means the denominator in a Google iOS cost per install is a modelled estimate blended with imputed postback values, and which of the three numbers you divide spend by changes the answer.
Apple Ads sits on a different measurement footing. AdServices uses Apple’s first-party data and returns attribution at campaign, ad group, keyword and placement level. The tracking-consent state affects the payload but not the attribution: a denied prompt yields a standard payload without click or impression timestamps, while a granted prompt adds them, rounded to the minute — a point we unpacked when Germany’s competition authority made Apple’s ATT commitments binding in August 2026. There is no modelling layer between the tap and the count.
The operational consequences run deeper than reporting aesthetics. Because App Campaigns depends on aggregated postbacks, Google publishes volume floors that function as minimum viable scale: a daily budget “at least 50 times your target CPI,” or “at least 10 times your target CPA” for in-app action campaigns; an in-app action “completed by at least 10 different users per day”; and for the SKAdNetwork schema, “more than 10 conversion events per day” with a goal of “around 50 installs per day.” Google further recommends consolidating “to 8 or fewer app install campaigns for each iOS app.”
Read that as an architecture constraint, not advice. App Campaigns needs concentrated volume per campaign to function on iOS, the opposite of what granular structure requires. Apple Ads goes the other way — brand, category and competitor separation with keyword-level bids is the standard shape precisely because the reporting supports it.
→ FREE 10-POINT AUDIT
Find out which channel is actually buying your payers
We open your Apple Ads account, reconcile it against your MMP and your Google App Campaigns reporting, and show you where the same install is being claimed twice and what your real blended cost of an acquired payer is. One hour. Senior strategist. No pitch.
Book my free audit →
The store economics underneath
Cost comparisons are only half of any channel decision. The other half is what a user from each store is worth, and here the gap is not subtle.
Business of Apps puts 2025 consumer spend at roughly $117B on iOS against roughly $49B on Google Play, and 2025 downloads at 36.6B on iOS against 104.6B on Google Play. Dividing one by the other gives revenue per download of about $3.19 on iOS versus about $0.48 on Google Play — a ratio near 6.7×.
≈6.7×
Derived, not reported. Consumer spend per download, iOS versus Google Play, computed from two separately sourced 2025 aggregates. The order of magnitude is the finding; the decimal is not defensible.
The caveats travel with the figure, because the underlying aggregates are contested. Sensor Tower’s State of Mobile 2026 puts combined 2025 consumer spend at $167B across 149B downloads, with exclusions stated plainly: Android estimates cover the Google Play Store only, and in-app purchase revenue excludes advertising and third-party purchases. Appfigures, via TechCrunch in January 2026, puts the same year at $155.8B and only 106.9B downloads — roughly 42B fewer downloads and $11B less spend, for the same twelve months.
When two panels disagree by 28% on the denominator, any per-download figure from either is an estimate with a wide interval. What survives is the direction: iOS is a minority of downloads and a clear majority of spend, on every panel, every year. That asymmetry is the whole economic case for buying iOS users at prices that look expensive in a cross-platform table, and why an iOS-only channel should never be judged against a blended benchmark that includes Android inventory.
One live variable worth tracking: Apple’s unified EU business terms take effect on 1 October 2026, changing net revenue per download for EU storefronts. Any per-download economics you compute now has an expiry date in one region.
What the only head-to-head evidence says
There is less direct evidence than most comparison articles imply. Two datasets are worth taking seriously, both with panel limitations their publishers state openly.
AppsFlyer’s Performance Index 2025, published 3 December 2025, covers 16.2B non-organic installs across roughly 39,000 apps. On iOS, Apple Ads ranks first in both gaming and non-gaming; in iOS non-gaming the order runs Apple Ads, Meta, TikTok, then Google Ads fourth. On Android, Google Ads ranks first in both. The limitation is structural: the index reflects AppsFlyer’s own client base, and its iOS rankings depend on a single-source-of-truth layer that de-duplicates SKAdNetwork against deterministic attribution.
Singular’s ROI Index 2026, covering 2025, introduced multi-touch attribution leaderboards including an “Exclusive Reach” view — installs where a network was the only engagement in the path to attribution. Apple Ads appears on it. Singular reports that under multi-touch attribution some platforms show up to 50% higher ROAS than last-touch, and states that “the findings are drawn from the company’s own client base.”
One distinction is routinely collapsed: exclusive reach is not incrementality. Being the only touchpoint means no other network claimed a touch. It does not establish that the install would not have happened anyway. On App Store search, where the user has already typed your category or your name, the counterfactual — would this person have found you organically? — is exactly what exclusive reach cannot answer.
The honest headline: no published incrementality study compares Apple Ads and Google App Campaigns on iOS. Every available ranking measures who claimed credit inside a vendor’s client base, not who caused what.
Running both without paying twice
Most apps at meaningful scale run both, and that is usually correct — they intercept demand at different moments. The risk is not auction overlap. It is reporting overlap.
Step 1 · ReconcileAgree on one install count before comparing costs
Pick a single system of record — usually the MMP — and compute both channels’ costs against its numbers, not against each platform’s self-reported conversions. Expect the Google Ads figure to exceed it, because modelled conversions never reach your MMP.
Step 2 · SeparateNever compare an iOS-only channel to a blended one
If you benchmark Apple Ads against an App Campaigns number that includes Android, you are comparing a high-spend audience to a mixed one. Split App Campaigns reporting by platform first. If you cannot split it, do not run the comparison.
Step 3 · DecomposePush past the blended cost per install
Ask what share of App Campaigns delivery came from search-intent surfaces versus in-app rewarded inventory. You will often find you cannot answer precisely — and that inability is itself the finding, because it means the blended price is not actionable.
Step 4 · TestBuy the counterfactual, not the report
Geo holdouts and structured pause tests remain the only way to establish whether either channel is incremental. They are cheap relative to what they resolve, and they are the only evidence in this entire article that would be generated by you rather than by a vendor panel.
Step 5 · MonitorWatch the control surface, not just the price
Both platforms change what you can control more often than they change what they charge. On the Apple side, the Platform API migration ahead of the January 2027 sunset alters what your reporting stack can read, and creative approval is a live dependency with no published SLA. Price is the visible variable; control is the one that determines whether you can act on price.
What nobody has published
The gaps here are wide enough that any confident verdict should be treated as marketing.
No incrementality study compares the two channels on iOS. No vendor publishes per-cell sample sizes, so a category-and-country median may rest on thousands of campaigns or a dozen. No public Apple Ads dataset covers the post-multi-slot auction, and Apple provides no slot-level impression share to diagnose one. Google publishes volume floors and modelling descriptions but no accuracy interval for its modelled conversions, so the gap between its number and your MMP’s can only be observed, not characterised. On Google’s support of Apple’s newer attribution framework for third-party networks, the App Campaigns help pages say nothing either way — an absence reported as an absence.
The store aggregates disagree by tens of billions of downloads, and the most widely quoted consumer-spend split comes from a page that does not disclose its source. Neither platform publishes what share of its delivery is incremental, and neither has any reason to.
What survives is small and durable. Apple Ads sells taps against declared intent inside the store where the purchase happens, whose users spend several times more per download. Google App Campaigns sells reach across a far larger and more varied surface, with less control and, on iOS, a measurement layer that is modelled rather than observed. Those are different instruments. Run both if the scale justifies it — but price them separately, judge them on a common install count, and stop putting them in the same column.