Does Google Play require a restore purchases button?

Not under that name, and not in policy. Google Play's Payments policy, read on 21 October 2026, does not contain the word restore anywhere. The obligation lives in the Play Billing documentation instead, in the section headed Detect and process purchases: you must call BillingClient.queryPurchasesAsync() to ensure your app processes all purchases. Google lists five situations that make it necessary, and one of them is multiple devices, where a user buys an item on one device and then expects to see it when they switch. Google's advice is to call it when your app establishes a connection to the billing library, which it recommends doing on launch or when the app comes to the foreground. That is a lifecycle call, not a button.

Then what does restore mean on Google Play?

Something else, which is the trap. On Play, restoring is what a customer does to a subscription they have cancelled but which has not expired yet. They go to the Google Play subscriptions centre and bring it back, keeping the same subscription and the same purchase token. Google's About subscriptions page, last updated 20 October 2026, carries a note that reads: supporting restore is required for all developers. The same page says the button customers see is now labelled Resubscribe, and that it was previously labelled Restore. So Play does have a mandatory restore requirement. It is simply not the one Apple is talking about.

Do I still need the button if StoreKit restores purchases on its own?

Yes, add one anyway, and this is Apple telling you so twice in different voices. The documentation for AppStore.sync() opens by saying to include some mechanism in your app, such as a Restore Purchases button. The same page then says that in regular operations there is no need to call sync(), because StoreKit keeps transaction information and subscription status up to date, and when a customer reinstalls your app or downloads it on a new device the app has all transactions available on first launch. sync() is for the rare case where a customer thinks something is missing. It shows a system prompt asking for App Store credentials, so Apple says to call it only in response to an explicit action such as a tap. It is available from iOS 15.

Do consumable purchases need a restore path?

No, and trying to build one is a misreading. Consumables do not appear in currentEntitlements at all. If you need the ones a customer has paid for but not yet been given, StoreKit's unfinished and all sequences are where those live. The balance itself is your job to hold, not the store's, and that is the other half of the sentence in 3.1.1: credits or in-game currencies bought through in-app purchase may not expire. On Google Play the mirror image applies. Consuming a one-time product is what makes it available to buy again.

How does this work in a React Native or Expo project?

The same way, because the rule is about what the app does and not what wrote it. Restore is a call to the platform's own API through a native module: AppStore.sync() and Transaction.currentEntitlements on iOS, BillingClient.queryPurchasesAsync() on Android. A generated project is a real React Native and Expo project you own, so this is a screen and a function in your code that you can read and change. The one detail that catches people is testing it, because a restore path that has never been exercised on a second device is a restore path you are guessing about.

Articles · GuidesUpdated October 2026

The restore purchases requirement is one sentence, and its verb is should.

Q: So is a restore mechanism optional?

Treat it as required, for a reason that sits in a different clause. Guideline 3.1.2(a) says an auto-renewable subscription must be available across all of the user's devices, and repeats it a few lines later: subscriptions must work on all of the user's devices where the app is available. That one is a must. If you sell a subscription, you are already obliged to make it work on a device the customer has not bought it on, and a restore path is how you do that. For a one-off unlock, Apple's own word is still should.

Q: What exactly has to be restorable?

StoreKit's currentEntitlements documentation gives the list, because it is the API that answers the question at runtime. It emits a transaction for each non-consumable in-app purchase, the latest transaction for each auto-renewable subscription whose renewal state is subscribed or in a grace period, and the latest transaction for each non-renewing subscription, including finished ones. Consumable purchases do not appear in it. Neither do products the App Store has refunded or revoked. So the restorable set is your non-consumables and your subscriptions, and nothing else.

The requirement people mean when they say restore purchases is a single sentence in App Store Review Guideline 3.1.1: any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases. Should, not must. That is the whole of it. Read on 21 October 2026, on a page Apple stamps Last Updated: October 16, 2026. The clause that genuinely obliges you is a different one, 3.1.2(a), and it is about subscriptions working on every device a customer owns. Google Play has no restore purchases rule at all, and uses the word restore for a job Apple does not use it for.

What follows is the exact wording of both Apple clauses, the precise set of purchases StoreKit treats as restorable, what Google requires instead and what it calls it, and why Apple's own API documentation says a customer almost never has to ask.

Read the sentence and the clause behind it

The short version

Build the button anyway. The reason is 3.1.2(a), not 3.1.1.

Apple asks for a restore mechanism in 3.1.1 using the word should. Four clauses later, in 3.1.2(a), it says an auto-renewable subscription must be available across all of the user's devices, then says it again: subscriptions must work on all of the user's devices where the app is available. That is the binding one. If you sell a subscription you already have to serve a customer on a phone they never bought it on, and a restore path is how an app does that.

Google's version is an engineering obligation rather than a policy line. Play's Payments policy does not mention restoring. The Play Billing documentation does, in a section called Detect and process purchases, where Google says you must call a method that returns the customer's existing purchases. It runs when your app connects, not when a customer finds a button. And Play keeps the word restore for something else entirely: a customer bringing back a subscription they cancelled.

Which guideline requires a restore mechanism, and how strongly?

Guideline 3.1.1 is titled In-App Purchase and sits under 3.1 Payments. Most of it is about having to use in-app purchase in the first place, about tips, about loot box odds and about gift cards. The restore line is one sentence in the middle of it, bolted onto a rule about expiry: any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases. Nothing in 3.1.1 says which purchases are the restorable ones. The guideline hands that question to the API.

We searched the live text rather than trusting the usual summary. On 21 October 2026 the stem restor appears four times in the whole document. Two of those are the restore and restorable in that one sentence. The other two are in the Developer Code of Conduct, where a terminated account may be restored after Apple approves a written plan. So there is exactly one mention of a restore mechanism in the App Review Guidelines, and Apple did not write must next to it. The page carries its own date stamp, Last Updated: October 16, 2026, so this is current wording and not an old cache.

The clause with teeth is 3.1.2(a), Permissible uses. It says that if you offer an auto-renewable subscription you must provide ongoing value, that the subscription period must last at least seven days, and that it must be available across all of the user's devices. A few bullets down it repeats the point on its own line: subscriptions must work on all of the user's devices where the app is available. Read the two clauses together and the practical rule is simple. A subscription has a must. A one-off unlock has a should. Build the same mechanism for both, because the code is the same code.

Apple, App Review Guidelines, 3.1.1 and 3.1.2(a), read 21 October 2026, page stamped Last Updated: October 16, 2026

What exactly has to come back?

Since the guideline says restorable without defining it, the answer comes from StoreKit. The reference page for Transaction.currentEntitlements, read on 21 October 2026, lists what that sequence emits: a transaction for each non-consumable in-app purchase, the latest transaction for each auto-renewable subscription whose renewal state is subscribed or in a grace period, and the latest transaction for each non-renewing subscription, including ones that have finished. That is the restorable set. Your non-consumables and your subscriptions.

Two kinds of purchase are named as absent, and both absences matter. Consumables do not appear in current entitlements, so coins and gems do not come back through a restore button. If you need the ones a customer has paid for and not yet received, the same documentation points you at the unfinished and all sequences instead. The balance is yours to hold on a server or on the device, which is why 3.1.1 pairs the restore sentence with a ban on those credits expiring.

The second absence is money that went back. Products the App Store has refunded or revoked drop out of current entitlements, so a restore call will not hand access back to someone who got their money back. That is the behaviour you want, and it is also the reason your own entitlement checks should read the store rather than a flag you wrote once at purchase time. If you are working out how a refund should feel inside the app, the mechanics are in refund handling ios android.

One thing has changed under your feet here. The old StoreKit 1 method, restoreCompletedTransactions, is documented as having no effect when you try to restore items that are not restorable, and it names a non-renewing subscription as an example. The newer currentEntitlements sequence includes non-renewing subscriptions. Apple's availability data for the old method stops at iOS 18, so if your paywall was written against the old API its idea of what is restorable is narrower than today's. Which products you have at all is a decision you made earlier, when you set up your app store pricing tiers.

Check yours

Which of your products has to come back

Tick what you sell. The answers come from the API each store uses to answer the question at runtime, not from a guess about review.

Nothing ticked. A free app with no in-app purchases has nothing to restore and needs no button on either store.

Does Google Play have the same requirement?

No, and the difference is not cosmetic. We read Google Play's Payments policy in Play Console Help on 21 October 2026 and searched it. The word restore does not appear in it. Neither does any instruction to give customers a way to recover past purchases. The policy is about which transactions have to go through Google Play's billing system and which must not, and it stops there. If you were looking for a Play clause to match 3.1.1, that is the page it would be on, and it is not there.

The obligation exists, in the developer documentation, with different words. In the section headed Detect and process purchases, Google writes that you must call BillingClient.queryPurchasesAsync() to ensure your app processes all purchases, and calls following that recommendation critical. It then lists the situations it covers, and multiple devices is one of them: a user may buy an item on one device and then expect to see the item when they switch devices. Google's advice is to make the call when your app successfully connects to the billing library, which it recommends doing on launch or when the app comes to the foreground. So the Android answer runs on its own, without the customer finding anything.

The same page carries a deadline that bites harder than any restore rule. You acknowledge a purchase to tell Google you have delivered it, and that must happen within three days or the purchase is automatically refunded and the entitlement revoked. Google says plainly that purchases are refunded after 3 days if your app has not processed the purchase, and warns against using that window as a way to reject a purchase you do not want. Figures read 21 October 2026 from a page Google stamps Last updated 2026-10-20.

Play does use the word restore, and it means a different thing. Google's About subscriptions page, stamped Last updated 2026-10-20, carries a note in the customer management section reading: supporting restore is required for all developers. The thing being restored there is a subscription the customer cancelled but which has not expired yet, brought back from the Google Play subscriptions centre, keeping the same subscription and the same purchase token. The same page notes the button is now labelled Resubscribe and was previously labelled Restore. So Play has a mandatory restore requirement that has nothing to do with a new device.

Google, Integrate the Google Play Billing Library into your app, read 21 October 2026, stamped Last updated 2026-10-20

Do you still need a Restore Purchases button?

Add one. Apple says so in the first line of its documentation for AppStore.sync(): include some mechanism in your app, such as a Restore Purchases button, to let users restore their in-app purchases. Then the same page tells you that in regular operations there is no need to call sync() at all, because StoreKit keeps transaction information and subscription status up to date on its own. When a customer reinstalls your app or downloads it on a new device, Apple says the app automatically has all transactions available on first launch. Both statements are on one page, read 21 October 2026, and they are not in conflict. The button is a safety valve.

That shapes how you wire it. Apple marks the sync() call as one to use only in the rare case where a customer suspects the app is not showing all of their transactions, because it shows a system prompt asking them to authenticate with their App Store credentials. The documentation is explicit that you call it only in response to an explicit user action such as a tap. It is available from iOS 15. So a paywall that calls sync() on every launch is a paywall that asks for a password on every launch, and the fix is to read current entitlements at launch and leave sync() behind the button.

There is a second reason the button earns its place, and it is about households. A subscription a customer did not buy themselves can still be theirs to use, and the path by which it arrives is not a purchase your app saw happen. The rules and limits of that are in family sharing for subscriptions. Either way, the support cost of not having the button is a person who paid you and cannot get in, and no guideline verb changes how that email reads.

Apple, App Review Guidelines, 3.1.2(a) Permissible uses, read 21 October 2026

One word, two different jobs on the two stores

The question	App Store	Google Play	Same answer on both
Where the rule is written	App Review Guideline 3.1.1, one sentence	Not in policy at all, only in the Billing Library docs	No
The verb used	should, for a restore mechanism	must, for calling queryPurchasesAsync	No
A separate hard requirement	3.1.2(a): subscriptions must work on all the user's devices	Supporting restore is required for all developers	No
What the store calls it	Restore Purchases	Resubscribe, previously Restore, for a different job	No
Needs an explicit tap	Yes, sync() shows a credentials prompt	No, it is a connection and foreground call	No
Consumables come back	No	No	Yes

Rows read on 21 October 2026 from Apple's App Review Guidelines and from Google's Play Billing integration guide, plus Google's About subscriptions page for the Resubscribe label.

Where this lands if a builder generated your app

Nothing about the restore path changes because an AI wrote the first draft of the code. It is still a call into StoreKit on iOS and into the Play Billing Library on Android, still a screen a customer can find, and still yours to test. Review sees the app, not the tooling. Guideline 4.2.6 is the reason the submission is yours too: apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content.

Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync, so a restore screen is a file you can open. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not press submit for you, because of the guideline above. It costs from $25 a month and there is no free tier.

What catches people out here is the test rather than the code. A restore path that has only ever run on the phone you built the app on tells you nothing, because that phone already holds the purchase. Buy the product with a sandbox account, delete the app, install it again, and watch whether access comes back before you touch the button. Then do the same on Android, where you are checking that your first billing connection queries purchases rather than waiting. If you are still working out the money side of all this, the cost to publish an app adds up before a single purchase arrives.

Questions people ask about the restore purchases requirement

Guideline 3.1.1, In-App Purchase. The sentence reads: any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases. Read on 21 October 2026, on a page Apple stamps Last Updated: October 16, 2026. The verb is should. A full-text search of the live guidelines finds the stem restor four times in the whole document. Two of those four are inside that one sentence, as restore and restorable. The other two are in the Developer Code of Conduct and are about getting a terminated developer account reinstated. So the restore button has exactly one mention in the App Review Guidelines, and it is not a must.

Build the paywall, then try it on a second device

Buy the thing in a sandbox account, delete the app, install it again, and see what comes back without you asking. That one test tells you more about your restore path than any amount of reading a guideline does.

Start building