App Store Connect bulk price editing: updating subscription prices across 175 territories efficiently
A practical guide to managing App Store subscription prices at scale — from the Connect UI's territory controls to the ASC API's automated workflows for updating all 175 storefronts.
Why pricing 175 territories manually doesn't scale
When Apple expanded its territory-level custom pricing controls, it handed developers an unprecedented degree of global pricing granularity. The catch: exercising that control across all 175 App Store storefronts is tedious by default. Most developers end up doing one of two things — they leave Apple's "globally equivalent pricing" enabled and let the algorithm maintain USD parity, or they hand-edit a handful of major markets and ignore the rest. Both approaches leave revenue on the table in different ways.
Globally equivalent pricing sounds convenient, but it silently resets custom prices whenever Apple adjusts exchange rates, undoing any PPP-adjusted tiers you've carefully set for markets like India, Brazil, or Turkey. Manual editing, on the other hand, doesn't scale past a dozen territories before it becomes error-prone and time-consuming enough to be skipped entirely.
This guide walks through a systematic approach: how to use the territory price editor in App Store Connect, how to group markets for efficient bulk management, and when to reach for the App Store Connect API to automate the work at scale.
Inside the App Store Connect territory price editor
In App Store Connect, subscription prices live under your app → Subscriptions → your subscription group → the individual subscription → Prices. From there you'll see a territory list where you can set a price for each storefront individually, or choose a base territory and let Apple calculate the rest from published exchange-rate tiers.
Two controls here deserve close attention:
- Maintain globally equivalent pricing — when enabled, Apple recalculates all non-base territory prices whenever exchange rates shift materially. Disabling it locks your custom prices in place until you change them manually.
- Automatically set prices for new storefronts — when disabled, any new storefront Apple adds will not have a price set for your app, meaning purchases are impossible there until you act. It's generally safer to leave this on unless you have a specific reason to exclude new markets.
Practical rule: disable globally equivalent pricing for any territory where you've deliberately set a PPP-adjusted price. Leave it on for territories where you genuinely want USD parity. You can run both strategies simultaneously — the toggle applies per-territory, not globally, once you've started editing individual overrides.
The UI lets you edit prices one territory at a time, which works acceptably for adjusting a handful of markets. For broader changes — say, repricing all Southeast Asian storefronts after a currency shift — you're looking at 20–30 manual edits per subscription product. That's where grouping by economic profile and the API become the right tools.
A framework for grouping territories strategically
Rather than treating 175 storefronts as independent levers, experienced operators group them by economic profile. The segmentation below reflects the purchasing-power and market-size considerations most commonly discussed in App Store pricing literature from RevenueCat, Phiture, and Sensor Tower:
| Tier group | Representative territories | Recommended pricing posture |
|---|---|---|
| Premium (USD anchor) | United States, Canada, Australia, Japan, Singapore, South Korea | Full price; globally equivalent is fine — these markets index closely to USD |
| Western Europe (EUR/GBP anchor) | Germany, UK, France, Netherlands, Sweden, Norway | Match the EUR tier nearest your USD price; review quarterly for EUR/USD drift |
| High-potential emerging markets | Brazil, Mexico, India, Turkey, Indonesia, Saudi Arabia | PPP-adjusted: roughly 40–60% of USD price; disable globally equivalent pricing |
| Smaller emerging markets | Nigeria, Pakistan, Egypt, Vietnam, Bangladesh, Ukraine | PPP-adjusted: roughly 20–40% of USD price; prioritise volume over ARPU |
| Long-tail storefronts (~125 territories) | Remaining storefronts | Let globally equivalent pricing run; spot-check a random sample twice yearly |
This framework reduces your active decision set to roughly 20–30 high-signal territories while delegating the remainder to Apple's automation. When a currency event occurs — say, the Turkish lira moves sharply in a month — you only need to review and update one group rather than hunting through all 175 rows. For the PPP logic underpinning these groupings, see Why a $9.99 app shouldn't cost ₹830 in India and the territory-level benchmarks on the AppsOps territories page.
Automating bulk updates with the App Store Connect API
Once you've defined your tier groups, the App Store Connect API is the right tool for executing updates at scale. The relevant resource is appPriceSchedules. A price schedule is a dated series of price-point assignments per territory — you POST a new schedule to change prices going forward, and Apple handles propagation across the storefronts you've specified.
The high-level flow for a bulk update:
- Authenticate — generate a short-lived JWT from your API key and include it as an
Authorization: Bearerheader on every request. If you haven't set up your key yet, start with Setting up the App Store Connect API key: a 5-minute guide. - Fetch existing price schedules —
GET /v1/apps/{id}/appPriceSchedulereturns the current territory-by-territory configuration. Always read the current state before writing; this also surfaces any existing custom overrides you might accidentally clobber. - Resolve price point IDs — price points are territory-specific. Retrieve them from
GET /v1/appPriceTiers/{id}/pricePointsfor each target territory. Never hardcode IDs; they are not portable across storefronts. - Build and POST the new schedule — for each territory in the group being updated, specify the
appPricePointIdand an effective date. Apple processes territory updates asynchronously; allow a few minutes before verifying. - Verify the result — pull the schedule again and diff against your expected state before marking the task complete.
Price point IDs are not portable across territories. A price point representing roughly $4.99 in the United States has a different ID in Germany, India, and Brazil. Attempting to reuse an ID from one territory in another will either fail with a validation error or silently apply a different price point than intended. Always fetch current price points per territory at the time of the update.
For a complete worked example with rate-limit handling and error recovery, see Building a price-update workflow with the App Store Connect API.
Maintaining pricing hygiene over time
Bulk price management is not a one-time task. Several routine triggers should prompt a pricing review across your territory groups:
- Apple's periodic currency adjustments — Apple adjusts prices in currency-volatile markets several times per year. Check App Store Connect's pricing history log, and monitor your per-territory revenue for unexplained dips or spikes in the days following Apple's announced adjustments.
- New storefronts — Apple occasionally adds storefronts. If "automatically set prices for new storefronts" is disabled, any newly added market will launch without a price, making purchases impossible there until you act.
- Significant exchange-rate moves — a move of 15% or more in a major currency (Turkish lira, Brazilian real, Argentine peso) can quickly make your PPP-adjusted prices meaningfully wrong. A quarterly sweep of your emerging-market groups catches this before it materially affects conversion or churn.
- Your own base price changes — when you raise the USD price, review whether the increase should propagate proportionally to PPP tiers or whether those local prices should move more conservatively. A 20% USD increase does not automatically justify a 20% increase in a price-sensitive emerging market.
Building a lightweight pricing calendar — a recurring quarterly review — takes under an hour once your tier groups are defined and your API scripts are in place. Research from Phiture and RevenueCat's annual State of Subscription Apps reports consistently points to pricing maintenance as an under-invested area for most subscription apps; developers who treat it as an ongoing operational task rather than a launch-day activity tend to perform better in secondary markets over time.
Common mistakes and how to avoid them
Re-enabling globally equivalent pricing after disabling it. If you've built carefully crafted PPP-adjusted prices for 20 markets and then accidentally re-enable globally equivalent pricing, Apple will recalculate and overwrite your custom values — without a warning dialog. Double-check this toggle after any App Store Connect session where you're editing subscription settings.
Ignoring subscriber consent thresholds on bulk increases. A bulk price increase that crosses Apple's notifiable threshold triggers a consent flow for existing subscribers; those who don't opt in will lapse at their next renewal. Before any bulk increase, review your grandfathering obligations — the post on Apple's grandfathering rules for subscription price changes covers the thresholds and consent mechanics in detail.
Setting prices below Apple's territory minimums. Each storefront has a floor price — the lowest available App Store tier for that territory. Attempting to set a price below the floor via the API returns a validation error. Know the floor prices for your target territories before building your schedule payload, especially in markets where the local-currency floor might be higher than you expect relative to your PPP target.
Neglecting the long-tail spot-check. It's tempting to focus only on your top 20 revenue territories and assume the rest take care of themselves. Globally equivalent pricing handles most of the long tail acceptably, but an unreviewed portfolio occasionally produces surprises: a territory where your app costs effectively nothing after currency collapse, or one where Apple's calculation has put the price unexpectedly high. A brief annual spot-check of 15–20 randomly selected long-tail territories takes under 30 minutes and prevents these issues from compounding.
Sources and further reading
- Apple Developer Documentation — App Price Schedules (App Store Connect API)
- Apple Developer Documentation — Managing Pricing for Apps and In-App Purchases
- RevenueCat — State of Subscription Apps (annual report)
- Phiture Mobile Growth Stack — App Store Pricing Strategy
- Apple App Store Connect Help — Set a Price for Your App
Share this post
Ready to put this into practice?
AppsOps is the first App Store ops dashboard — PPP-fair pricing for 175 App Store territories, AI metadata localization in 39 languages, AI screenshot localization for 14 Apple device classes, and one-click App Store Connect API push — all from one dashboard, all for $19/month.
Try AppsOps free — no card →