Restore Purchases Button Missing: The App Store Rejection Fix

Why does a missing Restore Purchases button get rejected?

Because Apple requires it, and it is one of the most common automatic rejections for apps with purchases. Under App Store Review Guideline 3.1.1, apps that sell non-consumable products or subscriptions must give users a way to restore those purchases on a new device or after a reinstall. If your paywall has a “Subscribe” button but no “Restore Purchases” option, a reviewer will reject it, not because the app is broken, but because a required element is simply absent. It is a missing-feature rejection, and the fix is small once you know it is the cause.

The honest framing first: this is not a bug, it is an omission, and it is one AI-generated paywalls make constantly. A model will happily generate a beautiful paywall with a purchase button because that is what paywalls look like in its training data, and it leaves out Restore Purchases because that is the unglamorous required part. So the rejection is predictable: the visual paywall is there, the compliance plumbing is not. Knowing that, you can check for it before you ever submit.

What does the fix actually require?

A clearly labeled restore action that calls the restore API and handles its states. The fix is three things:

1. A visible Restore Purchases control. It does not need to dominate the paywall, but it must be present and findable, commonly on the paywall itself and in settings.
2. A call to the platform restore API. Restore is a StoreKit operation, and most apps reach it through a library like react-native-purchases (RevenueCat), which pulls over 634,304 weekly npm downloads, whose restore method re-checks the user’s purchases against their Apple ID.
3. Honest state handling. Restoring, restored, and nothing-to-restore are distinct outcomes the UI must show clearly.

That third point is where most quick fixes fall short: they add a button that calls restore but treat “nothing to restore” as a silent no-op, which confuses the user and can still read as broken to a reviewer.

How should the restore states behave?

Each outcome needs its own honest response. When the user taps Restore, the app should show a brief restoring state (a spinner, not a frozen button), then resolve into one of two clear results: if entitlements are found, unlock the content and confirm it (“Your subscription has been restored”); if none are found, say so plainly (“No purchases found to restore”) rather than failing silently or throwing a scary error. A purchase that exists must unlock; a purchase that does not exist must be explained, not hidden.

This honest-state discipline is the same one behind every well-built paywall in an AI-built iOS app: the buy path and the restore path both have to communicate their real outcome. Restore is tied to the user’s store account, so it works without a separate login, which is part of its value, a user who reinstalls gets their subscription back by tapping one button.

How do you avoid the rejection in the first place?

Treat Restore as a required part of the paywall, not an afterthought. The reason this rejection is so common is that purchase and restore get built at different times, or restore never gets built at all. The fix is to make Restore part of the paywall from the start, the same way Apple treats required elements like Sign in with Apple when you offer third-party login: a non-optional piece of compliance that ships with the feature, not after a rejection.

The screens, the paywall with its purchase and restore actions, the restoring state, the restored confirmation, the nothing-found message, come as free VP0 designs that include the restore path, so an agent wiring up RevenueCat or StoreKit builds onto a paywall that already has Restore Purchases rather than shipping the half that gets rejected. The purchase button is the obvious part; the restore button is the part that clears review.

Key takeaways: fixing a missing Restore Purchases button

• It is a required element, not a bug: Guideline 3.1.1 requires a restore mechanism for non-consumable and subscription purchases.
• AI paywalls omit it constantly: models generate the purchase button and leave out the unglamorous compliance part.
• The fix is three things: a visible Restore control, a call to the platform restore API, and honest state handling.
• Handle every outcome: restoring, restored (unlock and confirm), and nothing-to-restore (say so plainly, never a silent no-op).
• Build Restore with the paywall, not after a rejection, the same way required elements like Sign in with Apple ship with the feature.

Frequently asked questions

Why was my app rejected for a missing Restore Purchases button? Because App Store Review Guideline 3.1.1 requires apps selling non-consumable products or subscriptions to provide a way to restore those purchases, and your paywall has a purchase button but no restore option. It is a missing-required-element rejection rather than a bug, and it is especially common in AI-generated paywalls, which produce the visual purchase flow but omit the restore compliance part. Adding a clear Restore Purchases control fixes it.

How do I add a Restore Purchases button? Add a clearly labeled Restore control on the paywall and in settings, wire it to the platform restore API (a StoreKit operation, usually reached through a library like RevenueCat’s react-native-purchases), and handle the states: a restoring spinner, a restored result that unlocks content and confirms it, and a nothing-to-restore result that says so plainly. A free VP0 design that includes the restore path makes this straightforward to wire up.

What should happen when there are no purchases to restore? Show a clear message such as “No purchases found to restore” rather than failing silently or throwing an error. Treating nothing-to-restore as a silent no-op is the common shortcut that confuses users and can still read as broken to a reviewer. Each outcome, restoring, restored, and nothing found, needs its own honest response so the user always understands what happened.

Does Restore Purchases require the user to log in? No, that is part of its value. Restore is tied to the user’s store account (their Apple ID), so tapping Restore re-checks their purchases against that account without a separate app login. This is why it matters so much for users who reinstall the app or switch devices: one tap returns their subscription or non-consumable purchases without making them create or remember separate credentials.

How do I avoid this rejection in the future? Build the Restore Purchases path as part of the paywall from the start, not as an afterthought. The rejection is common precisely because purchase and restore get built separately or restore never gets built. Treating restore as a required, non-optional element that ships with the purchase feature, the same way Sign in with Apple ships when you offer third-party login, keeps the paywall compliant before you ever submit it for review.