You are deciding what to charge, so you do the obvious thing and look at what the apps you compete with charge. On the App Store that check quietly fails, and not because the data is hard to find. The number you find is answering a different question from the one you asked.
Two findings, both measured rather than argued. Upfront price has almost disappeared from search results, so comparing prices compares nothing. And the price that actually matters — what a rival charges inside the app — is not in Apple's public API at all. What remains is still worth having, but it is a comparison of business models, not of price tags.
Upfront price is nearly extinct in search results
This site's monetization tool started life as a price comparison and could not stay one. Measured live against four cohorts, the apps charging anything upfront were: 0 of 20 for "pdf scanner", 0 of 22 for "weather", 1 of 23 for "calculator", and 0 of 25 in the Productivity cohort. One app in 90.
I re-ran the check while writing this, on 20 August 2026, against five terms in the US storefront, counting every software result with a price above zero. The pattern held: 0 of 21 for "pdf scanner", 0 of 22 for "weather", 1 of 23 for "calculator", 1 of 23 for "habit tracker", 0 of 21 for "photo editor". Two apps out of 110.
A dashboard built on Apple's formattedPrice field therefore reports that essentially every category is 100% free, and teaches you nothing. That is not a bug in the tooling. It is an accurate reading of a field that almost no longer varies.
The API has no field for any of it
The obvious next move is to ask Apple's public endpoints what the rivals charge inside the app. They do not carry it.
Checked live on 20 August 2026: a lookup response returns 44 fields, a search result 43. Filtering both key lists for anything matching iap, purchase, subscription or tier returns an empty set. The only money-related fields are price, formattedPrice and currency, and all three describe the install button and nothing else.
The consequence is sharper than it sounds. One app I sampled returns price: 0 and formattedPrice: "Free" while running an entire subscription business. Apple's API is not describing that app's monetization; it is describing what the Get button costs. "Free" is a fact about the install, and reading it as a fact about revenue is a category error.
The product page lists names, not prices
There is one place Apple does publish something: the web product page on apps.apple.com carries an "In-App Purchases" disclosure. Several tools advertise scraped competitor subscription tiers, and this disclosure is the only public place such a thing could come from, so it is worth seeing exactly what the list is before trusting anything built on it.
I read that list on 13 apps. It is capped at 10 entries. Apps with fewer than ten show their real count — I saw 2, 5, 5, 6 and 8 — but nothing showed more than ten, and eight of the thirteen sat at exactly ten. Any app with a larger catalogue is truncated there, and nothing on the page says it was.
The entries are display names chosen by the developer, and they repeat. One app listed ten entries under two distinct display names. Another listed ten under three. The list carries no duration, so you cannot tell a monthly from an annual from a one-time purchase. Each entry shows one price and nothing else — no indication of which product any given user is actually offered, which is the number you wanted. Introductory pricing, regional pricing and whatever the developer is currently testing on their paywall leave no trace in it.
So the list is real, and it is a list of product names. It is not a price structure, and it cannot be read back into one. Anyone reporting a competitor's subscription price as a single figure has picked one row out of a truncated, unlabelled list and called it the answer.
The four things Apple lets you sell
Apple defines four in-app purchase types in its App Store Connect help. They behave differently, and the public data distinguishes none of them.
| Type | What it is | In the public API | On the product page |
|---|---|---|---|
| Consumable | Used once, then depleted and bought again | Not present | Name and price, if within the first ten |
| Non-consumable | Bought once, does not expire with use | Not present | Name and price, if within the first ten |
| Auto-renewable subscription | Access for a set period; Apple's help says it "renews automatically unless cancelled by the user" | Not present | Name and price, if within the first ten |
| Non-renewing subscription | A service with a limited duration that does not renew | Not present | Name and price, if within the first ten |
Definitions from Apple's In-App Purchase types reference. The right-hand column is the same for every row, which is the point: the disclosure does not label the type, so an entry that looks like a subscription may be a one-off purchase and the other way round.
What is left to compare: the model, and one coarse rate
Strip out what is unknowable and something useful survives. For each app in a search result you can establish two things: whether it charges upfront (Apple's own field) and whether it sells in-app purchases at all (a third-party flag). That gives four buckets — free with no IAP, free with IAP, paid with no IAP, paid with IAP — plus a fifth that has to exist.
The fifth is unknown, and it is not a rounding detail. The in-app-purchase flag is documented as a boolean but arrives as an empty string for some apps. An empty value means the source did not answer, not that the app has no in-app purchases, so those apps go into their own bucket and are excluded from the denominator of every share. Filing them as "no IAP" would silently overstate how many rivals monetize nothing.
The second thing you can put a number on is revenue per install — a revenue estimate divided by a download estimate. Unlike most cross-source ratios, this one has matching units: both halves come from the same third party, the same worldwide window, the same 30 days. It is still two coarsely-rounded estimates — a live top-100 chart returned only 24 distinct download values across 100 apps — so it should be read as a bracket and never quoted to the cent.
It is also revenue before Apple's cut, and that cut is not one number:
| Situation | Apple's published figure | Source |
|---|---|---|
| Subscription, subscriber's first year | Apple states "you receive 70% of the subscription price at each billing cycle" | Auto-renewable subscriptions |
| Subscription, after one year of paid service | The developer's net revenue rises to 85% | Same page |
| Small Business Program | Commission reduced to 15% on paid apps and in-app purchases | Small Business Program |
Apple describes that last one as "a reduced commission rate of 15% on paid apps and In-App Purchases". It qualifies developers who made up to 1 million USD in proceeds in the prior calendar year, along with developers new to the App Store; passing that threshold moves future sales to the standard rate, and falling back under it lets a developer re-qualify the following year.
Read those three rows together and a further impossibility appears. To convert a rival's estimated revenue into what they actually keep, you would need to know their prior-year proceeds and how long their subscribers have been subscribed. Neither is public. Even the gross figure is an estimate, and the multiplier you would apply to it is unknowable.
What this cannot tell you
- What any competitor charges. Not the subscription price, not the tier structure, not the trial length, not the discount they are testing this week. It is not in the API, and the product page shows a capped list of display names.
- Which model is right for your app. A cohort sitting entirely on one model is a fact about the category, not proof the category is correct. Categories have converged on wrong answers before.
- What a rival keeps. The commission rate depends on facts about their business that are not published.
- Whether an upfront price would work for you. The measurement here says the pattern is rare, not that it fails. One of the two paid apps in the re-check first shipped in 2015, still charges upfront, and released an update the day before I ran the check.
- Anything about ranking. Apple publishes no factor linking monetization model to search position, so this post asserts none.
Nothing above tells you what to charge. It tells you what shape the competition is, which is a smaller claim and a true one.
Appstro's monetization mix runs this over the 25 apps in a search result — the model split, the unknown bucket kept separate, and revenue per install as a bracket. If you are working out whether to ask for money at all, the rating benchmark covers the adjacent question of whether the audience is engaged enough to ask.