App Store Pricing Recommendations explained: how Apple’s automatic tier suggestions work and when to override them

Apple pre-fills a recommended tier for all 175 storefronts when you set a base price — but accepting every suggestion uncritically can cost revenue in PPP-divergent markets. This guide explains how the recommendation engine works, where it falls short, and how to build an intentional override strategy.

When you set a base price in App Store Connect, Apple immediately fills in suggested prices for every other territory — 175 storefronts, all at once. These are Pricing Recommendations, and while they can save hours of manual work, accepting them uncritically can quietly undermine revenue in markets where purchasing power diverges sharply from the US baseline. This guide explains how the system works, what it optimises for, and when you should override it.

What App Store Pricing Recommendations actually are

Pricing Recommendations are Apple's way of translating your chosen base price into suggested tier equivalents across every active App Store territory. When you select Tier 5 ($4.99 USD) as your base, App Store Connect pre-fills a recommended tier for each territory — not a raw currency conversion, but the tier Apple considers "globally equivalent" for that storefront.

The key word is tier. The App Store does not allow arbitrary decimal prices; it uses a fixed schedule of price tiers. Each tier has a defined price in each local currency. Apple's recommendations map your base tier to the tier it considers most equivalent in each market, rounding to the nearest defined price point.

The feature sits under Pricing and Availability → Price → Edit Prices in App Store Connect. For new apps and new in-app purchase products, Apple shows the recommended tier pre-selected for each territory. For existing products, you access recommendations through the "Set Pricing" workflow when making a price change. The UI makes accepting the full recommendation set easy — perhaps too easy, given how much variation exists across markets.

How Apple calculates the recommendations

Apple has not published the complete methodology, but based on its developer documentation and observed industry behaviour, the system uses a combination of two inputs:

1. Reference exchange rates: Apple updates its FX reference rates periodically — not daily, and not on a publicly announced schedule. The starting point for a recommendation is roughly what your base price converts to at Apple's current reference rate.
2. Globally Equivalent Pricing adjustment: Apple applies a purchasing-power overlay to reach the nearest defined tier. The documentation describes this as making the price "feel equivalent" across markets — a concept loosely related to PPP, though Apple's precise weighting methodology is not disclosed.

When Apple updates its reference rates — which historically happens a handful of times per year — it also revises the recommendations. If you have Automatically adjust prices in other countries and regions based on the price of this product in the U.S. store enabled, your live prices update automatically. If you manage prices manually, the recommendations update but your actual prices stay locked until you explicitly apply them.

This is a meaningful operational distinction. Developers relying on automatic adjustments get currency protection in strongly appreciating markets, but lose granular control in markets where PPP and exchange rates diverge — which is common in high-inflation economies. Developers managing prices manually preserve control but must actively monitor for FX drift.

When the recommendations work well — and when they don't

Apple's recommendations are calibrated for developed-market currencies that track USD and EUR movements closely. They tend to hold up well for territories where currency stability is high and where the FX-to-purchasing-power relationship is reasonably direct:

• Eurozone territories (Germany, France, Italy, Netherlands), where currency stability means FX-based recommendations stay accurate between Apple's rate updates.
• English-speaking markets (UK, Australia, Canada), where small FX adjustments and VAT handling are built into the tier structure.
• Markets with small addressable audiences where fine-grained PPP optimisation would not meaningfully shift overall revenue.

Where recommendations most frequently diverge from what developers actually want:

The pattern is consistent: recommendations are most reliable where the markets are largest and most familiar to Western developers, and least reliable where localisation would have the greatest impact on conversion. Phiture's Mobile Growth Stack research and RevenueCat's annual subscription reports have both highlighted that price localisation — including moving away from FX-only recommendations — can improve conversion rates in lower-income markets. The relationship between PPP divergence and churn makes this a retention question as much as an acquisition one.

A practical framework for reviewing recommendations

Rather than reviewing all 175 territories simultaneously — a route to decision fatigue — segment your storefronts into tiers of strategic importance before opening the pricing editor.

Tier 1 — High-revenue, high-attention markets: US, UK, Germany, Japan, Australia, Canada. Review individually every time you change your base price. Confirm that recommendations look reasonable and that your auto-adjust setting matches your intent for each territory.

Tier 2 — Scale markets where PPP optimisation matters: India, Brazil, Indonesia, Mexico, Türkiye, Saudi Arabia, South Korea, the Philippines. These markets combine meaningful user populations with significant PPP divergence from USD. Override recommendations with PPP-informed tiers and revisit semi-annually. For a deep look at specific market dynamics, see the territory pricing guides on this site.

Tier 3 — Long-tail territories: Markets individually contributing less than 1–2% of revenue. Accepting recommendations here is usually defensible — the opportunity cost of manual optimisation exceeds the revenue gain for most apps, and the maintenance overhead is real. Assign these to auto-adjust and revisit annually or following major FX events.

Overriding recommendations: the mechanics in App Store Connect

Overriding a recommendation is straightforward in the UI, though the workflow has a few non-obvious elements:

1. In your app or in-app purchase product, navigate to Pricing and Availability → Price → Edit Prices.
2. Select the territory you want to override.
3. Change the tier from the recommended one to your preferred tier. App Store Connect shows the local currency amount next to each tier.
4. Repeat for each territory requiring a manual price.
5. Save. Manual overrides persist until you explicitly change them — they are not overwritten by future recommendation updates, unless you re-enable global automatic adjustments.

The critical nuance: if you subsequently enable automatic price adjustments globally, it will silently overwrite your manual territory overrides for affected territories. Apple displays a warning in the UI, but it catches developers who enable automatic adjustments at a later date without checking which markets had custom prices. If you maintain manual overrides for key markets, either keep automatic adjustment disabled and manage FX updates yourself, or use a scripted workflow via the App Store Connect API that applies bulk updates with selective overrides preserved.

For subscription products specifically, any price change in a territory — including one triggered by accepting a new recommendation — initiates Apple's subscriber notification flow. Existing subscribers may be grandfathered at their original price or prompted to consent to the new price, depending on configuration. Plan recommendation reviews around your subscriber communication cadence, not just your pricing calendar. Apple's grandfathering rules for subscription price changes cover the full decision tree.

Auditing recommendations at scale with the App Store Connect API

For developers managing multiple apps, multiple subscription tiers, or a broad in-app purchase catalogue, reviewing recommendations manually across 175 territories is not practical. The App Store Connect API provides a programmatic path.

The GET /v1/appPriceSchedules/{id}/manualPrices and GET /v1/appPriceSchedules/{id}/automaticPrices endpoints return current prices for each territory, including whether a price is a manual override or following the automatic recommendation schedule. Diffing these against the current recommendation set — available via GET /v1/appPricePoints — identifies territories where live prices have drifted significantly from current recommendations, flagging markets for intentional review.

A quarterly audit script built on this pattern typically:

1. Fetches all current live prices by territory for each product.
2. Fetches current Apple recommendation tiers for the same base price.
3. Flags territories where the live price differs from the recommendation by more than one tier in either direction.
4. Outputs a review list for human decision — accept the recommendation, maintain the override with justification, or set a new manual price.

This approach keeps pricing posture intentional rather than accidental, which is especially important in the months following major FX moves. Teams running this audit often discover that currencies they set manually two or three years ago have since moved significantly, leaving prices that made sense originally now either too high or too low relative to both local purchasing power and Apple's current recommendations.

Common mistakes when working with pricing recommendations

Accepting recommendations for all territories without review. The "apply to all" path in App Store Connect is fast, but it implicitly opts you into exchange-rate-based pricing everywhere, including markets where PPP-adjusted pricing would substantially improve conversion. At minimum, review Tier 2 markets before applying recommendations globally.

Confusing the recommendation date with Apple's FX update date. Recommendations shown in App Store Connect reflect Apple's last reference rate update, which may be weeks or months old. A recommendation that looked accurate when it appeared may now lag behind significant currency movement. Treat recommendations in volatile-currency markets as requiring independent verification, not as real-time FX-accurate figures.

Losing track of manual overrides over time. After months of incremental changes, it becomes difficult to recall which territories are on manual override and which are auto-adjusting. Build a lightweight audit — a spreadsheet refreshed from the API, or even a documented pricing policy — to maintain visibility into your actual pricing posture.

Not coordinating subscription price changes with the subscriber notification flow. Even a one-tier change in a territory can trigger the required consent flow for existing subscribers in some configurations. Recommendation reviews should be treated as pricing events, not routine maintenance, and planned accordingly.

Pricing Recommendations are a genuinely useful feature when used as a starting point rather than a final answer. The markets where they work best require the least ongoing attention; the markets where they require the most scrutiny — India, Brazil, Southeast Asia, Sub-Saharan Africa — are also the markets where getting localised pricing right can move your revenue curve meaningfully. The territory guides on this site are designed to help with that market-by-market analysis.

Sources and further reading

• Apple Developer — Manage app pricing in App Store Connect (Help Centre)
• Apple Developer — Subscriptions overview: pricing, trials, and mechanics
• App Store Connect API documentation — price schedules and price points reference
• RevenueCat Blog — State of Subscription Apps reports and pricing analysis
• Phiture — Mobile Growth Stack: ASO, pricing localisation, and conversion research
• World Bank — Purchasing Power Parity conversion factor data by country