Where should a paywall appear in an app?

At a moment of demonstrated value — after the user has done something useful — not on first launch. A paywall shown before the app has proven anything reads as a toll, not an offer.

How many pricing tiers should a paywall show?

Usually two or three. One tier gives no sense of choice; five forces a research project. Two or three lets the customer self-select without being overwhelmed.

What makes a paywall feel hostile?

Hiding the price, dark-pattern buttons, fake urgency, interrupting active work, and making the free or trial path hard to find. Honesty and good timing are what make a paywall feel fair.

Building a Paywall That Doesn't Suck

A paywall is the screen where a user decides whether you get paid. Most are bad — not because the pricing is wrong, but because the screen is designed as a wall instead of an offer. This post is about paywalls that convert because they respect the person reading them.

Timing beats everything

The single biggest paywall mistake is showing it too early. An app that opens straight onto “choose your plan,” before the user has done anything, is asking for money before it has given a reason. The user has no value to weigh against the price, so the screen reads as a toll booth.

The fix is to put the paywall at a moment of demonstrated value — right after the user has done the thing your app is good at. They exported the file, cleaned up the library, finished the recording. Now a prompt about unlocking more is an offer they can evaluate, because they just felt the product work.

For trial-based apps, the same logic spaces the messaging across the trial: quiet early, clear as the deadline nears, honest at expiry. The trial-to-paid conversion post covers that timing in depth. The principle is identical — never ask before you have shown.

Say the price

It is astonishing how many paywalls hide the number. Vague “unlock everything” buttons, prices one tap deeper, “contact us” where a figure should be. Developer-tool customers in particular read this instantly as evasive, and evasive erodes trust at the exact moment you need it.

Put the price on the screen. State what it buys. If it is a one-time purchase, say so — that is a selling point against subscriptions. If it is a subscription, show the billing period plainly. A customer who sees a clear price and decides “not now” might come back. A customer who feels the price was hidden from them will not.

Two or three tiers, not one or five

Tier count is a real design choice.

One tier gives the customer no sense of choosing — and some people want to feel they picked. It also throws away the easy upsell of a higher tier.

Five tiers turn a purchase into a research project. The customer has to build a comparison table in their head, and a confused customer does not buy.

Two or three is the sweet spot. It lets the customer self-select — “I’m a solo user,” “I’m a team” — without overwhelming them. Make the differences concrete (device count, features, support), and if you want to steer, gently mark a recommended tier. Do not make the comparison a puzzle.

Do not use dark patterns

Fake countdown timers, pre-checked add-ons, a “no thanks” link in 9pt grey, a close button that hides — these tactics can lift this week’s number. They also tell a technical audience exactly what kind of company you are, and that audience talks.

A paywall that does not suck is honest: real pricing, a real and findable free or trial path, no manufactured urgency, no tricks. You are trying to start a relationship with someone who may pay you for years. Do not open it by tricking them out of $20.

Friction is the silent killer

Even a well-timed, honest paywall fails if buying is a chore. Every extra step — leave the app, find a browser, make an account, come back, copy a key, paste it, hope — sheds customers.

The licensing layer is what removes that friction. When checkout and licensing are connected, a completed payment issues the license and the app can pick it up directly, with little or no manual key entry. The user pays and the app unlocks — close to seamless.

// After the customer completes checkout, the app resolves the new license:
await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:
    dismissPaywall()
    enablePaidFeatures()
case .invalid:
    showActivationSheet()   // fallback: manual key entry
default:
    break
}

The less the customer has to do between deciding to pay and using the paid app, the more of them complete the purchase. A good paywall is well-timed, honest, clearly priced, simply tiered, and backed by licensing that makes the unlock effortless.

If you have a paywall pattern that worked — or one that backfired — send us your feedback and we will write it up.