App Store Compliance Best Practices

Getting through App Review today doesn't mean Apple will accept the same flow six months from now. Apple enforces the spirit of its guidelines, decides what that spirit is, and can act on things it has approved many times before.

So the safest approach is to build as if every screen will be reviewed again. The tips below come from Apple's published App Store Review Guidelines and from what developers report hearing from Apple's review and developer relations teams. When those reports are stricter than the written rules, we say so and recommend following the stricter version.

The Short Answer: If Apple Hasn't Seen It, Assume It Isn't Approved

Put every paywall version in the build Apple reviews. Make the price the most prominent number on the screen. Take pressure tactics out of onboarding. Show each discount once per user. Keep your own notes on every conversation with Apple. And keep enough cash to get by if your Apple payouts stop.

1. Don't Count on Past Approvals

An approved build means one reviewer, on one day, didn't flag it. That's all. Developers report that once Apple starts enforcing, it can point to flows it previously approved as proof of a pattern.

Apple's focus can also shift without warning. In mid-January 2026, Apple started rejecting large numbers of toggle paywalls under Guideline 3.1.2, with no update to its documentation and no grace period, according to reporting from Adapty.

Best practices:

Review your live onboarding and paywall flows every time Apple updates its guidelines, and at least once a quarter.
Check each flow against what the guideline says. How many times it has passed doesn't matter.
Make one person on your team responsible for a compliance check before any build that touches pricing or onboarding.

2. Get Answers From Apple

Apple sees itself as the only one who can interpret its guidelines. One developer reported being told exactly that: no one should interpret the guidelines for Apple.

Paywall templates and advice from other founders are good for learning what converts. They can't tell you what Apple will accept in your app.

Best practices:

If a flow feels like a gray area, ask App Review through App Store Connect before you roll it out widely.
If you're rejected and disagree, appeal to the App Review Board.
Use templates and playbooks as a starting point, then check them against the guidelines yourself. Apple holds you responsible for everything in your app, no matter who designed it.

3. Keep Every Paywall Version in the Reviewed Build

The written rule is looser than how developers say it's enforced. Guideline 2.5.2 bans downloading code that changes what your app does. Many developers read that as permission to change paywall copy and layout remotely, since they're only changing settings.

Developers who have talked to Apple describe a much tighter line. Only use paywalls Apple has already seen. Even small remote copy changes count. Changing prices remotely is worse, especially if Apple never saw that price in review. Apple can rely on Guideline 2.3.1, which says your app's features must be clear to users and App Review. A paywall Apple never saw can be treated as a hidden feature.

Best practices:

Put every paywall version in the build you submit, and describe each one in your App Review notes.
Give the reviewer a way to see each version, like a test account or a debug setting explained in your notes.
Never launch a price, trial length, or offer that wasn't visible in a reviewed build.
If you're making a big paywall change, submit a new build. A short review wait costs much less than losing your account.

4. Make the Price the Biggest Number on the Paywall

Apple's subscription guidance is clear. The amount the user will be charged has to be the most prominent price on the screen. For free trials, you need to show how long the trial lasts, what it costs after the trial ends, and how renewal works. Developers often report rejections under Guideline 3.1.2(c) when the free trial stands out more than the price.

Developers also report being told that buttons saying "Try for FREE" or "Try for $0.00" are not allowed.

Patterns to avoid:

A big trial button with the real price in small gray text below it.
Annual plans shown only as a monthly price, so someone expecting $1.67 a month gets charged $19.99 up front.
A "50% off" badge without the actual price next to it.
A close button that's hidden, delayed, or hard to see.

Best practices:

Make the price and billing period the largest pricing text on the screen.
Put the trial length and the after-trial price right next to the purchase button, in similar size.
Keep "free" and "$0.00" off the button.
For annual plans, show the full yearly amount first. A monthly breakdown can appear in smaller text.

5. Take the Pressure Out of Onboarding

Apple looks at onboarding as closely as it looks at paywalls. Developers report that Apple goes after anything built to create urgency, including promises of results in a set number of days. Lots of apps do this, and that won't protect yours.

The rule behind this is Guideline 5.6, Apple's Developer Code of Conduct. It says apps should never prey on users, trick them into purchases, raise prices in a tricky way, or use any other manipulative practices. Since 2021, it has also said that repeated manipulative or misleading behavior will get you removed from the Apple Developer Program. In plain terms, that means losing your account.

Best practices:

Drop promises tied to a deadline, like "lose 10 pounds in 30 days."
Remove countdown timers unless there's a real deadline.
Explain what your app does and let people decide.
If your conversion rate depends on pressure, rebuild the flow before Apple makes you.

6. Show Each Discount Once

A discount is fine when it really is a one-time offer. Developers report being told that a discount users can trigger every time they open the app is not allowed. If the discount is always available, the "full" price is fake, which runs into the "raise prices in a tricky way" language in Guideline 5.6. Exit offers that pop up when someone closes the paywall, and showing paywalls back to back, are also common triggers for 5.6 rejections.

Best practices:

Show each discount once per user, and track it on your server so reinstalling the app doesn't reset it.
Only call an offer "limited time" if it actually ends.
Make sure the price you're discounting from is a price real users actually pay.

7. Keep Your Own Records

Apple rarely explains enforcement decisions in writing. Developers report that most guidance comes over the phone, which leaves you with nothing to point back to later.

Best practices:

Write down your questions before every call with Apple.
Note the date and the names of everyone on the call.
After the call, reply in App Store Connect with a short summary of what you understood, and ask Apple to correct anything you got wrong. That puts the record in Apple's own system.

8. Plan for the Worst Case

Losing your developer account is the most damaging thing that can happen to an app business, and there's little certainty about when you'd get paid. Developers report being told by Apple that remaining earnings are paid out after termination, but with no timeline. On Apple's developer forums, some say they were paid three to six months later. Others say they waited a year or more, or were never paid, especially when the termination cited fraud under Section 3.2(f) of the Developer Program License Agreement.

If you rely on Apple payouts to cover ad spend and payroll, a termination cuts off that cash while your bills keep coming. It also affects your financing. Anyone advancing money against your App Store earnings is counting on your good standing with Apple, so a compliance problem quickly becomes a cash problem.

Best practices:

Keep enough cash to cover a few months of fixed costs without an Apple payout.
Build revenue outside the App Store where you can, like web sales or Google Play, so one platform isn't your only income.
Treat compliance as a finance issue as much as a product issue.

A Pre-Submission Checklist

Run through this before any build that touches pricing or onboarding:

Every paywall version is in the build and listed in your App Review notes.
No price, trial, or offer will go live that the reviewer couldn't see.
The price is the largest pricing text on every paywall.
Trial length, after-trial price, and renewal terms are next to the purchase button.
The purchase button doesn't say "free" or "$0.00."
Onboarding has no deadline-based promises and no fake countdowns.
Each discount shows once per user, tracked on your server.
Anything Apple told you on a call has been summarized back to them in App Store Connect.

Frequently Asked Questions

Can I still A/B test paywalls on iOS?

Yes, carefully. Put every version in the reviewed build, mention the test in your App Review notes, and give the reviewer access to each version. Remote changes Apple never saw are the riskiest part, even if the written guidelines seem to allow them.

Is "Start free trial" banned?

The written guidelines focus on how prominent the price is and don't ban specific words. In practice, apps get rejected when the trial stands out more than the price, and developers report buttons saying "free" or "$0.00" getting flagged. Put the price on the button or right next to it, in similar size.

If Apple approved my flow before, can it still penalize it?

Yes. A past approval doesn't lock anything in, and Apple can look at your past submissions as a pattern when deciding whether something was manipulative.

Does Apple pay out my earnings if it terminates my account?

Developers report being told yes, but with no timeline. Forum reports range from a few months to much longer, and fraud-related terminations seem to be the slowest and least certain.

The Bottom Line

Apple's guidelines are broad, its enforcement changes without notice, and its explanations usually come over the phone. Focus on what you control. Keep every version of your flow in front of Apple, show your price honestly, and hold enough cash to handle a pause in payouts.

AppCap is not an arbiter of Apple's policies and does not interpret the App Store Review Guidelines on Apple's behalf. This post shares observations based on Apple's published guidelines and on developers' reported conversations with Apple, as of November 2026. Apple's enforcement can change at any time, and only Apple can decide whether a specific app complies. This post is not legal advice and is not endorsed by or affiliated with Apple. AppCap is a business unit of Emigrant Bank, Member FDIC. AppCap is not a separately insured entity; deposit and banking services are provided by Emigrant Bank, Member FDIC.