How to Update App Prices Per Country (Step-by-Step)

Step 3: How to Update App Prices Per Country Across Both Stores

You have your PPP baselines from Step 2. Your rounding rules are set. Your price grid looks sensible.

Now comes the part where most developers stall: actually shipping those prices to App Store Connect and Google Play without breaking anything.

This is where the spreadsheet confidence collapses. You have multiple SKUs, two stores with different pricing systems, 175 storefronts on Apple alone, and real subscribers who might be affected by price changes. The margin for error is not theoretical.

This guide is the operational checklist I built for myself after updating prices across 8 apps on both stores. It covers the sequence, the platform-specific constraints, and the sanity checks that prevent expensive mistakes.

If you followed Step 1 (pricing fundamentals) and Step 2 (PPP + rounding), this is where the theory becomes live in your stores.

Update all SKUs together, not one at a time

Your paywall presents pricing as a system. Monthly pushes users toward annual. Annual pushes toward lifetime. Weekly frames the value of monthly. These tiers only work when they're in proportion.

If you update the monthly price in Brazil but leave the annual unchanged, the ratio breaks. Your paywall that says "save 40% with annual" suddenly says "save 12%" in one country and "save 55%" in another. That's not localization, that's chaos.

With the right tooling, you don't need to trickle out changes one SKU at a time. If you can preview all your localized prices across all SKUs and all countries before pushing, there's no reason to hold back. Update the full set together so your paywall ratios stay intentional everywhere.

Practical order for a typical app:

Subscription tiers (weekly, monthly, annual), updated together. Check that the monthly-to-annual discount ratio holds per country.
One-time IAPs (lifetime unlock, consumable packs), updated alongside subscriptions so the "lifetime vs annual" comparison makes sense.
Legacy or low-traffic SKUs, these matter less but should still be consistent.

Rule of thumb: Update all related SKUs together so tier relationships hold. Preview the full grid first, then push confidently. RevenueCat's data shows that pricing changes on subscriptions can trigger opt-in flows for existing subscribers, so understand the impact before confirming.

Know what each store actually lets you do

App Store Connect and Google Play handle per-country pricing differently. Treating them as identical will cause problems.

App Store Connect

Apple uses a price point ladder with ~900 tiers across 175 storefronts. You cannot set an arbitrary price. You pick from their menu.
When you set a base price, Apple generates "comparable prices" for every storefront using exchange rates and tax. These are suggestions, not mandates. You can override each country individually.
For subscriptions, Apple lets you keep existing subscribers on their current price while applying the new price to new subscribers only. If you choose to migrate existing subscribers, Apple sends a consent notification for increases above certain thresholds. If the subscriber doesn't opt in, their subscription cancels at the end of the current period.
Apple occasionally adjusts prices across countries due to tax or FX changes. In late 2025, 3 countries (Poland, Switzerland, Turkiye) were affected in a single update. Your manually set prices can be overwritten by these adjustments.
Rate limits exist. Apple's App Store Connect API throttles requests. If you're updating prices programmatically across many products and countries, you'll hit 429 errors without proper pacing.

Google Play Console

Google lets you set arbitrary per-country prices in local currency. No ladder system.
As of October 2025, pricing templates are deprecated. All pricing adjustments must be made at the individual product level.
Google auto-converts your base price to local currencies, adds tax where required, and applies "locally relevant pricing patterns." These defaults are primarily exchange-rate-based with some local adjustments, but they're not a full PPP calculation.
For subscription price changes, existing subscribers are placed in a "legacy price cohort" and keep paying their original price by default. You must explicitly end the legacy cohort to migrate them. When migrating, the default is opt-in (the subscriber must agree to the new price).
Google supports 70+ local currencies with direct per-country pricing fields.

The practical gap

Apple's ladder means your PPP-calculated price might not match any available tier. You need to find the closest price point. Sometimes that means rounding up to the next tier, which can change your effective discount by several percentage points in a given country.

Google is more flexible but requires you to manage every country's price individually. With 170+ supported countries, that is a lot of fields to fill.

The stores don't talk to each other. Apple doesn't sync to Google and vice versa, which means without automation you're doing the same work twice, in two different consoles, with two different quirks. The PricePush engine handles both in a single operation so you only think about the price grid once.

The pre-push checklist

Before you publish any price to any store, run through this list. I use it every time I push prices on my own apps.

Grid sanity:

[ ] Every country has a price assigned (no blanks that would default to auto-conversion)
[ ] Monthly and annual prices maintain an intentional ratio in every country (for example, annual = 8-10x monthly, not 12x)
] No price endings look "computer-generated" (like $4.73 or €7.14). Every price lands in a [familiar psychological threshold
[ ] On Apple: every price maps to a valid price point tier. No "closest tier" surprises
[ ] On Google: prices are in the correct local currency for each country

Subscriber impact:

[ ] For existing subscription SKUs, understand how each store handles price changes for active subscribers
[ ] If prices are increasing, decide whether to grandfather existing subscribers or migrate them
[ ] If prices are decreasing, no opt-in is required, but track whether conversions improve within 7-14 days

Rollout scope:

[ ] All related SKUs (weekly, monthly, annual, lifetime) grouped together so paywall ratios stay intact
[ ] If this is your first time, consider starting with one app before rolling across your full portfolio
[ ] Document what you changed, when, and why (you'll want this for the measurement phase)

Push to stores, then measure

The push itself should be the fastest part. Both stores get the new prices together in a single operation, so there's no "Apple day vs Google day" to plan around. Here's the flow I follow after the pre-push checklist is clean.

Day 1: Push to both stores at once.

One operation, both stores, all SKUs, all countries. No separate App Store day and Google Play day. Once the grid is previewed and approved, the push is the easy part.

Apple price changes can take up to 24 hours to propagate across all storefronts, while Google Play usually reflects the update within hours. Don't check results on the same day you push.

Day 2 to 7: Monitor.

Look at the store dashboards or your analytics tool for:

Conversion rate by country (compare to pre-change baseline)
Refund rate by country (spikes indicate pricing discomfort)
New subscriber geography (are you seeing purchases from previously dead markets?)

Day 8 and beyond: Expand.

If results look good on your first app, repeat the process for your next app. Each app is a full all-SKU push. The workflow gets faster each time because your pricing strategy and rounding rules carry over.

---

What to measure after the push

Localized pricing is not a one-time task. It's a feedback loop: push prices, measure results, adjust.

The metrics that matter (in order):

Conversion rate per country. The primary signal. If you dropped prices in India and conversions went up, it worked. If they stayed flat, the price might still be too high or the market needs more time.
Revenue per country. Lower prices can mean lower revenue per transaction but higher total revenue if volume increases enough. Track both.
Refund rate per country. A spike after a price change (especially an increase) is an early warning.
ARPPU (Average Revenue Per Paying User). Localization should increase this globally even if individual country ARPPU drops, because you're adding paying users from markets that previously converted at zero.
Churn by country. For subscriptions, watch renewal rates in countries where you changed prices.

Evaluation window: Give each change 7-14 days before drawing conclusions. Subscription metrics need at least one renewal cycle to stabilize.

When to adjust: If a country's conversion rate doesn't improve after 14 days, the price might still be too high. Drop it one more tier and measure again. If refunds spike, you probably went too low and attracted users who expected a cheaper product category entirely.

The complexity problem (and the faster path)

If you read through this checklist and thought "this is a lot of manual work," you're right.

For a single app with one subscription SKU, it's manageable. You can click through App Store Connect and Google Play Console in an afternoon.

For multiple apps with multiple SKUs across both stores, the manual approach breaks down fast. I have 8 apps. Some have 4-5 subscription tiers plus IAPs. That's 30+ products across 175 storefronts across 2 stores. Doing this by hand took days per app.

That's why I built PricePush. It handles the entire workflow from this checklist:

Calculate PPP-adjusted prices for all countries in one click
Automatically map to Apple's price point ladder (no manual tier hunting)
Preview the full grid before pushing
Push to both App Store Connect and Google Play from one screen
Flag conflicts and large price jumps before they go live
Track price change history so you know what changed and when

The Indie plan starts at $9/mo for up to 3 apps with unlimited pushes. If you have more apps or need price change history, the Pro plan covers up to 20 apps.

You can also start free with 1 app and 10 pushes to see how the workflow feels before committing.

Copy/paste checklist (Step 3)

Print this or keep it open when you're ready to push:

[ ] All related SKUs updated together (paywall ratios intact)
[ ] Platform constraints understood (Apple ladder vs Google free-form)
[ ] Subscriber impact assessed (new vs existing)
[ ] Grid sanity-checked (ratios, endings, tier mapping)
[ ] Pushed to both stores in one operation (Day 1)
[ ] Monitoring conversion, refunds, geography (Day 2 to 7)
[ ] Next app rollout queued (Day 8 and beyond)
[ ] Measurement window: 7-14 days per change

What's next

You've now completed the full guided path:

Step 1: Localized pricing fundamentals, the mental model
Step 2: PPP baselines + rounding rules, the calculation
Step 3: Shipping prices across SKUs and stores, the operational rollout (you're here)

The next phase is iteration. After your first rollout, you'll start seeing which countries respond and which need further adjustment. The data will tell you more than any guide can.

If you want to skip the spreadsheet phase entirely, try PricePush free and go from Step 2 to live prices in minutes.

FAQ

Can I update prices on both stores at the same time? Yes, and you should. If you're clicking through the consoles manually, you'll handle one store at a time by necessity. With automation, a single push can update both App Store Connect and Google Play across all your countries at once. That's the whole point of using PricePush: skip the two-console tour entirely.

What happens to existing subscribers when I change prices? Both stores let you increase prices for new subscribers only, while existing subscribers stay on their current price. This is often the safer option: you test the new price on new users without risking churn from your existing base. If you do want to migrate existing subscribers to the new price, Apple sends a consent notification and cancels the subscription if they don't opt in. Google has a similar opt-in flow depending on the increase amount. Price decreases apply to everyone automatically on both platforms.

How often should I update localized prices? Review quarterly, or whenever major currency shifts happen. Apple occasionally forces updates due to tax changes. Monthly is too frequent for most apps. Quarterly catches drift without creating subscriber fatigue.

Shipping Prices Across SKUs and Stores: The Operational Checklist