DEV Community: nicoinu

Cutting store commission from 30% to 15%: what each application actually asks

nicoinu — Thu, 20 Aug 2026 12:43:41 +0000

Apple and Google both have a program that drops in-app purchase commission from 30% to 15%. Neither one is automatic. If you do not apply, you keep paying 30%.

This is the walkthrough: which page to open, what you get asked, and when the rate actually changes. Everything here comes from the official documentation and from the application screens themselves.

The rates are current as of August 2026. They change, so check the official pages before you act on any number.

1. Where the discount actually applies

What you sell	App Store	Google Play
One-time in-app purchases, paid apps	30% → 15% after applying	30% → 15% after enrolling
Subscriptions, first year	30% → 15% after applying	15% either way
Subscriptions, second year onward	15% either way	15% either way

On the App Store, a subscriber who accumulates more than one year of paid service in the same subscription group already moves you to 15%, program or not.

Applying to the program gets you that 15% from the first billing cycle instead of the thirteenth month.

On Google Play, auto-renewing subscriptions are 15% regardless of enrollment. The fee table spells it out: 15% "for automatically renewing subscription products purchased by subscribers, regardless of revenue earned by the developer each year."

That was not always true. Until December 2021, Google also charged 30% for the first year and 15% from month 13. On January 1, 2022 the distinction disappeared. If you remember Play subscriptions being 30%, that is where the memory comes from.

So on Google, enrollment matters for everything that is not a subscription.

Both programs cap out at 1 million USD per year.

One detail worth getting right: Apple does not count your sales. It counts proceeds, meaning what is left after Apple's commission and certain taxes and adjustments. That is the number you see paid out in App Store Connect.

Your sales can be above 1 million USD while your proceeds are still below it. Check the payouts rather than assuming you are over the line.

2. Applying on the App Store

Only the Account Holder can submit this. Other roles cannot reach the form at all, so if someone else holds that role, sort that out first.

2.1 Accept the paid apps agreement first

Open "Agreements, Tax, and Banking" in App Store Connect and check that the latest Paid Applications Agreement (Schedule 2 to the Apple Developer Program License Agreement) is accepted.

Accept it there if it is not. The first question on the application form is this exact check, and you cannot move past it otherwise.

2.2 Answer the two questions

https://developer.apple.com/app-store/small-business-program/

The form asks two questions and nothing else.

The first is the agreement from 2.1. Pick "Yes, I have accepted." and continue.

The second asks about Associated Developer Accounts. An account counts as associated if any of these are true.

You hold more than 50% of its ownership or shares
It holds more than 50% of your ownership or shares
You have ultimate decision-making authority over it
It has ultimate decision-making authority over you

For each one, you provide the name, Team ID, Account Holder email address, and a description of the relationship.

If there are none, say so and submit. That is the whole application.

Caution

When you do have associated accounts, the 1 million USD threshold is measured against their combined proceeds. Apple states that if your organization controls other accounts, or is controlled by one, the collective proceeds must stay under 1 million USD to qualify.

App transfers are allowed, but the proceeds for that calendar year attach to both the account that initiates the transfer and the account that accepts it. Moving revenue to a second account does not lower the combined total.

2.3 Wait for it to take effect

Approval is not the same as the rate changing. Your proceeds are adjusted 15 days after the end of the fiscal month in which the enrollment is approved.

Apple's own example: approved on February 10, 2022, adjusted starting March 14, 2022.

The clock starts at approval, not submission, and Apple's fiscal months do not line up with calendar months. How long approval takes is not published anywhere.

3. Enrolling on Google Play

This happens on the Play Console page at Developer account > Associated developer accounts.

Without a payments profile you cannot open that page at all. If you have not started monetizing yet, set the payments profile up first.

3.1 Create an account group

Click "Create account group" and enter a name. Use the legal name for a company, or your developer name for a personal account.

Click "Create account group" again to confirm. Whichever account you used becomes the main developer account for the group.

What if you only own one developer account? You still have to create the group. Enrollment in the 15% tier requires one.

3.2 Answer the two questions

Creating the group takes you straight to two questions. Does your legal entity own any other Play Console developer accounts, and does any other account publish apps under branding similar to yours.

Answer no to both, hit Save, and you are done.

If you answer yes, you add the other accounts by developer account ID or by the package name of one of their apps. The account ID is on the Developer account page, and package names sit under the app name on the All apps page.

Warning

Adding an account sends an approval request to that account's admins. The group is not complete until every associated account agrees to join, and you cannot enroll in the 15% tier while any request is still pending.

Requests you sent show up under "Sent requests" on the same page.

A developer account can only belong to one group at a time. Removing an account from a group can cost it certain benefits, including the 15% enrollment, so do not reshuffle groups casually.

3.3 Enroll in the 15% tier

Once the group is complete, a card appears on the same page offering enrollment in the 15% service fee. "Review and enroll" opens the confirmation screen.

That screen tells you the 15% fee applies to the combined annual sales of every developer account in the group, up to 1 million USD, and lists the accounts it covers.

Google applies it from the enrollment date. There is no waiting period like Apple's. The screen says it directly: enroll after July 1, 2021 and the program starts on the day you enroll.

4. What happens when you pass 1 million USD

On Google Play, once the account group's combined revenue passes 1 million USD, every account in the group pays 30% for the rest of that year. The count is per calendar year, so it resets on January 1.

The App Store also returns you to the standard rate for the rest of the year. The difference is how you get back.

Falling below 1 million USD is not enough on its own. You re-qualify for 15% the year after that. Cross the line in 2026, drop below it in 2027, and you are back at 15% in 2028.

5. Google Play's fee model is changing, and in some places it already has

Google announced a new service fee structure in March 2026. It is rolling out by region: EEA, the UK, and the US switched on June 30, 2026, Australia and Japan follow on September 30, 2026, South Korea on December 31, 2026, and everywhere else on September 30, 2027.

Under the new model, the rate depends on whether a transaction comes from a "new install" or an "existing install."

What decides it is not the buyer but the date that user first installed the app from Google Play, or first updated it from Google Play. On or after the launch date in their region makes it a new install.

New installs look like this. Billing fees are charged separately.

	Non-recurring	Recurring	First purchase of a paid app
Standard	20%	10%	20%
Enrolled in the new apps and games programs	15%	10%	15%
First 1 million USD of annual revenue	10%	10%	10%

Existing installs move the standard rate to 25% and the program rate to 20%. The row for the first 1 million USD of annual revenue stays at 10% in both tables.

Caution

Transactions that go through Google Play billing carry a billing fee on top of the service fee. It is 5% in the US, the UK, and the EEA. For every other region, including Japan and Australia, Google says the rate will be announced later.

If you are modeling your net revenue for a region that has not launched yet, that number is still blank.

Subscriptions land in the 10% row of the new table. Look at the US, UK, and EEA numbers, though, and the 5% billing fee brings the total back to 15%, which is exactly where it is today. Whether the change is a discount depends on the billing fee in your region.

Google has not said whether the "first 1 million USD" row is decided by the existing 15% service fee tier enrollment.

6. Before you start

[ ] Who the Account Holder is on the Apple side
[ ] Whether the latest Paid Applications Agreement is accepted
[ ] Whether you have a Google payments profile
[ ] If you added associated accounts, whether they have all approved

One more thing that is easy to miss: enrolling with the stores does not update your analytics.

If you use something like RevenueCat, change the commission setting in the dashboard too. Otherwise your reported net revenue keeps getting calculated at 30%. Their blog post covers the settings.

https://www.revenuecat.com/blog/engineering/small-business-program

Apple is an agreement plus two questions. Google is a group plus two questions. Neither takes long, and neither happens on its own.

References

App Store Small Business Program (Apple)

https://developer.apple.com/app-store/small-business-program/

Service fees (Google Play Console Help)

https://support.google.com/googleplay/android-developer/answer/112622

Create and manage account groups (Google Play Console Help)

https://support.google.com/googleplay/android-developer/answer/10627869

Google Play's lower service fees (Google Play Console Help)

https://support.google.com/googleplay/android-developer/answer/16954621

Where to draw the line between test and production, when there is no right answer

nicoinu — Mon, 03 Aug 2026 06:54:35 +0000

With billing working on both iOS and Android, the last thing I couldn't settle was where to draw the line between test purchases and production purchases.

The official docs don't answer it. They name two options, list the pros and cons of each, and stop. There's no criterion for picking one.

RevenueCat's own support has answered it both ways, depending on the question. Asked how to handle multiple Expo app variants, they said to create separate Apps inside one Project. Asked about running out of webhooks, they said to split by Project. Both are official answers.

So this isn't an area where you can copy somebody's correct answer. You have to decide from your own conditions, so I turned the branch points into a diagnostic chart. This is a record of that.

I'm on Expo SDK 54 and react-native-purchases v10, with a NestJS backend. The backend has a test environment and a production environment, and the mobile app switches between them by build profile.

"Shipping subscriptions with RevenueCat: from store setup to environment layout" (3 parts)

My subscribe button was greyed out, and that got my app rejected

Android needed almost no code changes, and still ate a full day in configuration

Where to draw the line between test and production, when there is no right answer ← you are here

1. Vocabulary first: "Sandbox" and "your test environment" are different things

The thing that muddies environment design most is using the single word "environment" for two different axes. So let me separate the terms before anything else.

Term	What it is	What it decides	Watch out for
Sandbox / Production	The store's transaction type	Whether a given purchase is a test purchase or a real one	RevenueCat detects this per transaction. There's nothing to configure
Your test / production environment	The API and database you run yourself	Which backend the app is talking to	RevenueCat does not detect this for you
RevenueCat Project	The top-level box holding Apps, Customers and Entitlements	The boundary for configuration and customers	The Customer ID space is per Project. Same Project means a shared space
RevenueCat App	One store app registered inside a Project	Maps to a bundle ID or package name	iOS and Android are separate Apps. Separate Apps still share an ID space if the Project is the same
Entitlement	RevenueCat's state for "Premium is active"	The billing state itself	Not the same as payment. It can be granted without one (section 2)
App User ID	The ID linking a RevenueCat Customer to your user	Whose purchase this is	Pass your database's sequential ID straight through and it can collide across environments
Webhook filters	Settings that narrow where RevenueCat sends events	Which events go where	They do nothing for purchase state the app fetches directly through the SDK

The conclusion up front: splitting Sandbox from Production does not stop users in your test database and your production database from mixing. The store's transaction type and your own backends are separate axes.

You have to decide which axis you actually want to split before you design Projects, bundle IDs and App User IDs.

2. My dashboard was full of customers I didn't recognise

What sent me down this road was something odd on the RevenueCat dashboard.

The Customers list held entries like 1, 2 and 14, bare numbers with nothing else, and I started wondering how test and production were supposed to be distinguished at all.

The reason turned out to be immediate. I was passing my database's sequential userId straight into appUserID on Purchases.configure(). And as the table in section 1 says, the App User ID space is scoped to a Project. My test and production environments used the same Project, so both sets of userId were flowing into the same space.

Here's where it gets bad.

userId=42 in the test environment makes a test purchase
  → RevenueCat Customer "42" becomes entitled
userId=42 in production (a different person) logs in
  → the SDK resolves Customer "42" and grants entitlement to someone who never paid

A production database starts fresh, so its IDs begin at 1. They collide head-on with the IDs I'd been testing with. As production users accumulate, sooner or later somebody lands on a test customer.

Warning
Webhook settings cannot prevent this. RevenueCat webhooks can filter by environment, app and event type, but the flow above never touches a webhook. It happens at the moment the app's SDK talks to RevenueCat directly and receives purchase state, so no amount of server-side defence will fire.

This wasn't a bug in my code. It was a consequence of how I'd structured things. That's what sent me looking for how to split it properly, and straight into the "there is no answer" problem from the intro.

3. Does RevenueCat have a concept of environments?

I went looking for the setting that splits environments. There isn't one. RevenueCat has no switch for toggling between your test environment and your production environment.

Two sentences in the docs explain why.

There's no concept of a sandbox or production user in RevenueCat, since the same App User Id can have both production and non-production receipts.
(Sandbox Testing)

App User IDs are case-sensitive and are scoped to a whole Project.
(Identifying Customers)

The first says one App User ID can hold both test and real receipts. In other words, RevenueCat Customers are designed to span environments by default. The Sandbox data toggle on the dashboard switches which transactions you see. It does not split the Customer.

The second is the one I walked into. The only boundary for the ID space is the Project.

Those are the only two axes of separation on offer, which means "how do I split environments" reduces to "how do I split Projects" and "how do I design App User IDs".

Laid out concretely, there are four places you can split, and each row constrains the one below it.

Where you can split	Options
Bundle ID / package name	One / one per environment (`com.example.app` and `com.example.app.dev`)
Store app registration	One / one per environment
RevenueCat Project	One / one per environment
App User ID namespace	Raw userId / per-environment prefix / unguessable ID

Keep one bundle ID and you keep one store app registration. That thins out the practical benefit of splitting Projects, which leaves you having to separate environments at the App User ID level. How you attack that constraint is the choice in the next section.

4. Looking for a fix, I found two official approaches

App Environment Strategies presents two. On Single Project, the docs say:

Unified API Keys: This approach allows you to use the same RevenueCat API keys across all environments, reducing complexity in your app configuration.

This approach is best for indie projects or cases where the added complexity of multiple projects is unnecessary.

Separate Projects opens with a warning.

This approach increases the risk of projects becoming out of sync, leading to possible issues between environments.

Significant duplication is necessary. You will need to manually replicate all aspects for each environment... This includes paywalls, targeting rules, offerings, and more.

So both options are laid out, but there's no criterion for choosing between them. What surprised me while researching is that the community answers shift with the context of the question.

Context of the question	Answer
How to handle multiple Expo app variants	Create an App per variant inside one Project (= Setup B)
Webhook limits make a multi-environment setup impossible to wire	Split Projects per environment (= Setup C)
How to exclude test users from metrics	Split Projects (charts can be filtered by Project)

And in Best environments strategy, the downside of splitting Projects is put like this:

No downside in having separate accounts or projects for your dev vs. production environments, apart from having to duplicate the setup which may introduce the possibility of typos, etc.

The same duplication gets a warning in the documentation and a "no downside" from support, so opinion inside the company looks split. That makes "follow the official recommendation" hard to act on. You're left deciding from your own conditions, which is what the chart in section 5 is for.

5. How to actually decide: three setups and a diagnostic chart

5.1 The chart

What this chart decides is how many store app registrations and RevenueCat Projects you're going to maintain. The more you split, the fewer accidents of things mixing, and the more times you rebuild the same configuration by hand. The question is where you settle that trade-off.

The three questions work differently from one another.

Question 0: do you need to go through the real stores?

If all you want is to exercise the flow from tapping buy to the entitlement appearing, you don't need store configuration at all. RevenueCat's Test Store (section 6) lets you pick success, failure or cancellation without touching App Store Connect or Play Console. It runs in CI too.

Anyone who answers "no" here doesn't need to split anything yet. The need shows up when you start handing builds to real devices through TestFlight or internal testing and want the store's real purchase flow.

Question 1: do you want different paywalls or prices?

This comes first because the paywall composition (the Offering) and the rules that target it are per-Project settings in RevenueCat. If you need a different set of plans in test, or want to try a different price, splitting Projects is the only way to get it. Nothing else is negotiable after that, so it settles first.

If "test just needs to show the same screen as production" is fine, the later options stay open. In practice, solo projects rarely need per-environment pricing.

Question 2: do you need to block misdelivery structurally?

With one bundle ID, your test build and your production build are the same app as far as the stores are concerned. You cannot structurally prevent uploading a test build to a production track. Careful process is all you have.

What decides it is team size and release procedure. If you're the only one releasing and can check the steps every time, Setup A is enough. If several people touch it, or releases are automated and nobody is looking, splitting bundle IDs into physically separate apps earns its cost.

Note
I ended up at Setup A by answering "same is fine" to question 1 and "process discipline is enough" to question 2. But that was partly because the decision to keep one bundle ID had already been made upstream. Starting from zero, I think I'd have taken question 2 more seriously.

5.2 Setup A: one bundle ID, one Project


What you create	One store app, one set of IAP products, one RevenueCat Project, one API key per platform
Non-negotiable	Give App User IDs an environment namespace (section 7), restrict Sandbox Testing Access (section 6)
The price you pay	No structural block on misdelivering test builds. Can't install test and production side by side on one device. Can't split TestFlight tester groups by environment
Per-environment paywall	Not possible
Fits when	Solo development. Billing gets verified infrequently
Revisit when	The team grows. You need a per-environment paywall. A misdelivery actually happens

This is what the docs recommend for indie projects. If the decision to keep one bundle ID is already made upstream, this is where you land.

5.3 Setup B: split bundle IDs, one Project

Register com.example.app and com.example.app.dev with the stores, and put two Apps inside the same RevenueCat Project (the .dev suffix is just one convention). This is the shape RevenueCat support recommends when asked about Expo app variants.


What you create	Two store apps, two sets of IAP products, one RevenueCat Project holding two Apps, two API keys
Non-negotiable	Give App User IDs an environment namespace (the Project is the same, so the ID space is still shared), keep the test app unreleased
The price you pay	Duplicated store registrations and IAP definitions. Two review processes
Per-environment paywall	Not possible (Offerings are a per-Project setting)
Fits when	Team development. You want the misdelivery path structurally closed
Revisit when	You need a per-environment paywall

Creating two sets of IAP products is not optional. Split the bundle ID without creating store entries and you fetch zero products. That's a store rule, not a RevenueCat one, so there's no way around it. On iOS, RevenueCat support states it plainly in this thread, and a wildcard bundle ID won't substitute. Android is the same.

When calling play store from the SDK, billing client uses the applicationId. On the backend we do the same. So if they are different, it won't fetch any product.
(Android app with different package ids)

Google Play does not treat a .dev suffix as a development build. It's a different app. And the docs say to keep the test app unreleased ("these separate apps should stay unreleased with only the PROD app released into production"), so you take on managing an app that sits in the store without ever passing review.

Warning
Setup B still needs App User ID design.

What gets separated is the store-side app and the RevenueCat App. The RevenueCat Project stays as one, so the Customer ID space that Project owns is still shared. A Customer created from the test app and one created from the production app are the same Customer if the ID matches.

"I split the store apps, so nothing mixes" is wrong. What decides whether things mix is the Project.

5.4 Setup C: one Project per environment


What you create	Two store apps, two sets of IAP products, two RevenueCat Projects, two API keys
Non-negotiable	Replicate paywalls, Offerings, Entitlements and targeting rules across both Projects, and keep them in sync afterwards
The price you pay	Duplicate maintenance. The docs themselves warn it "increases the risk of projects becoming out of sync"
Per-environment paywall	Possible. This is the one decisive advantage of this setup
App User ID design	Not needed (the ID space is split by Project)
Fits when	You want to try per-environment paywalls or prices. You prioritise complete data separation

The easiest thing to overlook in that replication is the paywall. RevenueCat paywalls are remote configuration, so the display changes without shipping a new build. If you build out a paywall in the test Project and forget to mirror it to production, the change never enters your release flow, so no review and no test will catch it.

There is one mitigating factor. Projects under the same App Store Connect account can share an In-App Purchase Key.

Note
One risk doesn't go away even with split Projects: shipping a production build that carries the test Project's API key. RevenueCat support names this as the biggest concern with Project separation. Unless you nail down how keys get injected, the separation buys you less than it looks. How I pass keys through EAS is in part 1.

5.5 The three side by side

	Setup A	Setup B	Setup C
Bundle IDs	1	2	2
Store app registrations	1	2	2
IAP product definitions	1 set	2 sets	2 sets
RevenueCat Projects	1	1	2
App User ID namespacing	Required	Required	Not needed
Per-environment paywall (Offering)	No	No	Yes
Structural block on misdelivery	No	Yes	Yes
Duplicate configuration	None	Store side only	Store side and RevenueCat side
Scale it fits	Solo	Team	Team

The Test Store and StoreKit Configuration Files combine with any of the three (section 6).

6. Three mechanisms that save you from splitting

There are risks you can close out while staying on Setup A. This was the most valuable part of the research.

6.1 Sandbox Testing Access

A Project's General settings hold a three-way choice for whether non-production purchases grant entitlements (Sandbox Testing Access).

Setting	Behaviour	Official use case
Anybody (default)	Every non-production purchase grants entitlements and virtual currency	"recommended for early development or internal QA testing"
Allowed App User IDs only	Only allowlisted app_user_ids are granted	"useful when running restricted tests (e.g: Google Play closed testing)"
Nobody	Non-production purchases grant nothing	When test purchases must not affect entitlements

No money moves in a sandbox purchase, so what this setting decides is only whether that purchase creates billing state.

The default is Anybody, which means that if you've configured nothing, every test purchase you've made during development has created billing state. Those 1, 2 and 14 customers from section 2 were sitting there entitled, off test purchases, before I'd sold anything to anybody.

Ship to production like that and this happens.

[Before launch] test purchases during development leave
  Customers "1", "2" and "14" holding active entitlements

[After launch] the production database starts issuing IDs at 1
  The first real user gets userId=1
  → the app calls Purchases.logIn("1")
  → it resolves the existing Customer "1"
  → the entitlement created during development is still valid. Premium without paying

Structurally this is the collision from section 2, except this one starts with your day-one signups and works its way up, because the low IDs are the ones you hammered during development.

Tightening this setting also removes entitlements that were already granted.

Previously granted entitlements will be removed. If a customer no longer qualifies under the updated setting, any active entitlements previously granted from non-production purchases will be automatically removed.

So it isn't only prevention. It also cleans up the billing state you accumulated during development. Virtual currency stays, though ("Virtual currency already granted will remain.").

Which gives you this by phase.

Phase	Setting	Why
During development	Anybody (leave the default)	You want your own test purchases to grant entitlements. Tighten it and you can't verify anything
Before launching to production	Allowed App User IDs only	Clear the accumulated state and stop real users from picking it up

Nobody isn't really selectable. Purchases from TestFlight and Google Play internal testing are sandbox purchases even when the distributed build is production-signed (part 1). Set it to Nobody and testers never become entitled, so you can't hand out a build and verify anything. Test Store purchases are non-production too, so they stop as well. As long as you're still iterating on billing, Allowed App User IDs only is as tight as you can go.

Tightening after launch does remove the entitlements, but it doesn't undo the fact that somebody had Premium for free until then. Nothing failed, so there's no error and no log, and no way to notice.

Warning
This setting alone isn't enough. The allowlist matches on the app_user_id string.

If both test and production pass a bare 42, they're the same string, so "allow only the test 42" is not expressible. Only once you add the prefix from section 7 and get dev_42 and prod_42 can you register just the dev_ side.

6.1 is not a replacement for section 7. It's a second layer on top of it. The order is: introduce the prefix from section 7, then this setting, then launch.

The operational cost of the allowlist is adding IDs by hand as testers accumulate. It's still cheaper than maintaining paywalls and Offerings twice, and this one issue is not a reason to split Projects.

6.2 Webhook filters

The Webhooks settings offer two narrowing controls: send to one App in the Project or all of them, and send production purchases only, sandbox only, or both.

So on a single Project you can route sandbox events to your development API and production events to your production API. Webhook separation is not a reason to split Projects.

Warning
That said, a Project is capped at five webhooks, and you can't reuse the same URL. Five is plenty for a single app, but it needs watching if you keep several apps in one Project.

6.3 Test Store

Test Store, which landed in December 2025, changes the premise of this whole discussion. I found out about it after I'd already finished the store configuration, so I never used it. It should help anyone walking the same path from here, so I'm writing up what I found.

It's a fake store RevenueCat provides, processing purchases in place of the App Store and Google Play.

test purchases behave like real purchases and subscriptions: they update CustomerInfo, trigger entitlements, and appear in your RevenueCat dashboard

Without registering a single product with a store, you can exercise the buy button, the CustomerInfo update, and the entitlement grant.

Where it earns its keep is local development and CI. Real store test purchases need a human to work the payment sheet, so they can't be automated, whereas the Test Store lets you specify success, failure or cancellation and drive it from test code. Branches like "keep Premium until the period ends even after cancellation" become checkable without waiting on sandbox's accelerated renewals.

What it can't confirm is equally clear. It doesn't go through real payment processing or the store's purchase sheet, so it tells you nothing about whether your product configuration in App Store Connect or Play Console is correct. It doesn't replace distribution testing through TestFlight or internal testing either. Every hour I burned in parts 1 and 2 was on that side of the line, so the Test Store wouldn't have saved any of it.

There are two constraints. The first is renewal count.

Each test subscription will renew automatically up to 5 times

It stops after five, then cancels, and the entitlement goes inactive. The second is that you must not ship it.

Warning

Never submit an app to the App Store or Google Play that is configured with a Test Store API key.

I've seen secondary sources say the API key is prefixed test_, but the official documentation page doesn't state it. You'll want to check the actual value in the dashboard.

To summarise, the Test Store is for development and CI. If you're at the "I just want to run the purchase flow locally and in CI" stage, you don't yet need to claim a dev bundle ID and create store entries. It doesn't make the Setup B and C discussion go away. It moves the point where you have to have it.

7. What I actually implemented: environments in the App User ID

Having decided not to change the setup, the collision from section 2 had to be stopped on the App User ID side. In Setups A and B, this is the last line of defence against customers mixing.

The idea is plain: prefix the ID with the environment and treat it as a separate namespace. Test becomes dev_42, production becomes prod_42.

7.1 Implementation

This only holds if the app and the server follow the same convention, so I put it somewhere both can reach.

// shared module, referenced by both the app and the server
export const APP_ENVIRONMENTS = { DEV: 'dev', PROD: 'prod' } as const;
export type AppEnvironment = (typeof APP_ENVIRONMENTS)[keyof typeof APP_ENVIRONMENTS];

const SEPARATOR = '_';

/**
 * Mobile passes EXPO_PUBLIC_APP_ENV, the API passes NODE_ENV.
 * Only "production" and "prod" count as prod. Everything else falls back to dev.
 */
export const resolveAppEnvironment = (value: string | null | undefined): AppEnvironment => {
  const normalized = value?.trim().toLowerCase();
  if (normalized === 'production' || normalized === 'prod') return APP_ENVIRONMENTS.PROD;
  return APP_ENVIRONMENTS.DEV;
};

export const buildRevenueCatAppUserId = (env: AppEnvironment, userId: number): string =>
  `${env}${SEPARATOR}${userId}`;

/** Returns null for another environment's prefix, anonymous IDs, and unprefixed IDs. */
export const parseRevenueCatAppUserId = (
  appUserId: string,
  env: AppEnvironment,
): number | null => {
  const prefix = `${env}${SEPARATOR}`;
  if (!appUserId.startsWith(prefix)) return null;

  const raw = appUserId.slice(prefix.length);
  // Number.parseInt would happily accept "14abc" as 14, so match strictly
  if (!/^\d+$/.test(raw)) return null;

  const userId = Number.parseInt(raw, 10);
  return Number.isSafeInteger(userId) && userId > 0 ? userId : null;
};

Three deliberate choices in there. Environment resolution falls back to dev. If the check fails, landing in dev does less damage than polluting the production namespace. The parser doesn't use bare parseInt. Number.parseInt("14abc", 10) returns 14. And an unprefixed, bare ID is not processed in any environment, so an event arriving from an older build that predates the convention never gets attached to the wrong person.

Rebind whenever the login state changes.

// src/providers/purchases-provider.tsx
const currentAppUserId = getRevenueCatAppUserId(user?.id) ?? null;
if (currentAppUserId === lastAppUserIdRef.current) return;

if (currentAppUserId) {
  const { customerInfo: info } = await Purchases.logIn(currentAppUserId);
  setCustomerInfo(info);
} else {
  const info = await Purchases.logOut();
  setCustomerInfo(info);
}
lastAppUserIdRef.current = currentAppUserId;

Note
logOut() generates a new anonymous ID. Calling logOut then logIn to switch accounts leaves one stray anonymous customer behind. For a switch, call logIn() directly.

7.2 Where this approach stops

It isn't a cure-all, so here are its limits.

Warning
The environment prefix approach is not in the official documentation. Neither Identifying Customers nor the environment strategies page describes it. It's my own workaround for the single-Project constraint, not an official recommendation.

And a prefix only solves namespace collision. Unguessability remains a separate requirement.

App User IDs should not be guessable
A non-guessable pseudo-random ID, like a UUID (RFC 4122 version 4), is recommended

The docs say this because app_user_id is itself the key that resolves billing state. Adding a prefix doesn't help if the ID body is easy to guess. The two solve different problems, so you stack them.

Element	Problem it solves
The `dev_` / `prod_` prefix	ID collision across environments (section 2)
An unguessable ID body (UUIDv4 or similar)	The official "should not be guessable" requirement

Combined, you get something like prod_3f2b1c8e-.... The code above uses sequential IDs to show the mechanism, but a setup that ships to a store should use an unguessable body. That also happens to satisfy the general rule about not handing your database's primary key to an external service.

There are values you must not use for app_user_id. RevenueCat blocks no_user, null, none, nil, (null), NaN, the empty string, unidentified, undefined, unknown, anonymous, guest, -1, 0, [], {}, [object Object], and any ID containing /. The length limit is 100 characters. Don't use email addresses or the IDFA (guessable, and the IDFA rotates). A hardcoded constant is forbidden too: it makes every install the same user, so people who never purchased end up entitled.

8. Wrapping up

8.1 The hardest part

Almost none of the difficulty in this article was in the implementation.

The hardest part was that researching it didn't produce an answer.

Getting rejected on iOS (part 1) and losing a day to Android configuration (part 2) were problems where I was stuck, but a correct answer existed somewhere. Read the error, search the docs, and failing that read your own logs, and you land.

Environment layout wasn't like that. The documentation and support don't fully agree with each other, and there was almost nothing written about it in Japanese.

What makes it worse is how hard the mistakes are to detect. Get the configuration wrong and purchases still succeed. The app still works. You can eventually spot that a user ID from your test environment and a different person in production have become the same customer, but not one error was raised along the way.

I wrote this up because I think the error handling, the review requirements and one worked example of reasoning about environment layout are worth leaving behind.

8.2 What to decide on

Which setup fits obviously depends on the project, but: Setup C if you need per-environment paywalls, Setup B if you want misdelivery of test builds structurally blocked, Setup A otherwise.

Here are the inputs I used, gathered up.

Splitting bundle IDs splits your store app registrations. There's no avoiding it
Splitting Projects duplicates paywalls, Offerings and targeting rules. And because the paywall is remote configuration, a missed update never enters your release flow
The "test purchases entitle production users" risk closes with two layers: the App User ID prefix and Sandbox Testing Access. That setting also clears state that's already been granted, so tighten it before launch. This alone is not a reason to split Projects
Webhooks can be routed per App and per environment inside one Project. The cap of five is the thing to watch
If you only need local and CI testing, the Test Store lets you skip store configuration entirely

In Setups A and B, App User ID design is the defence line. It's also a workaround of my own that isn't in the docs. Since the prefix only covers environment collision, the official "use an unguessable ID" requirement has to be satisfied separately, in the ID body.

References

Android needed almost no code changes, and still ate a full day in configuration

nicoinu — Sun, 02 Aug 2026 14:16:25 +0000

Once subscriptions were working on iOS, I added Android billing to the same app.

The app code I changed came to one place, in practice: the branch that picks an API key per platform. And I had already written that back when I did iOS.

The configuration is where the day went. Play Console, RevenueCat, and a handful of Android behaviours I didn't know about. This is a record of that.

I'm on Expo SDK 54, react-native-purchases v10, with a NestJS backend.

"Shipping subscriptions with RevenueCat: from store setup to environment layout" (3 parts)

My subscribe button was greyed out, and that got my app rejected

Android needed almost no code changes, and still ate a full day in configuration ← you are here

Where to draw the line between test and production, when there is no right answer

1. First, the vocabulary: a Play product has two levels

In part 1 I described how RevenueCat's Product, Entitlement and Offering do three different jobs. Adding Android doesn't change that structure. You just get more Products.

What changes is how you create a Product, and this is where Google diverges sharply from Apple.

	App Store Connect	Google Play Console
Shape of a product	One product, one level	A "base plan" inside a "subscription": two levels
Monthly vs yearly	Put them in the same Subscription Group	Create them as separate subscriptions (there is no group concept)
ID you register in RevenueCat	`premium_monthly`	`premium_monthly:monthly` (subscription ID : base plan ID)

On Google Play you first create a container called a subscription, then create a base plan inside it that holds the billing period and the price. The base plan is the thing that actually charges.

Note
premium_monthly and monthly in that table are names I made up for this article. Neither is a reserved word, so you pick both strings yourself.

What matters is that when you register the product in RevenueCat, those two levels become a single ID joined by a colon.

Those two levels are also what cost me half a day later on.

2. The code I changed came to one place

I'd written the platform split during the iOS work. This is the only thing I touched in the app for Android.

// src/providers/purchases-provider.tsx
const getApiKey = (): string | null => {
  if (Platform.OS === 'ios') return process.env.EXPO_PUBLIC_REVENUECAT_IOS_API_KEY ?? null;
  if (Platform.OS === 'android') return process.env.EXPO_PUBLIC_REVENUECAT_ANDROID_API_KEY ?? null;
  return null;
};

Since that was already there, all I really did was add the Android key to my environment variables.

The server needed zero changes. In the webhook RevenueCat sends, the field naming the store flips from APP_STORE to PLAY_STORE, and the existing handling takes it from there. Neither the app nor the server looks at anything but the entitlement, so adding a store doesn't add a branch.

Note
You don't have to add the Android billing permission by hand either. Autolinking in react-native-purchases merges it into AndroidManifest.xml. There was no native configuration work at all.

So the substance of "adding Android" was configuration from the start.

3. Snag 1: not a single product came back

I created the subscription and base plan in Play Console and activated them. I created a GCP service account, connected it to RevenueCat, registered the Android products, and attached them to an entitlement.

I opened the purchase screen and got zero products. The log had this.

Offerings fetch failed [23] ConfigurationError

With this body.

You have configured the SDK with a Play Store API key, but there are no
Play Store products registered in the RevenueCat dashboard for your offerings.

Open RevenueCat's Products screen and they're right there. The Entitlements column even says "1 Entitlements".

Registered. Attached. Still not delivered. I spent about an hour going back and forth over the Play Console side. Is the base plan active, is there a price on it, is the app published to a track. All of it was fine.

4. Six words: "for your offerings"

Then I reread the error.

there are no Play Store products registered in the RevenueCat dashboard for your offerings

It doesn't say there are no products. It says there are no products for your offerings. I had been reading straight past those last three words.

Caution
RevenueCat configuration has three stages, and stopping at the second one gets you zero products.
1. Products      register the product      premium_monthly:monthly
      ↓
2. Entitlements  attach it to premium      ← this is what shows "1 Entitlements"
      ↓
3. Offerings     put it in a Package on default   ← the one you forget
Finish stage two and the Products list reports "1 Entitlements". That is the trap: it looks done. But the app fetches from the Offering, so skipping stage three leaves you with an Offering that holds no Play products at all.

In the vocabulary section of part 1, I drew Product with two arrows coming out of it, one to Entitlement and one to Offering. The Offering arrow is exactly the one I forgot. I drew the diagram myself and then walked into it.

The fix is just RevenueCat → Offerings → default → add the Android products to each Package. Don't remove the iOS products. A Package means something like "the monthly slot", so the App Store product and the Play Store product sit in it side by side.

5. Snag 2: the release build failed lint

With products showing up, I built for distribution. lintVitalRelease failed, on ExtraTranslation.

The cause was the locales setting in app.config.ts. I had written it thinking of iOS only, and it applies to Android too. It generates values-b+{lang}/strings.xml per locale, and iOS-only keys (the usage descriptions for camera and microphone) were being emitted into them. There's no matching string on the default locale, so lint calls it an extra translation and fails the build.

I fixed it by nesting those under an "ios" key inside the locale JSON so they never reach Android.

Warning
This is the kind of problem you cannot see from iOS. I should have pushed one release build through the moment I added Android. The development build passes, so it stays hidden until you're about to distribute.

6. Snag 3: the app I'd just fixed wouldn't start

I fixed the lint error, built locally, installed to the device, and got the old behaviour. My change looked like it hadn't taken.

I started suspecting configuration again. This time two causes were stacked on top of each other.

Caution
First. I use appVersionSource: "remote", so versionCode in android/app/build.gradle was still sitting at its initial value of 1. The device had the build Play had delivered (31 at the time), so the install was being refused as a downgrade.

Second. adb install can return exit code 0 even when it fails. My build script took that as success and moved on, and what actually launched was the old app.

So my fix had never reached the device, and I was reading behaviour as though it had. I suspected the code, then the configuration, and skipped the one thing worth suspecting first: whether the thing was installed at all.

I now sync versionCode in the build script to something above what's on the device, and verify the install result explicitly.

7. Snag 4: the manage button opened nothing

Purchases were going through, so I checked the cancellation path. Tapping "Manage subscription" produced a generic error and opened nothing.

I took the long way round here too. I suspected the device couldn't open Play's subscription screen, so I fired it with am start, and it opened fine. I thought the management URL from RevenueCat might be empty, but the code wasn't even getting that far. I assumed a configuration mistake, but there was not one matching error anywhere.

I found it the moment I stopped swallowing the exception.

// Before. The exception isn't bound, so nothing reaches the log
try {
  await manageSubscriptions();
} catch {
  Alert.alert(t('common.error'), t('pricing.error.manageFailed'));
}

I changed catch {} to catch (err), logged it, rebuilt, and had the answer on the first run.

[Purchases] showManageSubscriptions failed
  [Error: This method is not available in the current platform.]

Caution
Purchases.showManageSubscriptions() is an iOS-only API. It isn't implemented on Android. The management URL was never empty. The method simply doesn't exist on the platform.

iOS has a system-provided management sheet. Android has no equivalent. You have to send the user to the relevant Play Store screen yourself.

The fix branches on platform and keeps three levels of fallback.

// src/providers/purchases-provider.tsx
const STORE_SUBSCRIPTION_URL: Record<string, string> = {
  ios: 'https://apps.apple.com/account/subscriptions',
  android: 'https://play.google.com/store/account/subscriptions',
};

const manageSubscriptions = async () => {
  // showManageSubscriptions() is iOS-only and always fails when called on Android
  if (Platform.OS === 'ios') {
    try {
      await Purchases.showManageSubscriptions();
      return;
    } catch (err) {
      console.warn('[Purchases] showManageSubscriptions failed', err);
    }
  }

  const fallbackUrl = customerInfo?.managementURL ?? STORE_SUBSCRIPTION_URL[Platform.OS];
  if (!fallbackUrl) {
    throw new Error(`No subscription management URL available for platform ${Platform.OS}`);
  }
  await Linking.openURL(fallbackUrl);
};

Warning
The hardcoded URL at the third level is there because the management URL RevenueCat returns can be empty on a perfectly healthy path. The type is string | null, and it comes back empty for test purchases and in the window right after a purchase while state is still syncing. Getting stuck here removes the user's way to cancel, so I keep a last resort.

8. What the four had in common

Looking back at the day, none of the four snags was technically hard. What was hard is that they were failing without looking like they were failing.

Where I got stuck	Why the failure was hidden
No products returned	"1 Entitlements" in the Products list made it look finished
Release build failed	The development build passes, so it stays out of sight until distribution
Fix didn't take	`adb install` returned 0 after failing
Manage screen wouldn't open	`catch {}` threw the exception away

An error you can see is an error you can read. The nasty case is when a healthy-looking screen or exit code is covering a failure. What I added over that day wasn't a feature. It was emulator startup logging, install verification, and exception output on the purchase screen.

9. Test settings that keep you off a real card

I push to the internal test track and verify on a real device.

pnpm build:development:android    # build the AAB
pnpm submit:development:android   # upload to the internal test track

In Play Console you register your testers' email addresses, and each tester opens the opt-in URL and accepts. Without that, they can't even see the app.

On top of that, there is a second registration you need.

Caution

Users incur actual charges for their test track purchases unless the user is a license tester.
(Test your Google Play Billing Library integration)

Buy with an account that isn't registered as a license tester and you are charged on a real credit card. That holds even for a build installed from the internal test track. It isn't decided by the track. It's decided by whether the purchasing account is a license tester.

You register them under Settings → License testing in Play Console. You can tell it worked by whether the purchase sheet says "Test card, always approves". If you see an actual card, stop right there.

10. On Android, a cancellation path is mandatory

The management link I fixed in section 7 is not a nice-to-have on Android.

Google Play policy requires that you provide a way to cancel from inside the app (Manage and cancel subscriptions). Linking out to the Play Store management screen is the straightforward way to satisfy it.

Apple's review requirement for the purchase screen (3.1.2(c)) asks for something different: that the subscription auto-renews, its duration, its price, and links to terms and privacy. An in-app management link isn't on that list.

Warning
So the bug in section 7 reads as "one button doesn't work" if you're only looking at iOS, and as a policy risk on Android. Shipping it broken wasn't an option.

11. Wrapping up

Three things came out of adding Android.

Absorbing platform differences in the first implementation really does pay. Because I'd written the API key branch during the iOS work, app code changes were close to zero. The flip side is that anywhere I skipped a branch because iOS worked fine, like showManageSubscriptions(), Android surfaced it immediately.

Don't carry iOS concepts over unexamined. There is no Subscription Group, product IDs are two levels joined together, there's no native management API, and even the renewal interval during testing is different. About all the two have in common is the word "store".

Make failures look like failures. Don't write catch {}, don't trust an exit code, don't treat a dashboard label as proof of completion. All four of these were preventable by that alone.

Next: where to draw the line between development billing and production billing. RevenueCat's own docs offer two options and stop there, and it's an area where staff answers point in opposite directions depending on who asked.

References

My subscribe button was greyed out, and that got my app rejected

nicoinu — Sat, 01 Aug 2026 16:22:14 +0000

I was building toward Shipaton, RevenueCat's hackathon, so I added a RevenueCat subscription to a side project I'd built with Expo and submitted it to the App Store. The first submission came back rejected on three counts.

Two of them I could fix by rereading the guidelines. The third was the annoying one: the subscribe button wouldn't respond. On my simulator, the exact same code let me buy the thing without any trouble.

What gave it away was opening my server logs and finding nothing there. Not an error. Not a single line.

I'm on Expo SDK 54, react-native-purchases v10, with a NestJS backend.

"Shipping subscriptions with RevenueCat: from store setup to environment layout" (3 parts)

My subscribe button was greyed out, and that got my app rejected ← you are here

Android needed almost no code changes, and still ate a full day in configuration

Where to draw the line between test and production, when there is no right answer

1. The vocabulary: three words that do three different jobs

1.1 How IAP and RevenueCat relate

IAP (In-App Purchase) is the store's own billing machinery. You reach it through StoreKit on iOS and Google Play Billing on Android. Payment and receipts are handled entirely on the store side. You don't get to build your own checkout.

RevenueCat is a layer on top of that. It flattens the two stores' IAP into a single model, so you can ask who bought what and whether it's still active.

So billing itself belongs to the store, and what RevenueCat gives you is a layer that makes that state easy to work with. Even with a single store, it saves you from writing receipt validation and renewal tracking yourself.

1.2 Product, Entitlement, Offering

The vocabulary is where RevenueCat first trips you up. Product, Entitlement and Offering all sound alike, and the names don't tell you how they connect. You also have to wire up all three before a single product comes back.

The trick is noticing that the three do genuinely different jobs.

Term	What it is	Its job	Watch out for
Product	Something you listed on a store	What you sell	Each store has its own copy
Entitlement	The state of "this feature is unlocked"	What the user can use	The only thing your app checks
Offering / Package	The set you put on the paywall	What you show right now	Skip this and you get zero products

Note
The names premium_monthly, premium_yearly, premium and default below are all made up for this article. None of them are reserved, so you can use whatever strings you like. The exception is identifiers starting with $rc_, like $rc_monthly and $rc_annual: those are RevenueCat's conventional names, and using them makes it easier for the SDK to tell monthly from annual.

Drawn out, the connections look like this.

Again, premium_monthly and friends are placeholders for whatever product IDs you pick.

Products are per store. The "monthly plan" you registered on the App Store and the one on Google Play are two different products. Add Android later and one plan turns into two products.

Entitlements collapse that back down. All four products above end in the same place: Premium is unlocked. Your app only ever reads the entitlement, so it never needs to know which store or which plan the purchase came from. Add stores or plans and the check in your app stays exactly as it was.

An Offering is what you put on screen right now. Packages are the slots, "the monthly one" and "the annual one", and you drop each store's product into a slot. Your app fetches the offering and lays out the slots it gets back.

The payoff of keeping this separate is that you can change how you sell without shipping an app update. If you decide to push the annual plan, or run a limited-time plan, you swap the offering in RevenueCat and the paywall changes.

Note
As the arrows show, two lines leave each product: one to an entitlement, one to an offering. One of them is not enough. Wire up only the entitlement and you land in the state where buying grants access, but the paywall has nothing on it.

Later in this article, I forget the offering half and walk away convinced I'm done.

2. Rejected on three counts

Review came back in one to three days, with three items.

Guideline	What they flagged
4.8 Login Services	Google sign-in with no equivalent privacy-preserving option
3.1.2(c) Subscriptions	No functional links to the EULA and privacy policy inside the purchase flow
2.1(b) App Completeness	The subscribe button is greyed out

The first two tell you what to do if you read them. The third was the problem, because it worked on my machine.

3. Rejection 1: I only offered Google sign-in

Apple's rule is simple. If you offer Google, you have to offer an equivalent privacy-preserving login too, which in practice means adding Sign in with Apple.

Four things to do: add expo-apple-authentication; set ios.usesAppleSignIn: true and the plugin in app.config.ts; add an endpoint on the API that verifies the identity token; and put the official Apple button on the login screen with at least as much visual weight as the Google one. Then enable the "Sign In with Apple" capability on your App ID in the Apple Developer portal.

Note
Server-side verification is just public key verification against Apple's JWKS, so you don't need a private key or a Services ID. That part was easier than I'd braced for. Enabling the capability invalidates your provisioning profile, but the next eas build regenerates it for you.

4. Rejection 2: my policy link only existed in one place

I'd put a Privacy Policy URL in the App Store metadata and assumed that covered it. It did not.

Warning
You need the links in the app and in the metadata. Either one alone will fail.

In the app: put tappable links to the EULA and the privacy policy on the paywall screen (WebBrowser.openBrowserAsync)

In the metadata: the Privacy Policy URL field in App Store Connect. For the EULA, link it from the description if you use Apple's standard one, or fill the EULA field if yours is custom

When I resubmitted, I attached a screen recording in Resolution Center. Apple asks for one explicitly on 3.1.2.

5. Rejection 3: the subscribe button stayed grey

Here's the real story.

I opened the build I'd distributed through TestFlight, and there was no price.

The amount shows as —. RevenueCat returned zero products, so there's no price to render, and the button does nothing. This is the screen the reviewer saw.

Let me kill one common misreading first.

Warning
Grey does not mean "still in review". Products are supposed to show up in Sandbox even while the IAP status says "Waiting for Review". The rejection email says as much. Reviewers go all the way through a Sandbox purchase, so if the button isn't live at the moment you submit, you fail.

So this wasn't going to fix itself once review passed. It had to be fixed right then.

And the awkward part: the same code showed products just fine in the simulator. I couldn't reproduce it locally. Works here, broken only in what I shipped, which is the worst place to be.

6. Not a single log line

You can't attach a debugger to a distribution build, so I needed some way to see what was happening from the outside.

I kept the RevenueCat state in a module-level variable, attached it to every request header through an axios interceptor, and logged it on the server.

// src/lib/iap-diagnostics.ts
const state: IapDiagSnapshot = {
  offeringId: null,
  packageCount: null,
  lastError: null,
  lastUpdatedAt: null,
};

export const updateIapDiagnostics = (patch: Partial<IapDiagSnapshot>): void => {
  Object.assign(state, patch, { lastUpdatedAt: new Date().toISOString() });
};

export const getIapDiagnosticsHeader = (): string | null => {
  if (!state.lastUpdatedAt) return null;
  return JSON.stringify({
    offering: state.offeringId,
    pkg: state.packageCount,
    err: state.lastError ? state.lastError.slice(0, 200) : null,
  });
};

// src/lib/api/axios-instance.ts
axiosInstance.interceptors.request.use((config) => {
  const diag = getIapDiagnosticsHeader();
  if (diag) config.headers.set('X-Iap-Diag', diag);
  return config;
});

I opened the server logs and went looking for requests from the TestFlight build.

There was nothing.

Not an error. The diagnostic line simply never appeared.

The header is only attached once something has written RevenueCat state at least once. Zero lines meant that write had never run, which meant the app was never even reaching RevenueCat's initialization.

So it wasn't that products failed to load. Billing wasn't running at all.

Note
The absence of the log was the answer. When you go in looking for an error, an empty result reads as "I haven't looked hard enough yet". Decide up front on something that must always appear when things are healthy, and its absence becomes evidence.

What the log says	What it means
`pkg:2, err:null`	Healthy. The button should be enabled
`pkg:0, err:"...has no packages..."`	StoreKit returned nothing. Paid Apps agreement, or the product wiring
`pkg:0, err:"No current offering..."`	No offering is marked current in RevenueCat
`err:"Offerings fetch failed [CODE]..."`	The fetch itself threw. Wrong API key lands here
nothing at all	Initialization was never reached. The API key isn't in the build

7. The cause: eas build doesn't read .env

Once I knew initialization wasn't running, the code told me why immediately. When the API key is missing, I'd chosen to disable billing rather than crash.

// src/providers/purchases-provider.tsx
const apiKey = getApiKey();
if (!apiKey) {
  console.warn('[Purchases] RevenueCat API key is not set. Subscription features disabled.');
  setIsReady(true);
  return;   // ← bails out here, so the diagnostic line is never written either
}

That early return is what produced a build where nothing happens at all.

So why was the key missing from the distribution build?

Caution
eas build never reads .env.

A local dev build (expo run:ios and friends) reads .env and injects EXPO_PUBLIC_* into your JS. That's why the simulator showed products

eas build only looks at env in eas.json and at EAS Environment Variables. If the key isn't registered there, you never reach Purchases.configure()

The difference between the simulator and TestFlight wasn't the code and it wasn't the environment. It was how the key gets delivered.

The fix is to register the key with EAS.

# register it in both environments so billing also works in development builds
eas env:create --name EXPO_PUBLIC_REVENUECAT_IOS_API_KEY --value "appl_xxxxxxxx" \
  --visibility sensitive --environment development --environment production

Note
You can't pick secret for --visibility. Anything EXPO_PUBLIC_ is baked into the binary, so it can't be kept secret in the first place. Choosing sensitive is about keeping the key out of git; the fact that it ships inside the app is by design.

After a rebuild the diagnostic line read pkg:2, err:null and the button came alive. That was the real fix for 2.1(b).

8. The order I should have done all this in

Looking back, every place I got stuck was something the right order would have avoided. These tasks depend on each other, and doing a later one before an earlier one finishes is wasted effort.

8.1 Start the business setup first

This is the paperwork under "Business" in App Store Connect.

Caution
Until the Paid Apps agreement is active, your app can't fetch a single product. Correct code and correct RevenueCat configuration don't matter; you get back an empty list. Apple's side takes anywhere from a few hours to two days, so start it before anything else.

In App Store Connect you need to accept the Paid Apps agreement, add a bank account, complete the tax forms (W-8BEN-E if you're a Japanese entity) and, if you distribute in the EU, the DSA trader declaration. Build while you wait.

One clarification: "Apple handles the taxes" is a half-truth. Apple handles consumption tax, VAT, sales tax and withholding. Declaring your own income is still on you.

8.2 Add the API key before wiring the three layers

This is the key RevenueCat uses to query Apple for product information. You issue it in App Store Connect and register it in RevenueCat, so it spans two dashboards. Issue it under Users and Access → Integrations → App Store Connect API, then add it to your RevenueCat project settings.

Warning
Skip this and the Store Status in RevenueCat's product list sits at "Could not check", which makes product delivery flaky. Also, App Store Connect lets you download the .p8 file exactly once. Lose it and you're issuing a new one.

Then wire up the three layers from section 1 in the RevenueCat dashboard. Once you create an offering, don't forget to hit Make current. Your app asks for the offering that is current, so if you skip that click, products come back empty. I managed to produce exactly that state once: everything configured, nothing on the paywall.

8.3 Put the products in the same Subscription Group

This part happens in App Store Connect, under Monetization → Subscriptions. Subscription Group is an Apple concept with no counterpart in RevenueCat.

Warning
When you create the monthly and annual products, put them in the same Subscription Group. In separate groups Apple no longer treats the move as a plan change, so upgrades and downgrades don't work. The same user can end up subscribed to both, which is a double-billing risk. Within one group Apple also handles the proration for you.

On the same screen, each subscription requires a screenshot under its review information. One taken from the Sandbox purchase screen is accepted.

8.4 The only way out of "Missing Metadata"

You can fill in every field on the product and the status still sits here.

Nothing on the screen tells you what's missing. I went back and forth on this one for a while too.

Caution
The only way out is to attach the product to an app version and submit it for review.

Distribution → the version → pick a build → In-App Purchases and Subscriptions → attach → submit for review.

A product can't get there on its own. It only becomes submittable together with an app version.

You don't have to wait for the review to be approved, though. The moment you press submit in App Store Connect, purchase testing works in TestFlight. I'd convinced myself that testing had to wait for approval and put off submitting, which cost me a few days for nothing.

8.5 Record three kinds of offering failure, not one

The diagnostic table in section 6 only works because I never collapsed these failures into a single error.

const loadOffering = async () => {
  try {
    const offerings = await Purchases.getOfferings();

    // failure 1: no offering is marked current
    if (!offerings.current) {
      setLastOfferingError('No current offering configured in RevenueCat dashboard');
      return;
    }

    // failure 2: there is an offering, but no packages (store propagation, etc.)
    if ((offerings.current.availablePackages ?? []).length === 0) {
      setLastOfferingError(`Offering "${offerings.current.identifier}" has no packages`);
      setOffering(offerings.current);
      return;
    }

    setLastOfferingError(null);
    setOffering(offerings.current);
  } catch (err) {
    // failure 3: it threw. A wrong API key shows up here
    const e = err as { code?: string; message?: string };
    setLastOfferingError(`Offerings fetch failed [${e?.code ?? 'UNKNOWN'}]: ${e?.message}`);
  }
};

Different causes need different fixes. Had I logged all of these as "couldn't load products", the triage in section 6 wouldn't have been possible.

8.6 Never hardcode the price in your UI

Prices are decided in App Store Connect and Google Play Console. Your app should render the price string the RevenueCat SDK hands back, and nothing else.

// in the app: don't assemble the amount, just print the display string from the SDK
const label = pkg.product.priceString;   // e.g. "¥1,000"

Warning
Picking the same price tier does not produce the same yen amount on the App Store and Google Play. Apple uses price tiers, Google is configured per country, so matching the USD price still leaves the yen prices apart. On top of that, Apple's yen prices shift tiers with exchange rates.

Use the string from the SDK and each store shows its own correct amount. Write the number into your code or your design docs and it will be a lie on at least one store.

9. An aside: subscriptions renew at a different speed while testing

I bought a subscription, walked away for a bit, came back, and the billing state had rolled forward several times. Test environments deliberately compress the subscription period.

The confusing part is that the speed is set by the account you bought with, not by the environment. A TestFlight build also runs against sandbox, so "TestFlight" doesn't mean "slow".

Account used for the purchase	Renewal speed	Stops after
A TestFlight tester (a normal Apple ID)	Once a day, whatever the period	6 renewals
A Sandbox Apple Account	One month becomes 5 minutes by default. Four rates to choose from	12 renewals

What confused me was using a normal Apple ID in TestFlight. I sat there expecting a renewal within minutes, and nothing happened until the next day. Buy with a Sandbox account instead and it cycles several times in minutes, so if you step away you come back to an expired subscription. Check the billing state right after purchase.

You can pick the compression rate in TestFlight too, as long as you sign in with a Sandbox account.

Android's license testers have their own, different table of compressed periods, so iOS intuitions won't carry over. That's for the next part.

One more thing about Sandbox purchases in the simulator. The simulator has no Settings → App Store → Sandbox Account entry. You end up typing the Sandbox tester's credentials straight into the purchase dialog. That was unstable for me, and purchases kept getting treated as cancelled. Recreating the tester usually fixed it, but switching to a real device and TestFlight turned out to be faster than fighting it.

10. Resubmitting, and getting stuck again

Three items fixed, so all that was left was submitting. Or so I thought.

Warning
Replying in Resolution Center is not a resubmission. A reply doesn't move you back into review. It's supplementary, and useful for attaching a screen recording, but you still have to press "Update review content" on the version page.

Builds are locked while review is in progress. To swap one out you withdraw the submission and take the version back to "Prepare for Submission".

Then, when I went to resubmit, the "In-App Purchases and Subscriptions" section had vanished from the page. That's the field I'd finally managed to fill in back in section 8.4, so I assumed it had come unattached.

Note
That section only appears while you have unsubmitted IAPs in "Ready to Submit". Once submitted, an IAP is tracked separately as awaiting review or approved, so the section disappearing means it's attached. That's the normal state. Check the status under Monetization → Subscriptions instead.

11. Wrapping up

The code that calls the SDK came to about 200 lines, initialization and entitlement checks included. The time went into four things, none of which are code.

Waiting for Apple's business setup to go active (a few hours to two days)
Working out how to escape "Missing Metadata"
Finding out why only the distribution build had no products
Navigating the resubmission process

Recording three distinct kinds of "no products" is what let me look at the log once and conclude "it's none of the three, it isn't running at all". Collapsed into a single error, I'd have taken a much longer route.

The nastiest part, though, was an early return I wrote myself. It was meant as a kindness, not crashing when the key is missing, and what it actually built was a state that leaves no trace anywhere. Honestly, crashing would have told me sooner. That same code path now writes the missing key into the diagnostic log.

Next up: adding billing on Android. The code barely changed, and the configuration still gave me trouble.

New territory is hard work. Good luck out there, fellow Shipaton entrants.