Where a Price Rise Needs a Yes: Apple's Consent Map

The version of this rule circulating in developer conversations has the wrong year and the wrong map. Before you re-plan a price increase around it, it is worth getting both right — because the correction changes who is affected, and the real mechanic underneath is more interesting than the headline.

The correction first: 2025, and three storefronts

The subscription price-increase consent rule took effect August 4, 2025, not 2026. 9to5Mac reported it as forthcoming on 16 May 2025, ASO World states the year explicitly, and App Store Connect release notes already describe it in the past tense.

Apple’s own transition language proves the year. Increases with a start date before the cutoff keep the previous criteria “even if the renewal occurs after August 4 (for annual subscriptions, renewal could be as late as August 2026).” An annual renewal landing as late as August 2026 only parses if the cutoff was August 2025.

The scope correction matters more. Apple’s sentence is geographically bounded: Austria, Germany and Poland. It is not a worldwide change. Every other storefront still runs the older threshold regime, unchanged. If you publish a post — or a pricing memo — asserting a global consent requirement, a German product owner will catch it in the first paragraph, because they are the one person for whom it is actually true.

One sourcing caution while we are here. The developer news URL commonly passed around with this rule (?id=wim4cztw) surfaces the consent text, but its body is the May 2025 tax and price post — Brazil CIDE, “44 currencies.” Apple’s January 2026 post says 43 currencies, so wim4cztw predates it. Cite Apple’s subscription pricing help page, not a news post ID.

Regime A: Austria, Germany and Poland

In those three storefronts, a price increase on an active subscription requires each affected subscriber to affirmatively agree to the new price. There is no size below which you can raise quietly.

The framing that helps here: Austria, Germany and Poland did not invent a new mechanism in 2025. Apple already had a consent flow — it was reserved for large increases. What changed in those three storefronts is that the exemption for small increases was removed. The machinery is the same machinery.

That is why this is worth building for even if none of those three markets is your biggest. A pipeline that can handle a consent-gated rise in Germany is the same pipeline that handles a consent-gated 60% rise in the United States. You are not building a regional special case; you are building the general case and then choosing when to use it.

Regime B: consent-free only if you stay small

Everywhere else, the old criteria still govern: an increase that stays inside Apple’s limits can go out as a notice, and the subscription renews at the new price unless the customer cancels. Above the limits, you are back in the consent flow.

The limits have two limbs — a percentage limb (50%) and a cash limb. Whether the test is AND or OR is the single highest-stakes detail in this entire subject, and it is worth confirming against the live help page before you commit to a plan. My reading of Apple’s wording is AND: both limbs must be breached for consent to be triggered.

If that reading is right, the practical consequence is large. Small-dollar subscriptions cannot reach the consent path at all, no matter the percentage — doubling a $1.99 monthly clears the 50% limb but not the cash limb. For an annual subscription, the price would need to be somewhere above roughly $100 before a 50%-plus rise could trigger consent. If the test is OR, the opposite is true and most percentage-heavy increases land in consent. Two different posts, two different roadmaps, one conjunction. Check it.

The mechanic almost nobody covers: the test runs per subscriber

Here is the part that changes how you compute things. The threshold test is applied at renewal, against each subscriber’s current price — not against your current App Store price point, and not once per product.

So consider a product that has been on sale for years and has accumulated legacy tiers: an original cohort at $4.99, a middle cohort at $7.99, current price $9.99. You raise to $12.99. Against the current price that is a 30% rise. Against the original cohort it is 160%. Same increase, different regime, depending on who is renewing.

The result is perverse in exactly the wrong direction. Your longest-tenured, most loyal, lowest-paying subscribers are the ones most likely to breach the percentage limb and get pulled into a consent flow — which is to say, the people you least want to show a cancel button to are the ones Apple will interrupt.

The operational rule follows directly:

for each legacy price tier t:
    pct   = (new_price - t.current_price) / t.current_price
    cash  = new_price - t.current_price
    needs_consent = breaches(pct) AND breaches(cash)   # AND vs OR: confirm

Compute it per tier, per storefront, and know the subscriber count behind each row before the increase is scheduled.

Silence is now a third outcome

Under a notice-only increase there are two outcomes: the customer stays or the customer cancels. Under consent there are three: yes, no, and no answer.

Apple re-requests consent from non-responders on a repeating cadence — commonly described as weekly, which is worth confirming before you build timing assumptions into a launch plan — and if consent never arrives, the subscription does not renew at the new price. Inaction resolves against you.

That breaks a habit most subscription models depend on. Consent rate and (1 − cancellation rate) are not complements any more, because silence sits between them. A cohort with a 4% cancellation rate under notice-only does not become a 96% consent cohort; it becomes some split of yes, no and never-opened-the-prompt, and the third bucket behaves like churn on your revenue line while looking nothing like churn in your support inbox.

I have no reliable numbers on real-world consent rates, and I am not going to invent any. The structural point stands without them: model the three outcomes separately, and treat non-response as a distinct forecast input rather than folding it into your existing churn assumption.

Grandfathering: two positions, no data

The obvious response to the per-subscriber mechanic is to grandfather legacy cohorts — leave the $4.99 tier where it is and raise only the cohorts where the increase stays under the thresholds.

The case for it: you avoid a consent prompt entirely for the cohort most likely to trip it, you keep tenured subscribers whose lifetime value is already proven, and you sidestep interrupting a happy customer with a dialogue box that mentions cancelling.

The case against: legacy tiers are permanent operational debt. Every future rise has to be computed against a widening spread of current prices, the per-tier matrix above grows every time you defer, and the revenue gap between your oldest and newest subscribers compounds indefinitely.

I could not find data from a named source that settles this, so treat it as a genuine judgement call rather than a solved question. What I would say is that the choice is easier to make well if you have the per-tier subscriber counts and the consent-exposure calculation in front of you before you pick a number — which most teams do not, because they price against the current App Store tier and discover the legacy spread afterwards.

What to build, and what to check first

Practically, a price rise on an existing subscription app now needs three things it did not need five years ago: a per-tier, per-storefront consent-exposure map; in-app messaging that reaches affected subscribers before Apple’s system prompt does, so the prompt confirms a decision rather than introducing one; and a forecast that treats non-response as its own bucket.

On the implementation surface: Apple confirms the capability in prose, but I have not verified the current StoreKit API symbols for reading or reacting to price-consent state, so I am not going to print a code sketch that might name something that does not exist. Same for OS and toolchain versions — the only version evidence in these notes is contemporaneous with the 2025 material, which establishes what existed a year ago, not what is current. Check both against Apple’s API reference before you write against them.

And check the AND/OR conjunction on the live help page before anything else. Whether small-dollar increases can trigger consent at all determines whether this is a problem you have to solve this quarter or a constraint you simply price around.