Your Shipaton App Is Already Priced in 175 Countries. Here's What the Stores Picked.

To enter the RevenueCat Shipaton, your app has to make money. The rules require it to use the RevenueCat SDK to power at least one in-app or web purchase, or to serve ads through RevenueCat. Unless you take the ads route, that means shipping an in-app purchase or a subscription, and the moment you create one you have made a pricing decision, whether you meant to or not.

Here is how far that decision reaches. You create the in-app purchase or subscription in App Store Connect or Play Console and type one price, in one currency. Both stores then fill in every other market for you, around 175 of them, in the background, using rules most people never read. On a Shipaton timeline this happens late, between the last feature and the screenshots, and it gets about ten seconds of thought.

It deserves more than that, because shipping at all is the hard part. Last year 51,883 people registered for the Shipaton, and the Devpost project gallery lists 813 submissions, roughly 1.6% of everyone who signed up. RevenueCat's opt-in app showcase lists a smaller 610, since appearing there took a separate step. If you are one of the few who ships, the prices your app launches with are the ones the stores chose, not the ones you did.

Shipaton entries also have to be first releases. The rules say "the first public version of the Project must be released during the Submission Period," and "updates to previously released apps are not eligible." So whatever you set between the 31 July open and the 30 September deadline is your app's opening position in every market, and the default is the one you get by not deciding.

What Apple did

Apple's documentation is direct about it. You set a price for the country or region you know, and that becomes "the basis for automatically generating prices across the other 174 storefronts and 43 currencies." Those generated prices "account for foreign exchange rates and certain taxes, and follow the most common pricing convention for each country or region."

Then Apple keeps going. "Periodically, Apple updates prices in certain regions based on changes in taxes and foreign exchange rates." The stated aim is that your price "stays equalized with your base country or region." Apple never changes your base price in your base market, and it notifies you before changing anything else.

So on the App Store your prices move on their own. If a currency slides in November, Apple pulls that market back into line with your base.

What Google did

Google Play converts once. The documentation says Play converts your price to the local currency, adds tax in select countries, and applies "locally relevant pricing patterns and valid exchange rates for the date on which you set the price for your app."

The date on which you set the price. That rate gets captured and held. There is a button at the top right of the Local prices section called Update exchange rates, and it exists because nothing refreshes by itself. Google's wording: "You can manually refresh the price to ensure that the local price reflects the latest exchange rate."

A price you set in September 2026 is still running on September 2026 exchange rates in 2029 unless somebody presses that button.

Subscriptions don't get re-adjusted

Apple's automatic adjustment has an exception. Prices of apps and in-app purchases get updated as taxes and currencies change, and auto-renewable subscriptions are excluded from that. Apple says subscription prices aren't automatically adjusted for foreign exchange and tax changes, and that you can update them yourself in App Store Connect whenever you want.

A RevenueCat SDK purchase is the Shipaton entry requirement, so a lot of entries are subscription apps. For those, both stores behave the same way. Apple sets the grid once and leaves it. Google sets the grid once and leaves it. Nobody comes back to it except you.

Some entrants monetize through RevenueCat Ads or web purchases, which also qualify. If that's your build, the store price grid isn't your problem and the rest of this won't apply.

Setting your own price switches the maintenance off

Apple's docs are explicit about the trade: "If you select your own prices, Apple won't adjust your pricing on those storefronts in the future."

Override the generated price on a storefront and you have taken that storefront over for good. Apple stops maintaining it. The devs who hand-edit five or six countries are usually editing the markets they care most about, which means they have quietly opted those exact markets out of every future adjustment.

Set your own prices where you have a reason to. Keep a list of which storefronts you took over, because you're the one keeping them current now.

Currency-correct, still the wrong number

Both stores are doing currency conversion, and both do it well. Purchasing power is a different question, and neither store is answering it.

RevenueCat's own price localization guide puts it plainly, saying store defaults "ignore a crucial factor: value to the customer." The same guide notes that Apple's recommendation for India sits around 21% below the US price, while apps in practice tend to price India 50% to 80% lower.

The outcome data sits behind that gap. RevenueCat's State of Subscription Apps 2026 reports first-year revenue per payer of $32 in North America against $14 in India and Southeast Asia, and trial-to-paid conversion of 34.2% in North America against 15.2% in India and Southeast Asia. A converted US price asks a market that pays less than half as much to accept the same figure. That is the whole argument for localized pricing, and there's evidence it moves sales rather than just unit counts.

Before you submit

Two checks are worth ten minutes each, whatever you price with.

1. Read the generated grid before it goes live. Both consoles show every country's price on one screen, and it is the only look at the defaults you get before customers do.
2. Sanity-check your lower-income markets. The defaults are your base price converted, so India, Brazil, and Turkey usually land well above what those markets actually spend.

What you will usually find is that the defaults are currency-correct and still wrong, because neither store prices for what a market can actually pay. Fixing that across every storefront, and keeping it right as exchange rates move, is the part worth handing to a tool.

If you want the reasoning behind the numbers themselves rather than the store mechanics, the guide to pricing an app covers choosing the base price, and the localization cheat sheet has the country-by-country table. The background on why store conversion isn't regional pricing is in this post.

If you want the grid done for you

RevenueCat runs the purchase itself: the SDK you are required to use, the paywall, the entitlement. What neither RevenueCat nor the store sets for you is a price point matched to what each market can pay, because the store owns that number and fills it with a plain currency conversion. That gap is the one PricePush closes. RevenueCat powers the sale, and PricePush makes sure the price the sale charges fits the country it runs in.

PricePush is in the Shipaton Sale. The free plan covers one app across every country on both the App Store and Google Play, which is the shape of a Shipaton build. The code SHIPATON26 takes 60% off the first year, renewing at the regular price after that, and a few founding lifetime seats are still open. It does not cover the Samsung Galaxy Store, which is an eligible Shipaton store, so if that's where you're launching this won't help you. And if you only want to see what the numbers should look like, the free localizer shows a purchasing power grid for any base price, no login.