iOS paywall: 7 beginner mistakes that kill your sales

Why your iOS paywall isn't selling

Your app is on the App Store, installs are coming in, and yet almost nobody subscribes. Most of the time, the problem isn't your idea or your code. It's your iOS paywall, the screen that presents the paid offer and asks the user to commit. A paywall shown at the wrong moment, with no free trial, no restore button or without the disclosures Apple requires won't sell, or gets rejected in review.

Here are the 7 mistakes I see most often on a first app, and how to fix each one. No magic formula: concrete, verifiable settings you can apply before your next submission to Apple.

I publish my own subscription iOS apps: Solys, an alarm clock with mini-games, and TradaZen, a trading simulator, both wired to RevenueCat. On both, I went through the same thing: lots of installs, very few free trials started. The product wasn't the issue. The paywall and the onboarding didn't lead clearly enough to the trial. That's one of the reasons I reworked them in depth, and it's where this list comes from.

Mistake #1: showing the paywall too early, or too late

This is the most expensive mistake, and it goes both ways.

Too early means the paywall shows up before the user has understood what the app does. They open the app, see a price, close it. They have no reason to pay since they haven't seen anything yet.

Too late means the paywall is hidden behind a "Premium" button in the settings, or only appears after several days of use. Most users will never see it. And a user who doesn't see your offer can't subscribe.

The right moment sits in between: at the end of the onboarding, right after the user has felt the app's value. They've answered a few questions, they've seen what the app will do for them, maybe they've tried the main feature. That's when the offer makes sense.

In practice:

• the onboarding asks useful questions and shows a preview of the result;
• the paywall comes at the end of that flow, not in the middle;
• you can show it again later, when the user hits a limit of the free version. If you're putting a previously free feature behind the paywall, read the guideline 3.2.2 guide first.

Mistake #2: not offering a free trial

For an app nobody knows yet, asking people to pay right away is a big leap. A free trial shrinks that leap: the user tries it risk-free, and payment only starts at the end of the trial period if they don't cancel.

Apple provides this mechanism under the name introductory offer for auto-renewable subscriptions. Two rules to remember, from Apple's subscriptions page:

• a customer can only get one introductory offer per subscription group;
• in the purchase flow, you must clearly state the trial length and the price charged once the trial ends.

The common mistake is offering a trial without saying so. If your button just says "Subscribe," the user doesn't know they can try it for free. Spell it out on the button or right above it: trial length, then price. That's exactly the kind of detail that makes the difference between installs that sit idle and trials that start.

Mistake #3: not highlighting the annual plan properly

Lots of first apps offer a monthly and an annual plan, but present them as two identical options, side by side, with no hierarchy. Result: the user hesitates, and a user who hesitates often closes the screen.

Yet the annual plan has advantages for you and for the user: a lower equivalent monthly price for them, a longer commitment for you. To highlight it honestly:

• preselect it and give it a distinct visual treatment;
• show the monthly equivalent next to the annual price, so the comparison is instant;
• state the real savings compared to monthly, calculated on your actual prices, never on a made-up reference price.

Be careful not to overdo it the other way: the price actually charged must stay the most visible. Apple requires the full renewal price to be displayed clearly and visibly. A big monthly equivalent and the real annual price in tiny print is a misleading paywall, and it's grounds for rejection under guideline 3.1.2.

Mistake #4: forgetting the restore purchases button

This is the dumbest oversight and one of the most common. A subscriber switches iPhones, reinstalls the app, and lands on the paywall even though they're already paying. Without a "Restore Purchases" button, they have no way to get their access back.

This isn't optional. The App Store Review Guidelines (guideline 3.1.1) require a restore mechanism for any restorable in-app purchase, and Apple's subscriptions page lists among the elements of the sign-up screen "a way for existing subscribers to sign in or restore purchases."

With RevenueCat, restoring is a single call. The real work is checking what happens next:

• the subscriber actually gets their access back, without having to relaunch the app;
• a user with no purchase gets a clear message, not a technical error;
• the button is visible on the paywall itself, not just in the settings.

Mistake #5: forgetting the disclosures Apple requires

A paywall that doesn't clearly say what the user will pay can be rejected. On its subscriptions page, Apple details what must appear on the sign-up screen:

• the name and duration of the subscription, and what it provides during that period;
• the full renewal price, displayed clearly and localized in the available currencies;
• a way to restore purchases (see the previous mistake).

Add an explicit sentence about auto-renewal: the subscription renews until the user cancels it, and they can cancel it in their Apple account settings.

The same page also states that the app and its App Store metadata must include links to the terms of use and the privacy policy. Many people discover this when they get rejected: putting these links in the app isn't enough, you also need a summary of the subscription terms and both links in your App Store listing description. Without them, it's a rejection under guideline 3.1.2. On my subscription apps, I end the description with a short block: subscription terms, then a link to the terms of use and a link to the privacy policy. And if your listing is translated, that block has to exist in every language.

Before pasting your links, open them in a browser. A link to a page that doesn't exist is as good as no link.

I covered the other common rejection reasons in this article on Apple rejections, and the App Store listing itself has its own page: optimizing your App Store listing.

Mistake #6: not testing the paywall in the sandbox

A paywall that looks fine in the simulator isn't a paywall that works. Between the product setup in App Store Connect, the offerings in RevenueCat and the app's code, there are plenty of places where a detail can break: a product not attached correctly, a price that doesn't load, a trial that doesn't show up.

For this, Apple provides a test environment, the sandbox, with test Apple accounts you create in App Store Connect, under Users and Access, Sandbox tab. These accounts let you test purchases without being charged, including renewals, payment failures and refunds, as explained in the App Store Connect documentation.

Before every submission, run at least this flow on a real iPhone:

1. first launch, full onboarding, landing on the paywall;
2. starting the trial with a test account;
3. checking that premium access actually unlocks;
4. deleting the app, reinstalling, restoring the purchase;
5. correct paywall display on the smallest and largest iPhone you support.

Apple's reviewer will test the purchase too. If it gets stuck, that's a rejection.

Mistake #7: measuring nothing

This is the mistake that keeps you from fixing all the others. Without measurement, you don't know where users drop off. You only see the end result: few subscribers. You don't know if the problem is the onboarding, the paywall, the price or the trial.

That's exactly what let me spot the problem on my own apps: the installs were there, the started trials weren't. Without those two numbers side by side, I could have spent weeks reworking something else.

Set up analytics events at each key step, for example with PostHog:

• onboarding started;
• onboarding completed;
• paywall shown;
• trial started;
• purchase or subscription confirmed;
• restore succeeded.

With these events, you get a funnel. You see the step where users leave, and you know what to rework first. RevenueCat completes the picture on the revenue side: trials, conversions, renewals, cancellations.

One last tip: don't change everything at once. If you change the price, the trial and the paywall design on the same day, you'll never know what moved the numbers.

The paywall checklist before your next submission

• The paywall comes at the end of the onboarding, after a proof of value.
• The free trial is shown clearly: length, then price after the trial.
• The annual plan is highlighted honestly, and the price actually charged stays readable.
• The "Restore Purchases" button is on the paywall and works.
• Name, duration, renewal price and auto-renewal are stated.
• Links to the terms of use and the privacy policy are in the app and in the App Store description, in every language.
• The full purchase flow has been tested in the sandbox on a real iPhone.
• Analytics events cover every step, from onboarding to purchase.

If you're still unsure about the model itself, subscription or one-time purchase, I wrote a dedicated guide: subscription or one-time purchase for your first iOS app. And for the full technical side, products, RevenueCat and review, everything is on the iOS in-app subscriptions page.

Building your paywall with the iOS Kit

The paywall is just one piece. It depends on the onboarding before it, the price you set, the App Store listing that brings users in, and the app's main feature, the one you should keep simple in a well-scoped first version.

If you want to start from a ready-made base, the onboarding, paywall and subscriptions are already in the Starter Code of the iOS Kit, and the third step of its path is about wiring them into your own app. Nobody can guarantee you any revenue.

Before submitting, the Claude Code skills in the Apple Review Kit review your paywall and the disclosures Apple requires. And the home page shows how to launch your mobile app with this paywall already wired in.

Frequently asked questions

Which iOS paywall mistakes kill a first app's sales?

Seven mistakes keep coming up on a first app: a paywall shown too early or too late, no free trial, an annual plan that isn't highlighted properly. Then come a forgotten restore button, missing disclosures that Apple requires, a paywall never tested in the sandbox, and no measurement at all. Each one is fixed with a concrete setting, to check before your next submission to Apple.

When should you show the paywall in an iOS app?

At the end of the onboarding, right after the user has felt the app's value. Too early, they see a price without understanding what the app does. Too late, for example behind a "Premium" button in the settings, most users will never see it. You can show it again later, when the user hits a limit of the free version.

What must an iOS paywall show to follow Apple's rules?

On the sign-up screen, Apple requires the subscription's name and duration, what it provides, the full renewal price displayed clearly, and a way to restore purchases. You also need links to the terms of use and the privacy policy, in the app and in your App Store listing description. Without them in the description, it's a rejection. Add an explicit sentence about auto-renewal.

Should you offer a free trial in an iOS app?

Yes, especially for an app nobody knows yet: asking people to pay right away is a big leap, and the trial lets them try it risk-free. Apple calls this an introductory offer, limited to one per subscription group for the same customer. Write the trial length, then the price charged afterward, on the button or right above it.

How do you highlight the annual plan without misleading users?

Preselect the annual plan, give it a distinct visual treatment and show its monthly equivalent next to the annual price. State the real savings compared to monthly, calculated on your actual prices, never on a made-up reference price. Don't hide the real price: a big monthly equivalent and the annual price in tiny print is a misleading paywall and grounds for rejection.

How do you test an iOS paywall before submitting to Apple?

With Apple's sandbox: test accounts, created in App Store Connect, that let you buy without being charged. On a real iPhone, run the full flow: onboarding, starting the trial, premium access, then deleting the app, reinstalling and restoring the purchase. Also check the display on the smallest and largest iPhone you support.