Add a paywall to an app and the rule that gets it rejected is what the screen does not say, not how it looks.
Here is the answer first. Both stores reject paywalls over disclosure, so before the purchase button the screen has to show the full amount that will be charged, how long the term runs, the fact that it renews until cancelled, and what the money buys during each period. Apple also wants links to your terms of use and privacy policy, and a way for an existing subscriber to sign in or restore. Google also wants a clearly visible way to dismiss the screen and an in-app route to cancel. The rest is taste. This page gives the rules for subscriptions and for one-time unlocks, read from Apple's and Google's own documentation on 3 October 2026.
Most app paywall design writing is about conversion, which is a different subject and has no single right answer. The paywall best practices app reviewers actually enforce are written down, numbered and short. Below: what each store requires on the screen, which guideline a rejection cites, where the two platforms disagree, and which parts you cannot test without real hardware.
Check your screen against both storesThe short version
A paywall is a disclosure document that happens to have a button.
Two different things live on that screen. One is the pitch, which is yours to design, test and argue about. The other is a short set of facts a store requires you to state before money moves. The pitch has no wrong answer. The facts do, and that half is what review looks at.
So build it in that order. Put the required elements down first, as real text in a layout that cannot hide them, then arrange the pitch around them. Teams who work the other way round end up cutting a feature out of a finished design to make room for a price.
What the subscription paywall screen must say before it takes money
Apple publishes the list. On its auto-renewable subscriptions page, read on 3 October 2026, Apple states that the following details must be included in your subscription's sign-up screen: the subscription name and duration, and the content or services provided during the subscription period; the full renewal price, shown clearly and prominently and localised in available currencies; and a way for current subscribers to sign in or restore purchases. The same page adds that your app and your App Store metadata must include links to your terms of use and privacy policy.
Two more rules on that page are the ones real screens fail. On billing amount: in the purchase flow, the amount that will be billed must be the most prominent pricing element in the layout. You may still show that an annual plan works out to a smaller weekly figure, but the breakdown has to sit in a subordinate position and size to the annual price. On free trials: in the purchase flow you must clearly indicate how long the trial lasts and the price billed once it is over.
Notice what is not on Apple's list. No required close button. No comparison table. No minimum font size, and no limit on how many screens the flow may take. Apple's own paywall view, SubscriptionStoreView in StoreKit, loads the localised names, descriptions and prices for a subscription group and automatically displays buttons for the terms of service and privacy policy you submitted in App Store Connect. Build the screen by hand instead and those two links are yours to remember.
Apple, Auto-renewable Subscriptions: clearly describing subscriptions
Google writes the dismiss button into policy and Apple does not
Google Play's Subscriptions policy, under Monetization and Ads and read on 3 October 2026, requires you to clearly and explicitly disclose your offer terms, the cost of the subscription, the frequency of the billing cycle, the automatic renewal terms, whether a subscription is required to use the app, and any other material information about it. Then comes the sentence that settles most internal arguments: users should not have to perform any additional action to review the information. A price that needs a tap to appear is not disclosed.
The policy also lists its own violations, with annotated screenshots. A dismiss button that is missing or not clearly visible is one of them, because users may not understand that they can use the app without accepting the offer. An annual plan whose pricing is shown most prominently as a monthly figure is another. So is pricing and terms that are only partly localised, and a purchase flow where repeated taps in the same spot land the user on the subscribe button. On free trials it wants the duration, the fact that it converts automatically, the price it converts to, and how to cancel before it does.
Then cancellation, which has no Apple equivalent as a requirement. If you sell subscriptions, your app must clearly disclose how a user can manage or cancel, and it must contain access to an easy-to-use online method to cancel: a link to Google Play's Subscription Center, direct access to your own cancellation process, or both, in your account settings or an equivalent page. Apple's guidance recommends making the system management screen easy to reach, through showManageSubscriptions(in:), but the guidelines do not require a link. A one-time unlock has no renewal to disclose and nothing to cancel, which is why the screen you need to add in app purchases runs to a shorter list than this one.
Which guideline a rejection actually cites
Rejections arrive with a number. For subscriptions it is usually 3.1.2 of the App Store Review Guidelines, read on 3 October 2026, and specifically 3.1.2(c) Subscription Information: before asking a customer to subscribe, you should clearly describe what the user will get for the price, and you must clearly communicate the requirements described in Schedule 2 of the Apple Developer Program License Agreement. 3.1.2(a) adds two hard limits that are easy to trip over by accident. The subscription period must last at least seven days, and the subscription must be available across all of the user's devices.
Two neighbouring guidelines matter as much. 2.3.2 requires that your app description, screenshots and previews clearly indicate whether featured items, levels or subscriptions require additional purchases, so a screenshot of a premium screen with no note is a metadata rejection rather than a paywall one. 2.3.1 bans hidden, dormant or undocumented features and requires new features to be described with specificity in the Notes for Review field, which is where a paywall sitting behind a server flag goes wrong. And 3.1.2(a) says apps that try to trick users into purchasing a subscription under false pretences will be removed from the App Store.
One more, because it gets cited wrongly. Guideline 4.9 does contain a clean four-item disclosure list: the length of the renewal term and the fact that it will continue until cancelled, what will be provided during each period, the actual charges that will be billed to the customer, and how to cancel. That list governs Apple Pay recurring payments, which is what you use for goods and services consumed outside the app. It is a good checklist and it is the wrong citation for an auto-renewable subscription.
Non-subscription apps get their own rule, in 3.1.1. A free time-based trial ahead of a full unlock is set up as a non-consumable item at price tier 0, named in the XX-day Trial form, and before the trial starts the app must clearly identify its duration, the content or services that stop working when it ends, and any downstream charges for full functionality. 3.1.1 also says you should have a restore mechanism for any restorable purchase. If you are weighing a hosted tool to render all of this, revenuecat vs superwall is the comparison to read, with one caveat: an SDK renders the screen, and the reviewer still judges the screen.
Check it
What your paywall is still missing
Tick only what a reviewer can see on the screen itself, without tapping anything.
6 Apple gaps, 6 Google Play gaps
Still missing: The full amount that will be charged, as the biggest price on the screen; How long the term runs, and that it renews until cancelled; What the money buys during each period; Price and terms localised to the same country as each other; Links to your terms of use and privacy policy; A way for an existing subscriber to sign in or restore; A dismiss control a reviewer can see at a glance; An in-app route to cancel or manage the subscription. Each one is named in the policy text of the store beside it.
No permission, one API each, and what a simulator will not tell you
A paywall asks for no operating system permission on either platform. Apple's StoreKit documentation describes no permission prompt and no Info.plist key for in-app purchase, and the current Google Play Billing Library integration guide asks you to declare no manifest permission. The system puts up the payment sheet and the customer authorises it with their own store account. What they can refuse is the purchase, not an access request, and both platforms hand you that refusal explicitly: StoreKit's Product.PurchaseResult returns userCancelled, and Google Play Billing returns BillingResponseCode.USER_CANCELED, documented as response code 1, a transaction cancelled by the user. Treat both as a normal outcome and leave the app usable afterwards.
Use the current API names, because the pages you arrived from probably do not. On iOS the current framework is StoreKit 2: you load a Product, call purchase on it, and read entitlements from Transaction. The older payment queue API, SKPaymentQueue, now carries the note No longer supported in Apple's documentation, although guideline 2.3.2 still refers to its SKPaymentTransactionObserver method. On Android the library is the Google Play Billing Library, at version 9.1.0 as of its release note dated 18 June 2026. Product details are fetched with queryProductDetailsAsync and ProductDetails; the older querySkuDetailsAsync and SkuDetails were deprecated and then removed in version 8.0.0, which is why tutorials built on SKUs no longer compile.
Testing is where the two platforms diverge most, and it is the part that costs people an afternoon. Apple's StoreKit Testing in Xcode uses a local configuration file, needs no App Store Connect setup and no network connection, and Apple's own documentation says you can test your app in Simulator or on real devices. Sandbox is the next stage and is described as testing on devices, with real product information from App Store Connect, and it will not produce a purchase at all until your membership Account Holder has signed the Paid Applications Agreement. On the Android side, the Play Billing testing documentation says you can test your integration on any Android-powered hardware device with the most current version of the Google Play application installed, and that the billing library is ordinarily blocked for apps that are not signed and uploaded to Google Play unless the account is a license tester. It describes hardware. Budget for a real Android phone.
What none of that tests is whether a human reviewer finds your price legible, and that judgement is the one you cannot automate. This page gives no console menu paths on purpose: both consoles are renamed often enough that a path printed today is wrong within a quarter, while the policy text stays put. What to charge, and which plan shape to put on the screen in the first place, sits outside the rules and inside monetisation strategies.
What each store requires on the screen
| What the paywall must show | Apple | Google Play | Where the rule is written |
|---|---|---|---|
| The full amount that will be charged | Required, and it must be the most prominent pricing element in the layout | Required; an annual plan shown mainly as a monthly figure is a listed violation | Apple auto-renewable subscriptions page; Play Subscriptions policy |
| Term length, and that it renews until cancelled | Required, as subscription name plus duration | Required, including the automatic renewal terms | Apple auto-renewable subscriptions page; Play Subscriptions policy |
| Trial length and the price it converts to | Required in the purchase flow | Required, plus how to cancel before it converts | Apple auto-renewable subscriptions page; Play Free Trials section |
| Terms of use and privacy policy links | Required in the app and in App Store metadata | Not named in the Subscriptions policy | Apple auto-renewable subscriptions page |
| A dismiss control and an in-app cancel route | Neither is stated in the App Store Review Guidelines | Both required; a missing or unclear dismiss button is a listed violation | Play Subscriptions policy, violation examples and cancellation section |
Wiring the disclosure into a paywall you ship
The build order that survives review is boring. Write the required strings as real localised text in the layout, not inside an image and not inside a web view, because a reviewer reading a screenshot has to be able to see them. Load the price from the store rather than hardcoding it, so the number on your screen always matches the number in the payment sheet. Google's Payments policy states that in-app pricing must match the pricing displayed in the user-facing Play billing interface, and a hardcoded price breaks that the first time you change a tier or add a currency.
Newly is an AI app builder: you describe an app in plain English and it writes a React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, and ships to TestFlight and to Google Play internal testing. It is $25 a month and there is no free plan. Ask the agent for a paywall and it shows a Connect RevenueCat card, then sets up the subscription products and adds the paywall screen, which is an owner or admin action. It uploads the build and you press submit yourself, because Apple's guideline 4.2.6 puts that on the person whose app it is, and your Account Holder still has to have signed the Paid Applications Agreement before a single test purchase works.
Whatever builds the screen, do one pass before you submit anything. Read your own paywall as someone who has never seen the product: can you find the amount you will be charged, when you will be charged it, how long it lasts, how to get out, and how to leave the screen without paying? If any of those takes more than a glance, fix that before you touch the headline.
Questions people ask about app paywalls
Merge both stores' lists and you get five things: the full amount that will be charged, how long the term runs and that it renews until cancelled, what the money buys during each period, the trial duration and the price it converts to if there is a trial, and a route to cancel. Apple adds links to your terms of use and privacy policy plus a way to sign in or restore. Google adds a clearly visible dismiss control. Everything beyond that is design.
Write the required lines before you design the screen
List the facts your paywall has to state, write them as real text in the layout, load the price from the store, and add the dismiss and cancel routes. Then build the pitch around them.
Start building