App Store Regional Pricing

---
name: app-store-regional-pricing
description: Research and configure App Store and in-app purchase prices by storefront using affordability evidence and available Apple price points.
license: MIT
---
<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->

# App Store regional pricing

Use for storefront pricing that reflects local affordability, including one-time purchases and subscriptions. Do not confuse the app download price with a separate in-app purchase.

1. Identify the exact app, product ID, purchase type, base storefront, current schedule, availability, effective dates, and any existing custom prices. Inspect the live schedule before proposing changes; never assume exchange-rate equalization is purchasing-power pricing.
2. Establish the user's base price and commercial constraints. Research current, dated primary sources for affordability (for example World Bank income or GDP per capita and PPP data), taxes, applicable Apple rules, and relevant market evidence. GDP per capita is a rough proxy, not a measure of every customer's income. Record missing or stale data and avoid unsupported precision.
3. Propose a transparent, reproducible price ladder and country assignments, with the actual Apple storefront currency and allowed price point for each. Account for tax treatment, Apple proceeds, minimum viable revenue, and commercial judgment; distinguish observed figures from proposed estimates. Review outliers, dollar-denominated storefronts, and availability. Do not claim a price is objectively fair or promise a currency the storefront does not support.
4. Follow the user's authorized scope for changes. Preserve the base and unrelated existing prices unless requested. For material unresolved business choices, present concrete options before applying them. Do not buy, submit for review, or release the app as a side effect.
5. Use the existing project workflow, CLI, or connected UI to configure custom storefront prices. Check effective dates, current and future schedules, and whether the change replaces existing overrides. Apple states manually managed regions are not automatically updated for exchange rate or tax changes; identify the monitoring owner and review cadence.
6. Reopen the saved schedule and verify the exact product, dates, storefronts, amounts, currencies, and unaffected base. Report applied versus proposed prices and remaining coverage. If sandbox or storefront purchase testing is unavailable, say so. Note that the customer's Apple account storefront determines the price, not necessarily physical location.

## Post-launch review

- Confirm the app is actually available for sale and record the launch date before interpreting sales. If it has not launched, report the review as pending; schedule the first review only if a real scheduling tool can anchor it to 30 days after the actual launch. Set a fixed calendar date only after the launch date is recorded. Do not claim a reminder was created without a verified schedule.
- At approximately 30 days and 90 days after launch, and quarterly thereafter, retrieve the latest available App Store Connect Analytics and Sales and Trends reports using an authorized workflow. Record the report dates, timezone, product, storefront, currency, report freshness, and missing or suppressed data. Distinguish downloads, product-page views, purchases, refunds, and proceeds; do not count TestFlight or sandbox activity as sales.
- Compare storefront purchase conversion only when the numerator and denominator cover the same product, audience, and period. Compare net proceeds and refunds as well as unit sales, and segment by acquisition source where available. Record sample sizes and avoid conclusions from sparse data, privacy thresholds, or incomplete reporting. Pricing is one possible cause of differences, not proof of causation.
- Recheck manual prices against current exchange rates, taxes, local purchasing-power indicators, and Apple price points. List changes since the previous review, markets needing attention, and the dates and sources of evidence. Account for Apple commissions and local tax treatment without guessing actual proceeds.
- Recommend a small, reversible set of changes with current and proposed prices, expected tradeoffs, and follow-up date. Respect the user's authorization and product-specific pricing rules; verify each saved schedule and distinguish scheduled changes from active prices. Never promise a future review will happen without a functioning automation or explicit follow-up.

Primary references: [Set a price for an In-App Purchase](https://developer.apple.com/help/app-store-connect/manage-in-app-purchases/set-a-price-for-an-in-app-purchase), [Apple pricing](https://developer.apple.com/in-app-purchase/), [World Bank data](https://data.worldbank.org/indicator/NY.GDP.PCAP.PP.CD). Check current documentation for product-specific behavior before making changes.