Monetization
Subscription pricing gets discussed as if it's purely a numbers problem — what to charge — but most of the conversion difference between apps comes from the mechanics around the price: when you show the paywall, how the trial works, and whether your entitlement checks are actually trustworthy. Those are engineering and design decisions, not just pricing decisions.
Before designing screens, decide the shape: freemium with a metered limit (a certain number of uses free, then pay), a hard paywall (no meaningful use without paying), a trial-gated subscription (full access for a set period, then billing starts), or a one-time purchase with an optional subscription add-on for ongoing features. Each shape implies a different onboarding flow, so this decision has to come before UI design, not after.
The standard pattern on both platforms is a trial that requires a payment method up front and converts automatically unless cancelled — StoreKit 2 introductory offers on iOS, base plans with offers in Play Billing on Android. A no-card trial (full access with no payment method collected) is far less common because it requires you to build your own manual conversion flow rather than relying on the store's billing system, but it does remove a common point of user hesitation. Seven days is the most common trial length we see, long enough to reach a real "aha" moment in most products without giving away so much value that paying feels unnecessary.
A three-tier structure (monthly, annual, sometimes lifetime) is the most common pattern, with the annual plan visually highlighted as the default choice — it's usually both the best deal for the user and the best retention outcome for you, since annual subscribers churn far less often than monthly ones. Displaying the annual price broken down to a per-week or per-month equivalent, next to the monthly price, is standard because it reframes an annual commitment as a small recurring number instead of one large charge.
A soft paywall lets someone browse and explore before hitting a wall at the moment they try to act (save, export, unlock a feature). A hard paywall blocks the core feature immediately. Generally, showing the paywall after the user has experienced a real taste of value — not before they've seen anything — converts better than gating the entire app from launch, though there are legitimate hard-paywall products where the value is obvious enough (a utility that does one specific thing) that an immediate paywall with a trial works fine.
Checking "is this user subscribed" only on the client is not secure — a modified client can simply lie about it. Real subscription products validate purchases server-side, either through a service like RevenueCat or a custom receipt-validation pipeline, and listen for App Store Server Notifications (v2) and Google Play Real-time Developer Notifications so your backend knows immediately about renewals, cancellations, refunds, and billing issues rather than trusting a stale client-reported state.
Apple's guideline 3.1.2 requires a specific in-app consent flow before an existing subscriber can be charged a higher price — you can't simply raise the price silently for current subscribers. Both platforms support win-back and promotional offers aimed at subscribers who've cancelled or lapsed, which is often a cheaper way to recover revenue than acquiring a brand-new subscriber.
The free tier isn't just "what's left over after the paid features" — it's the mechanism that gets someone to the paywall with context. A free tier that's too generous removes any reason to upgrade; one that's too thin means most people never experience enough of the product to want to. Metered limits (a fixed number of uses, exports, or saved items) tend to communicate value more clearly than time-based trials alone, because the limit is tied to something the user actually did, not just a clock running in the background.
It's also worth deciding early who owns pricing changes once the product is live. Because Apple and Google both cache and roll out price changes on their own timelines, and because guideline 3.1.2 gates any increase for existing subscribers behind an explicit consent flow, pricing isn't something you can adjust as casually as a line in a config file — treat it as a deliberate, occasional decision with real lead time, not a lever to pull reactively.
We run this entitlement pattern — store billing plus server-side validation through RevenueCat — across our own subscription products, including SurfaceIQ and Flourish PDF, precisely because client-only checks don't hold up once an app has real usage. It's not more work worth skipping; it's the part of the paywall that actually has to be correct.
More from the journal
App Store
Apple rejects a meaningful share of first-time submissions, and it's rarely the exotic reasons founders worry about. Here's what actually trips people up, and how to submit clean.
Launch
Launch day is the easy part. The work that determines whether it goes well happens weeks earlier — here's the sequence we actually follow.
Engineering
Cross-platform frameworks have closed most of the historical gap with native — but not all of it. Here's the actual decision framework, not a philosophy war.