Guideline 5.6: the paywall that gets your app rejected

Guideline 5.6 is the developer code of conduct. When it's about a paywall, Apple cites it with a stock sentence: the app "attempts to manipulate customers into making unwanted In-App Purchases." In plain terms, a button in your purchase flow doesn't do what it says, or an offer comes back without the user asking for it. The fix comes down to one rule: every button does what it says, and the user alone decides when they see an offer again.

I got this rejection on TradaZen, my trading practice app. I tell the story of its launch in this case study. Here's the rule, what I found in my paywall, the patterns to avoid and my reply to Apple. For the related rule on rating prompts, read the guideline 5.6.3 guide instead.

What does guideline 5.6 say?

5.6, "Developer Code of Conduct," sits in section 5 "Legal" of the App Review Guidelines. Its first paragraph is about respect: toward customers, in replies to reviews and in your dealings with Apple. The second one targets purchases directly.

The current text sets out the principle: "Customer trust is a cornerstone of the App ecosystem." It then lists what an app must never do: take advantage of users, scam them, "trick them into making unwanted purchases," force them to share unnecessary data, "raise prices in a tricky manner," charge for things that aren't delivered, or any other manipulative practice, inside or outside the app.

In plain English: you must not get a purchase through trickery. The text doesn't give a list of banned buttons. It judges the effect: did the user pay because they wanted to, or because the screen trapped them?

5.6 also groups four sub-rules:

Sub-rule	What it covers
5.6.1 App Store Reviews	Reviews and rating prompts
5.6.2 Developer Identity	Accurate info about you
5.6.3 Discovery Fraud	Visibility fraud
5.6.4 App Quality	Complaints, refunds

The penalty is written into the rule: "Repeated manipulative or misleading behavior or other fraudulent conduct will lead to your removal from the Apple Developer Program." So repeated manipulative behavior gets you kicked out of the developer program. It's a general rule, and a good reason to fix your whole purchase flow after the first rejection.

The 5.6 rejection message for a paywall

The message often repeats the same sentence: "The app attempts to manipulate customers into making unwanted In-App Purchases." Apple doesn't always say which element it's targeting. On my rejection, there was nothing more.

Other developers describe the screen in question. In an Apple forum thread from November 2024, a developer links their 5.6 rejection to a one-time offer shown when the user closed the first subscription screen.

5.6 isn't only about paywalls. One developer was also rejected for features that seemed hidden during review. If your 5.6 rejection doesn't mention purchases, first look for what the reviewer couldn't see.

My 5.6 rejection on TradaZen

On October 12, 2026, Apple rejected TradaZen version 1.5.1, tested on iPad Air. Reason: guideline 5.6, with the stock sentence about unwanted purchases. No screen was named.

So I went through my whole purchase flow as someone who just wants to say no. The paywall at the end of onboarding has no close option: the app asks for the trial or the subscription to continue. Three mechanisms around it could pass for manipulation:

• A fake close button. At the top of the screen, an X-shaped button, announced as "Close" to VoiceOver, opened a discounted offer instead of closing.
• An offer that came back on its own. As long as the offer was running, it reopened whenever the user came back to the app.
• A promotional nudge. Leaving the app from the paywall scheduled a notification announcing an exclusive discount.

One detail matters: these mechanisms were already in the previous version, approved three days earlier. An approval doesn't validate your paywall forever: another reviewer can read the same screen differently.

What I changed

• The X is gone from that screen. In its place, a gift icon, announced as "Exclusive discount" to VoiceOver, opens the offer when tapped. Nothing pretends to close anymore.
• The offer never opens on its own when the user returns to the app.
• The discount notification is removed. What's left is a soft reminder, sent only once per install and only if notifications are allowed. It mentions no price, no discount and no deadline.
• That reminder is described in the message to App Review, with its text and when it's sent.

What I kept

I also reviewed what remained, asking whether each element really left the user a choice.

• An offer after a canceled purchase. If the user cancels Apple's payment sheet for the annual subscription, a welcome offer opens. It has a single 5-minute window that doesn't restart: if the user cancels again during that time, it reopens. It closes in one tap with the X or "No thanks," and shows the product's real price.
• A real 5-minute timer. Its deadline is saved on the device the first time it's shown. It keeps running when the app is closed and doesn't reset on relaunch. Once it runs out, the offer disappears for that install of the app. If you close it before then, a small badge shows the time left and only reopens the offer if you tap it.
• A locked chest. It shows the items earned during onboarding, and only those, locked until the app is unlocked. Nothing says they'll be lost.

These elements are listed in the review notes. The rejection didn't name any screen, so I'm not presenting them as approved by Apple. In my view, they're the transparent versions of these mechanics, and I disclosed them.

The fix needed a new build, since everything happened inside the app. TradaZen went back into review on October 13, 2026.

Paywall dark patterns that trigger 5.6

Apple doesn't publish a list. The same mechanic often comes in two versions: one that traps and one that leaves the choice. This table separates them, combining the text of the rules, rejections published by other developers and my own. The transparent version doesn't guarantee approval. It's the one that isn't trying to deceive. The last column shows what each row is based on.

Manipulative version	Transparent version	What backs it up
An X that opens an offer instead of closing	The X closes. A screen that can't be closed shows no X	Fixed after my TradaZen rejection
A "one-time" offer that pops up when you close the paywall	A discount behind a button that clearly says so	Rejection posted on the Apple forum
A second offer launched after a refusal, in a paywall with a misleading price	A single offer after a canceled purchase, at the real price, closable in one tap	Cal AI case; exchange reported by Superwall
A paywall or offer that reopens on its own when you return to the app	It comes back when the user hits a limit or taps a button that says so	Fixed after my TradaZen rejection
A promotional notification nobody asked for	Promotion after explicit consent, with an opt-out in the app	Rule 4.5.4
A fake timer that resets, or whose offer returns after it ends	A real deadline that keeps running with the app closed and truly ends	My reading of "trick them," rule 5.6
Made-up rewards, or rewards threatened to vanish without a purchase	The user's real gains, shown without any threat of losing them	My reading of rule 5.6
A free trial that hides the automatic charge	Trial length and the price charged afterward, next to the button	Apple's subscriptions page
A big weekly price, with the billed amount in small print	The billed amount is the most prominent price on the screen	Apple's subscriptions page
A guilt-tripping decline button	A neutral decline, like "Not now" or "No thanks"	My reading of rule 5.6

The Cal AI case was reported by TechCrunch: Apple cited 5.6 for a second subscription offer shown to people who declined the first one. The same paywall was also flagged under 3.1.2(c): the weekly price dominated the billed amount, and the trial hid the auto-renewal. The article doesn't describe the second offer in more detail.

On the other side, Superwall, a paywall tools company that sells this kind of offer, reports an informal exchange with Apple in June 2026. An offer shown after a canceled purchase is described there as allowed. Pushiness isn't: an offer that comes back every session, or a flow you can only leave by paying. Superwall notes these aren't official rules and that the reviewer keeps their own judgment. So an offer after a refusal remains a judgment call: the text doesn't ban it, published rejections exist, and how you do it matters.

The notification rule is 4.5.4: no promotion via notifications without explicit consent collected in the app, or without a way to opt out.

On pricing, Apple's subscriptions page is clear: the billed amount must be the most prominent pricing element. The reason fits in one sentence: "This ensures that people are not misled." Rule 3.1.2 adds that Apple removes apps that sell a subscription under false pretenses or through "bait-and-switch."

The test I use now: does every button do exactly what its look promises, and can the user say no in one tap without the offer coming back on its own?

The more classic paywall mistakes, the ones that cost you sales without necessarily getting you rejected, are in iOS paywall: 7 beginner mistakes.

How to fix a 5.6 rejection

1. List your entire purchase flow. Paywall, secondary offers, timers, notifications, prompts when the user returns to the app. Apple doesn't always say what it's targeting. For each element, check that it's in its transparent version: closable in one tap, real timer, accurate price, no automatic return. Fix or remove anything that looks like a trap, not just the most likely culprit.
2. Replay the reviewer's path. Delete the app, reinstall it, finish onboarding, then refuse everything: close, cancel, leave the app, come back. Note every screen that opens without you asking, and check you can close it in one tap.
3. Prepare a new build. The cause is in the app, so in the shipped code. A remote update doesn't replace a build, as I explain in the guideline 2.1 guide.
4. Don't hold anything back. Turning an offer back on remotely after approval amounts to hiding a feature from the reviewer. RevenueCat itself warns against this reflex in its article on exit offers.
5. Reply in App Store Connect, in English, by replying to the App Review message.

Here's a template taken from my reply and review notes, shortened. Replace the build number and the changes with yours, then list what remains:

Hello,

Thank you for your feedback on Guideline 5.6.

Issue: on the subscription screen, the button in the top
corner looked like a close button, but it opened a
discounted offer instead of closing the screen.

Changes in build X:
- Nothing on the subscription screen pretends to close it.
  A clearly labeled button now opens the optional offer.
- The offer never reopens by itself when the user comes
  back to the app.
- The notification announcing a discount has been removed.

Still in this build (also described in the review notes):
- [Each remaining offer: what triggers it, how often it
  appears, how the user dismisses it.]
- [Each remaining reminder: its text, when it is sent,
  and under which conditions.]

If another part of the purchase flow still looks unclear,
please tell me which screen, and I will change it.

Best regards,

What you write must match the build exactly. If you keep a reminder or an offer, even an automatically triggered one, describe it in the reply and in the review notes. If you think the reviewer got it wrong, Apple lets you appeal to the App Review Board, with one appeal per rejected submission. For a paywall, fixing seems safer to me than contesting. Other rejection reasons and how to respond are in why Apple rejects an app.

The anti-5.6 checklist before submitting

• Every X closes the screen. A screen that can't be closed shows no X.
• Every button says what it does, on screen and for VoiceOver.
• No offer hides behind a close button.
• An offer triggered by a refusal, if you keep one, fits in a single window that doesn't restart, at the real price, and closes in one tap.
• No paywall or offer reopens on its own when the user returns to the app.
• No promotional notification without explicit consent in the app.
• No fake timer: a displayed deadline is real, doesn't reset and truly ends.
• What the screen shows as earned really was earned, with no threat of losing it.
• The trial shows its length and the price charged afterward.
• The billed amount is the most prominent price on the screen.
• The review notes describe every offer and every reminder in the build.
• You replayed the flow refusing everything, on iPhone and on iPad.

Get your paywall reviewed before Apple does

The Review Kit bundles my pre-submission checklist, my fixed rejections and two Claude Code skills that review your project, your paywall and your listing. If Apple rejects you, they draft your reply. For a human eye, book an hour with me: we replay your purchase flow together, on your screen. The full process after a rejection is on the app rejected by Apple page, and the technical side of subscriptions is on iOS in-app subscriptions.

If you're preparing your first release, take the free diagnostic: it puts the steps in order and sends you my Apple anti-rejection checklist. The home page shows how to build a mobile app with a paywall designed for review from the start.

Nobody can guarantee Apple will approve your app. What I can do is help you avoid a 5.6 rejection I already paid for with a review cycle.

Frequently asked questions

What does "Guideline 5.6 - Developer Code of Conduct" mean in a rejection?

It's the title of the rule on the developer code of conduct. For an app with in-app purchases, it usually flags a purchase flow judged manipulative: a fake close button, an offer that comes back on its own, a trial or price presented misleadingly. The message doesn't always name the screen in question.

Are exit offers banned by Apple?

The text doesn't ban them outright. RevenueCat notes this too, while pointing out that developers have been rejected for it. Published rejections target an offer that pops up when the user closes the paywall, or a second offer launched after a refusal. What sets the transparent version apart: an optional offer, limited to a single window that doesn't restart, at the real price, closable in one tap, that doesn't come back on its own, with a real timer if there is one. Describe it in the review notes. Nobody can guarantee a reviewer will see it that way.

Is a paywall without a close button allowed?

The rules don't require an X, and that's the choice I made on TradaZen after this rejection. What Apple rejects is a button that looks like a close button and does something else. That said, one developer reported a 5.6 rejection for a paywall with no way out in a free-to-download app. Show the value before asking for the trial, and make it clear in your listing that the app is paid.

Do you need a new build after a 5.6 rejection?

Yes in most cases, because the cause is a screen or a behavior in the app. If the problem is outside the app, in the listing or metadata, a fix without a build may be enough. If in doubt, ask the reviewer which screen they mean.

Can a 5.6 rejection lead to your developer account being closed?

The rule provides for it in cases of repeated manipulative behavior, with removal from the developer program. It also provides that a closed account can be reinstated after a written improvement plan, approved and then verified by Apple. That's why it pays to fix the whole flow after the first rejection.

What's the difference between 5.6 and 5.6.3?

5.6 is the general code of conduct: respect, trust, no purchase obtained through trickery. 5.6.3 is one of its sub-rules, about manipulating rankings, search and reviews. Apple cited it on Solys for a rating prompt placed in onboarding.