What happens to App Store subscriptions when a user changes country

When a subscriber switches their App Store region, their active subscription doesn't cancel immediately — but the next renewal follows the new storefront's pricing rules. Here's what that means for your revenue and what your backend needs to handle.

A subscriber who built their habit with your app in Germany relocates to Australia. A US student spending a year abroad switches their App Store country to Japan. A remote worker moving from the UK to Brazil updates their billing region. What happens to their active subscription? Does it cancel on the spot? Does their price follow the original currency or shift to local pricing? Can they even keep the subscription at all?

These questions surface constantly in developer forums, yet Apple's official documentation on the topic is spread across several technical reference pages and support articles. This guide consolidates what is publicly documented — drawing from Apple's developer reference and widely reported patterns across the iOS developer community — so you can handle country-change events correctly in your backend before they silently distort your MRR figures.

How Apple's country-change process works

When a user decides to change their App Store country, they navigate to Settings → [Name] → Media & Purchases → View Apple ID → Country/Region. Before Apple permits the change, several conditions must be met:

• The account must have no outstanding unpaid balance.
• Any unredeemed Apple ID credit balance may not be transferable to the new storefront — Apple's terms vary by region and some credits expire on transfer.
• The user must agree to the new storefront's terms and conditions, including any jurisdiction-specific legal text.
• A valid payment method accepted in the new country must be on file.

These prerequisites mean that the country change is not instantaneous. A user who cannot clear a pending balance or provide a valid local payment method stays in their original storefront. From a developer perspective, that is a useful safeguard: it prevents mid-cycle storefront switches that would complicate billing.

This carry-through period is deliberate. It prevents abrupt service interruptions and gives the subscriber a natural break point: they pay out their current cycle under existing terms, then the new pricing takes effect on the following renewal.

What happens at the next renewal: pricing mechanics

After a country change, the subscription auto-renews in the new storefront at the locally configured price for your product's tier. Apple maps the subscription's price tier to the closest equivalent in the new currency using its territory pricing schedule — the same framework that governs globally equivalent pricing when you have that option enabled. Critically, this is not a spot-rate currency conversion of the old price; it is a tier lookup in your new storefront configuration.

This has concrete revenue implications. A user who originally subscribed at USD 4.99 per month in the United States and moves to India will not renew at USD 4.99 converted to INR at the daily exchange rate. Instead, Apple applies your product's INR price tier — which, if you have set up PPP-adjusted pricing for India, may be substantially lower in USD-equivalent terms.

That last row is the one that catches developers off guard. If a subscriber moves to a storefront where your app has no active price configured — or where your app is not available at all — the subscription will simply lapse at the next renewal. There is no automatic notification beyond a standard EXPIRED event. The subscriber loses access, and Apple does not automatically migrate them or notify you of the root cause. This is one of the strongest practical arguments for ensuring your app maintains an active price across all major storefronts, even if you have not invested in territory-specific PPP optimisation for every market. For a primer on how price tiers map across currencies, see our guide to Apple's price tier system and currency mapping.

What your server-side code needs to handle

From a backend engineering standpoint, Apple does not send a discrete COUNTRY_CHANGED server notification. The signal arrives embedded in the normal renewal flow. There are three things your handler should do.

Track storefrontCountryCode on every transaction. Every signed transaction and renewal info object returned by App Store Server Notifications v2 includes a storefrontCountryCode field in the JWS payload. After a country change, this field will differ from the value you recorded at the time of the original purchase. Comparing this field across consecutive renewal events is your primary mechanism for detecting that a subscriber has moved storefronts. If you are not already logging this field, adding it is a one-line change with meaningful downstream value.

Update your revenue records at the renewal event. If you maintain per-subscriber revenue records — for MRR dashboards, cohort analysis, or financial reporting — you need to update both the currency and the expected proceeds figure when you detect a storefront change. A subscriber who was contributing USD 4.99 to your MRR may now contribute the INR equivalent, which affects your cohort LTV calculations. Most managed SDK solutions such as RevenueCat handle currency normalisation automatically in their dashboards, but custom-built backends commonly miss this update and accumulate silent drift in their MRR figures over time.

Re-evaluate regional content entitlements. If your subscription includes access to region-licensed content — media libraries, locally compliant data handling, features restricted by rights territory — a subscriber's country change affects what they are entitled to access. Your entitlement logic should reference the storefrontCountryCode from the most recent transaction, not the country recorded at initial subscription. This is particularly relevant for apps in media, education, or anything touching GDPR or jurisdiction-specific compliance.

A minimal detection pattern in pseudocode:

on DID_RENEW notification:
  current_country = transaction.storefrontCountryCode
  stored_country  = db.get_subscriber_country(transaction.originalTransactionId)

  if current_country != stored_country:
    db.update_subscriber_country(transaction.originalTransactionId, current_country)
    recalculate_mrr_contribution(transaction)
    check_content_entitlements(transaction.originalTransactionId, current_country)
    log_country_change_event(originalTransactionId, stored_country, current_country)

This adds negligible latency to your notification handler and prevents silent MRR reporting drift from accumulating as your international subscriber base grows. On the tax side, Apple handles VAT and GST collection and remittance on your behalf regardless of storefront, so you do not need to recalculate tax on the subscriber's new renewals. However, if you issue VAT receipts or invoices for business subscribers, the applicable tax regime changes with the storefront. See our overview of how Apple handles VAT, GST, and withholding tax across territories for the broader context.

Edge cases: family sharing, grace periods, and promotional offer eligibility

Family sharing. When the subscription organiser — the family group owner who purchased the subscription — changes their App Store country, shared subscriptions can be affected for the whole group. Apple's documentation indicates that family group membership rules are tied to the organiser's storefront, and in some configurations family members in different countries may lose access to shared subscriptions after the organiser moves. This is worth flagging to users who set up family-shared subscriptions for small teams or households with members across borders.

Failed renewals in the new storefront. If the first renewal attempt in the new storefront fails — for example, because the subscriber's payment method is not accepted in their new country — Apple's standard billing retry and grace period logic applies unchanged. The subscriber enters the billing retry window (Apple's documentation describes up to 60 days for annual plans) before the subscription lapses. Your DID_FAIL_TO_RENEW and GRACE_PERIOD_EXPIRED notifications will fire as normal; the country-change context will be visible in the storefrontCountryCode field. For the full mechanics, see our guide to grace periods and billing retry.

Introductory offer eligibility. A subscriber who redeemed an introductory offer in their original storefront is not eligible for a new introductory offer in the new storefront. Apple's eligibility rules track the original transaction ID, not the current storefront — so the subscriber cannot reset their introductory offer eligibility simply by changing countries. Promotional offers (win-back mechanics) may or may not be re-eligible depending on your specific configuration; consult Apple's developer documentation on offer eligibility for your use case before assuming they cannot be re-targeted.

Pending price changes. If you had a scheduled price increase set to take effect at the next renewal — one that required subscriber notification and consent under Apple's grandfathering rules — a mid-cycle country change can interact with that flow in unexpected ways. Apple's published guidance does not fully specify the precedence between a pending price change and a country-change event. Developer community reports suggest the new storefront's pricing takes precedence at the next renewal, but test this in the sandbox before relying on that behaviour for a major price-change rollout.

Why this matters more as your user base goes global

For apps with a predominantly single-market subscriber base, country-change events are rare enough to be noise. For apps with users across Europe, Asia-Pacific, and the Americas — precisely the apps that have invested in localisation and PPP-adjusted pricing — the frequency rises meaningfully. Remote workers, students on exchange programmes, frequent long-stay travellers, and expats are segments that tend to over-index on the kind of productivity, language, and utility apps that have already done the work of localising their listings and optimising territory pricing.

In practice, the apps most likely to see country-change events in volume are the same apps that have done the most international work. Building the backend handling early avoids technical debt accumulating quietly as your international subscriber count grows. A subscriber whose currency has silently shifted but whose MRR record has not been updated represents exactly the kind of invisible reporting error that makes cohort analysis unreliable over a multi-year subscription lifecycle.

If you have not yet reviewed your territory pricing coverage to ensure active prices are configured in each storefront where you have users, the AppsOps pricing dashboard surfaces which storefronts your app is priced in and whether your current tiers are within PPP-adjusted ranges for each market.

Sources and further reading

• Apple Developer Documentation: App Store Server Notifications — complete v2 reference including storefrontCountryCode field
• Apple Support: Change your App Store country or region — prerequisites and what happens to active purchases
• Apple Developer Documentation: StoreKit — Subscriptions and Offers reference
• RevenueCat: State of Subscription Apps report — renewal rate and retention data by region
• Apple App Store Connect Help: Set a price for an in-app purchase — territory pricing configuration