Apple moved the price. It did not move yours

What app store pricing changes, and on which day#

Two separate app store pricing events happened, a fortnight apart, and conflating them is the fastest way to make the wrong decision. On 27 August, per Apple's own developer news post, developer proceeds fell in three countries because those countries changed their tax: Morocco introduced value added tax at 20 per cent, the Republic of the Congo introduced it at 18 per cent, and Tanzania raised its digital sales tax from 2 to 3 per cent. That happened immediately.

The second app store pricing event happens on 14 September, when Apple updates app store prices by country in four storefronts: Israel, Indonesia, Morocco and the Republic of the Congo. Israel and Indonesia are on that list without a corresponding proceeds change, which is worth noticing, because it means the repricing list and the tax list are not the same list.

Both lists are produced by the same machinery. Apple's equalised pricing model sets one price on your base storefront and derives the rest, and the update mechanism explains how those derived prices are refreshed when a rate moves. That automation is the whole subject here: app store pricing in 174 storefronts is not 174 decisions, it is one decision and a conversion table, until the day the table updates itself.

The two names on the repricing list without a matching tax change are worth a moment. Apple's own documentation says it initiates retail price changes for tax movements and for significant foreign exchange movements, and only the tax half of that has been announced this week. The reasonable inference, and it is an inference rather than something Apple has stated, is that Israel and Indonesia are on the list for currency reasons rather than fiscal ones. Anyone selling meaningfully into either should treat the 14 September date as a currency event and check the direction of the move, because a repricing driven by a weakening currency lands very differently from one driven by a new tax.

Apple also names three exclusions from the 14 September app store pricing update, and they matter more than the headline. Prices will not change on your base storefront. They will not change where you manually manage prices rather than using automated equalised prices. And, in Apple's own flat phrasing, prices "won't change in any region if your In-App Purchase is an auto-renewable subscription".

The carve-out, in Apple's own words#

That third exclusion is not a footnote, and Apple has documented the reasoning elsewhere with unusual clarity. It is the hinge the whole app store pricing question turns on. The App Store Connect help page on subscription pricing states it directly: "Apple will not make price adjustments on your auto-renewable subscription products", and that retail price changes Apple initiates because of tax movements and significant currency swings "will exclude auto-renewable subscriptions".

The same page is equally clear about what does still change. "For any value-added tax (VAT) rate changes, your proceeds and Apple's commission will be calculated after the deduction of VAT, which means that your proceeds will change." The tax comes off the top either way. What Apple withholds from subscriptions is only the automatic retail adjustment that would pass that cost to the buyer.

Apple's subscription model treats a subscription as a relationship rather than a transaction, and its app store pricing rules follow that framing: a renewal price is something a subscriber agreed to, not a number to be adjusted underneath them. Then comes the sentence that hands the decision back: "You can choose to pass any changes caused by taxation or foreign exchange onto your subscribers by adjusting the price for your subscription." Choose. Which is generous framing for a choice between absorbing a tax rise and asking an existing subscriber to accept a higher renewal, a request that reliably costs some of them.

App store pricing defaults decide who actually pays#

Follow the scent through the whole burrow and the app store pricing pattern is consistent. Apple's commission is calculated after tax is deducted, so on a VAT introduction the developer's take falls whatever the product type. What differs is the recovery route.

Those figures are modelled rather than published. Apple does not release a per-country proceeds table, so the chart above applies the standard 70 per cent share to a ten dollar sale and lets the stated tax rates do the rest. Read it for the shape, not the decimal. The terms governing that split live in the Paid Applications Agreement, which Apple says it is updating to reflect the new collection duties in Morocco and the Republic of the Congo. Developers on the App Store Small Business Program, or in the second year of a subscription, keep 85 per cent and see a proportionally smaller bite.

Which brings us to the question every app store price developer eventually types into a search box. Does apple still take 30% from the app store? For most paid apps and one-off purchases, yes, that is still the standard commission, reduced to 15 per cent under the small business programme and on subscriptions after a subscriber's first year. The tax sits outside that split and is deducted before it.

What the research says a forced price rise costs#

There is a neat piece of published work on exactly this app store pricing mechanism, and its identification strategy is almost comically well suited: it uses Apple's own tax-driven and currency-driven price adjustments as the exogenous shock. Enache, Friberg and Wiklander, in the International Journal of Industrial Organization in 2023, studied five freemium mobile games across six European markets, exploiting the fact that the same titles ran on both Apple and Google with price changes on only one platform.

Their headline finding, in the paper's own words: "Our main identification comes from exogenous adjustments of Apples prices in 2021. Own-price elasticities of conversion are in the -1 to -4 range." Demand, in other words, is elastic. A price rise costs more than proportionally in conversion, which is precisely what an automatic repricing does to a one-off purchase on 14 September.

The authors also found that watching rewarded video moved with in-app prices at an elasticity of roughly 0.5, while overall play was unaffected. Monetisation behaviour is sensitive to price; engagement is not. For anyone modelling in app purchase pricing across a portfolio, that split is the useful part of the app store pricing picture, because it says the damage lands on conversion rather than on retention.

Set that against the subscription carve-out and the app store pricing trade becomes legible. One-off purchases take an elastic conversion hit and the developer keeps their margin. Subscriptions keep their conversion and the developer takes the margin hit. Neither is free. Apple has simply chosen which cost each product type pays, and it has chosen the quieter one for subscriptions.

What to settle before the fourteenth of September#

None of this is an emergency, and the markets involved are small for most catalogues. Apple's developer news feed is where the announcement will sit alongside the next one, and there is always a next one.

It is, though, an app store pricing decision with a deadline attached, and deadlines are the only reliable way anything gets priced properly. Two weeks is enough time to do it deliberately rather than discover it in a payout statement in October.

Check first whether any of the four storefronts is your base storefront, because if it is, nothing moves there and the rest of this is somebody else's problem. Then separate your catalogue into one-off purchases, which will be repriced for you, and subscriptions, which will not. Only the second list needs a decision.

Then set a rule for next time, because there will be a next time: tax rates move somewhere every quarter, and each move sends a fresh app store pricing notice into a developer inbox that is already full. A standing policy, written once, beats a fortnight of debate twice a year.

For that second list, the honest question is not whether to pass the tax on. It is whether your current price was ever the right one. A subscription whose price has not been examined since launch is not being protected by this carve-out; it is being preserved in amber by it. Use the deadline as the prompt it is, and set app store pricing that reflects what the product is worth in that market rather than what an exchange-rate table produced three years ago.

A fox does not chase every rustle in the hedgerow. It works out which ones are worth the run, and it keeps to the trail it chose. Three small markets and a fortnight's notice is a small rustle in the undergrowth, but the habit it should build, of app store pricing on purpose rather than by default, is the quarry worth the prowl across every storefront you sell in.

Frequently asked questions#