How to Build a Subscription App with Paywalls and Trial Flows

The subscription app economy is enormous. Apple reported over $1.1 billion in weekly App Store spending in 2028, and subscriptions account for the majority of that revenue. Yet 70% of users who start a free trial never convert to a paid subscription. That is not a marketing problem. It is an architecture and design problem.

Most teams treat the paywall as an afterthought: a static screen with a price and a "Subscribe" button. They pick a trial duration at random (usually 7 days because that is what everyone else does), wire up StoreKit or Google Play Billing, and ship it. Then they wonder why conversion sits at 2% while competitors pull 8% or higher.

The teams that win at subscription monetization treat every component of the flow as a system. The onboarding experience primes the user for the paywall. The paywall itself is a configurable, A/B testable component that evolves weekly. The trial duration is calibrated to the "aha moment" for their specific product. Grace periods keep subscribers active during temporary payment failures. And win-back flows re-engage churned users before they forget your app exists.

This guide covers how to build all of it, from SDK integration to compliance to the psychology behind trial flows that actually convert.

Before you write a single line of paywall UI, you need to decide how you will manage subscriptions on the backend. You have three real options: RevenueCat, Adapty, or building directly on top of Apple StoreKit 2 and Google Play Billing Library v7.

RevenueCat

RevenueCat is the market leader for a reason. It abstracts away the differences between iOS and Android billing into a single API. You configure your products and entitlements in the RevenueCat dashboard, and the SDK handles purchase validation, receipt verification, subscription status tracking, and webhook delivery. RevenueCat is free up to $2,500 in monthly tracked revenue (MTR), then charges 0.9% to 1.2% depending on your plan.

The biggest advantage is the server-side subscription status API. Instead of relying on on-device receipt validation (which is fragile and spoofable), RevenueCat maintains a single source of truth for every subscriber's status. Your backend can query it via REST API, and you receive webhooks for every state change: initial purchase, renewal, cancellation, billing issue, grace period entry, and refund.

Adapty

Adapty is the strongest alternative. Its core differentiator is the built-in paywall builder: you can design, deploy, and A/B test paywall screens remotely without shipping app updates. This is a massive advantage if you want to iterate on paywall design weekly. Adapty charges $0 up to $10K MTR and 0.6% above that, making it cheaper than RevenueCat at scale.

Adapty also offers a robust analytics dashboard that tracks trial-to-paid conversion, renewal rates, and revenue per user out of the box. If paywall experimentation is your top priority, Adapty deserves serious consideration.

Going Native

Building directly on StoreKit 2 (iOS) and Google Play Billing Library v7 (Android) gives you full control and zero platform fees. But you will need to build receipt validation, subscription state management, grace period handling, cross-platform status syncing, and analytics yourself. That is 4 to 8 weeks of engineering time for a senior mobile developer. For most teams, the SDK cost is a fraction of what that engineering time costs. We only recommend going native if you have a dedicated billing team or extremely unusual subscription logic.

Our recommendation: start with RevenueCat. If paywall A/B testing becomes your primary growth lever and you want a visual paywall builder, evaluate Adapty. If you are already familiar with the billing patterns from implementing subscription billing on the web, the concepts translate directly to mobile, but the platform-specific compliance requirements add real complexity.

The paywall does not exist in isolation. It is the culmination of an onboarding sequence that either builds enough perceived value to justify a purchase or falls flat. The best subscription apps follow a predictable pattern: hook, value demonstration, commitment, then paywall.

The Hook (Screens 1 to 2)

Open with the outcome, not the feature. "Track your sleep and wake up feeling rested" beats "Advanced sleep stage tracking with HRV monitoring." Use a maximum of two screens. Every additional onboarding screen before the paywall reduces conversion by 5 to 10%, so be ruthless about what you include.

Value Demonstration (Screens 3 to 4)

Let the user interact with your core feature before you ask for money. Duolingo lets you complete a lesson. Headspace lets you do a breathing exercise. Calm shows you a sleep story preview. This is not optional. Users who experience your product's value before the paywall convert at 2x to 3x the rate of users who see only static screens.

If your app requires account creation, delay it until after the value demonstration. Asking for an email before the user has experienced anything creates friction with zero upside. Use anonymous accounts (Firebase Anonymous Auth or similar) and prompt for full registration later.

The Soft Commitment (Screen 5)

Before the paywall, ask one personalization question. "What is your primary goal?" with three to four options. This does two things: it makes the experience feel tailored, and it creates a micro-commitment. Users who have invested effort (even minimal effort) are psychologically more likely to continue through the paywall. Noom, Flo, and BetterMe all use this pattern to great effect.

The Paywall (Screen 6)

Now you present pricing. The user has seen what your app does, experienced a taste of the value, and told you what they care about. The paywall should reflect their stated goal: "Start your personalized [goal] plan" is far more compelling than a generic "Unlock Premium."

Timing matters. Data from Adapty shows that apps presenting the paywall on second launch (not first) see 15 to 20% higher conversion rates. The user has already experienced enough of the app to know they want more. If your product has a strong first-session hook, showing the paywall on first launch is fine, but test both approaches.

Your paywall is not a "set it and forget it" screen. The top subscription apps test paywall variations constantly. You need to build your paywall as a configurable component that can be updated remotely.

Architecture for Remote Paywalls

The cleanest approach is to define your paywall as a data-driven component. The paywall configuration lives on your server (or in RevenueCat/Adapty), and your app renders it dynamically. A typical paywall config includes:

• Header text and subtitle: "Start your free trial" vs. "Unlock all features" vs. "Join 2M+ users"
• Plan options: Which products to show, in what order, and which one is pre-selected
• Social proof: Review count, rating, testimonial text
• Feature list: Which features to highlight and in what order
• CTA button text: "Try Free for 7 Days" vs. "Continue" vs. "Start My Plan"
• Visual layout: Single plan, two-plan comparison, or three-tier pricing grid

If you are using Adapty, the visual paywall builder handles this natively. You design variants in the dashboard and the SDK renders them. With RevenueCat, you will use their Offerings and Paywalls feature (currently in beta for remote paywall rendering) or build your own config-driven system.

What to A/B Test First

Not all paywall elements have equal impact. Based on data from hundreds of subscription apps, here is the priority order:

1. Trial duration (highest impact). Test 3-day vs. 7-day vs. 14-day trials. The difference between a 3-day and 7-day trial can swing conversion rates by 30% or more, but longer trials do not always win. More on this in the next section.

2. Price anchoring. Show the annual price alongside the monthly price with the savings percentage. "Save 60%" next to the annual option is one of the most reliable conversion lifts in subscription apps. Pre-selecting the annual plan increases annual plan adoption by 20 to 40%.

3. CTA copy. "Try Free for 7 Days" consistently outperforms "Subscribe" or "Continue." Users need to know exactly what happens when they tap the button, and the word "free" reduces friction significantly.

4. Social proof placement. Adding an App Store rating ("4.8 stars from 50K reviews") above the pricing options lifts conversion by 5 to 15% in most tests.

Run one test at a time. If you change the trial duration and the CTA copy simultaneously, you will not know which change moved the needle. Use RevenueCat Experiments or Adapty A/B testing to split traffic 50/50 and let the test run for at least two full billing cycles before declaring a winner.

Trial duration is the single highest-leverage variable in your subscription funnel, and most teams pick it without any data. Here is how to think about it properly.

Match Trial Length to Your Aha Moment

The right trial duration depends on how long it takes your user to experience the core value of your product. A meditation app might deliver value in a single 10-minute session (3-day trial works). A fitness app needs a user to complete 3 to 4 workouts to feel results (7-day trial makes sense). A habit tracker needs 2 to 3 weeks of consistent use to demonstrate behavior change (14-day trial is appropriate).

Analyze your existing data. Look at the cohort of users who converted and identify when they first engaged deeply with the core feature. If 80% of converters hit their aha moment by day 3, a 7-day trial is wasting 4 days of free access. If most converters do not engage meaningfully until day 5, a 3-day trial is cutting them off too early.

The Economics of Trial Length

Longer trials are not free. Every day of free access is a day your servers handle load without revenue. More importantly, longer trials increase the window for users to forget about your app entirely. A 14-day trial gives a user 14 days to get distracted, forget they signed up, and then get hit with an unexpected charge that triggers a refund request.

Short trials (3 days) create urgency but can feel aggressive. They work best for apps with immediate value delivery: photo editors, AI tools, and utility apps. Medium trials (7 days) are the default for a reason. They balance value demonstration with urgency. Long trials (14+ days) only make sense for apps where the value compounds over time: fitness, education, and productivity tools.

Introductory Offer Strategies

Both Apple and Google support introductory pricing beyond simple free trials. You can offer a discounted first period ($0.99 for the first month, then $9.99/month) or a discounted first payment ($4.99 for the first year, then $49.99/year). These "penny trial" approaches can outperform free trials because the user has made a financial commitment, even a small one, which increases their psychological investment in the product.

Apple StoreKit 2 supports three introductory offer types: free trial, pay-as-you-go (discounted price for a set number of periods), and pay-up-front (one-time discounted price for a set duration). Google Play Billing v7 supports equivalent structures through its base plan and offer system. RevenueCat and Adapty both surface these offer types natively.

Test a free 7-day trial against a $0.99 first-month offer. In many categories, the paid intro offer generates higher lifetime value because the initial payment filters out users who never intended to pay.

Platform compliance is where subscription apps get rejected, pulled from stores, or hit with penalties. Both Apple and Google have tightened their billing rules significantly, and staying compliant requires careful attention to detail.

Apple StoreKit 2 Requirements

StoreKit 2, introduced in iOS 15 and now the required framework for new apps, uses a modern async/await API with server-side receipt validation through the App Store Server API. Key compliance requirements include:

• Subscription disclosure: Your paywall must clearly display the subscription price, duration, and terms before the user taps subscribe. Apple rejects apps that obscure pricing or use dark patterns to trick users into subscribing.
• Restore purchases: You must provide a visible "Restore Purchases" button. Apple will reject your app if users cannot recover their subscriptions on a new device.
• Subscription management link: Include a link to Apple's subscription management page (itms-apps://apps.apple.com/account/subscriptions) so users can cancel directly.
• Trial disclosure: If you offer a free trial, you must clearly state the trial duration, the price that will be charged when the trial ends, and the billing frequency.

StoreKit 2 also introduces Transaction.currentEntitlements, which gives you a real-time view of the user's active subscriptions without needing to validate receipts manually. This is a huge improvement over the original StoreKit receipt parsing approach.

Google Play Billing Library v7 Requirements

Google Play Billing Library v7 (released in 2028) introduces the new subscription model with base plans and offers. A single subscription product can have multiple base plans (monthly, annual) and each base plan can have multiple offers (free trial, introductory price, developer-determined offer). Compliance requirements include:

• Transparent pricing: Display the full price, billing period, and any introductory pricing clearly on the paywall.
• Library version: Google requires apps to use Billing Library v6 or later. Apps on older versions risk removal from the Play Store.
• Purchase acknowledgment: You must acknowledge every purchase within 3 days using the BillingClient.acknowledgePurchase() method. Unacknowledged purchases are automatically refunded.
• Subscription cancellation: Provide a way for users to manage their subscription, linking to the Google Play subscription management page.

If you are using RevenueCat or Adapty, both SDKs handle purchase acknowledgment, receipt validation, and entitlement management automatically. But you are still responsible for the paywall UI compliance: clear pricing disclosure, restore button, and subscription management links.

Payment failures are inevitable. Credit cards expire, bank accounts get overdrawn, and payment processors have temporary outages. How you handle these failures determines whether you keep the subscriber or lose them permanently.

What Grace Periods Are

Both Apple and Google offer grace periods: a window after a payment failure during which the user retains full access to their subscription while the platform retries the charge. On iOS, grace periods are 6 days for weekly subscriptions and 16 days for monthly and annual subscriptions. On Google Play, grace periods are configurable up to 30 days in the Google Play Console.

You must opt into grace periods in App Store Connect and the Google Play Console. They are not enabled by default. Enabling them is one of the easiest wins in subscription retention. Apple reports that grace periods recover 16% of otherwise-churned subscriptions.

Implementing Grace Period Logic

When a payment fails and the user enters a grace period, RevenueCat and Adapty both emit specific events (BILLING_ISSUE on RevenueCat, "billing_issue_detected" on Adapty). Your app should:

• Continue providing full access. The user is technically still a subscriber during the grace period. Do not downgrade them.
• Show a soft in-app banner. Something like "There is an issue with your payment method. Please update it to avoid losing access." Include a deep link to the platform's payment method settings.
• Send a push notification. On day 1 and day 3 of the grace period. Keep it helpful, not threatening.
• Send an email. If you have the user's email, send a clear message explaining the issue and how to fix it.

Billing Retry Logic

After the grace period expires, both platforms enter a "billing retry" phase. Apple retries for up to 60 days. Google retries based on your configured account hold period. During billing retry on iOS, the subscription status changes to "expired" but Apple is still attempting to charge the card. On Google, the user enters an "account hold" state.

During account hold, you should revoke access but keep the user's data and preferences intact. If the payment succeeds during retry, restore their access seamlessly. If you are tracking strategies to reduce app churn, grace period and billing retry handling should be near the top of your list. These are subscribers who want to keep paying. All you have to do is help them.

Even with perfect grace period handling, some subscribers will cancel. Your win-back flow is the last line of defense before that user is gone for good. The best subscription apps treat win-back as a structured, multi-touch system.

Timing the Win-Back Sequence

Do not wait weeks to re-engage a churned subscriber. The optimal win-back sequence looks like this:

• Day 0 (cancellation): Show an in-app cancellation survey. Ask why they are leaving (too expensive, not using enough, found alternative, technical issues). This data is gold for product improvement and for personalizing the win-back offer.
• Day 1: Send a push notification acknowledging the cancellation. "We are sorry to see you go. Your premium access is active until [date]." No hard sell.
• Day 3: Send an email highlighting what they will lose: specific features, data, or content. Personalize this based on their actual usage patterns.
• Day 7: Offer a win-back discount. Apple supports Win-Back Offers in StoreKit 2, allowing you to offer a discounted resubscription to users who previously canceled. Google has equivalent promotional offers. A 30 to 50% discount for the first resubscription period recovers 5 to 10% of churned users.
• Day 14: Final push notification with the discount offer and a clear expiration date. "Your 50% off offer expires in 48 hours."

Apple Win-Back Offers and Google Developer-Determined Offers

Apple introduced Win-Back Offers as a native StoreKit 2 feature. You configure these in App Store Connect, specifying eligibility criteria (users who were previously subscribed and canceled at least a set number of days ago). The offer appears in the App Store subscription management page and can be surfaced in your app via the StoreKit API.

Google Play supports developer-determined offers, which let you target specific user segments with custom pricing. You create the offer in the Google Play Console, define targeting rules, and present the offer in your app using the Billing Library. This is more flexible than Apple's approach because you control the targeting logic entirely.

Win-Back Paywall Design

The win-back paywall should look different from your standard paywall. It should acknowledge that the user was previously a subscriber, highlight what has changed since they left (new features, content, improvements), and present the discount prominently. "Welcome back. Here is what you have been missing" with a list of new features and a discounted price is a simple, effective pattern.

If you are thinking about mobile conversion rate optimization more broadly, win-back flows are often the highest-ROI investment because you are targeting users who already demonstrated willingness to pay.

Building a production-grade subscription app with paywalls and trial flows is a 6 to 10 week effort for a small mobile team. Here is a realistic breakdown:

• Weeks 1 to 2: SDK integration (RevenueCat or Adapty), product/entitlement configuration, basic purchase flow, and receipt validation. This is the foundation.
• Weeks 3 to 4: Paywall UI development with remote configuration support. Build the component system so you can change copy, layout, and pricing without app updates. Implement the onboarding-to-paywall flow.
• Weeks 5 to 6: Grace period handling, billing retry logic, and in-app messaging for payment failures. Webhook integration with your backend for subscription state syncing.
• Weeks 7 to 8: A/B testing infrastructure, analytics integration, and trial duration testing. Set up RevenueCat Experiments or Adapty A/B testing and launch your first paywall test.
• Weeks 9 to 10: Win-back flows, cancellation surveys, promotional offer configuration, and end-to-end QA across both platforms. StoreKit 2 sandbox testing on iOS and Google Play Billing test tracks.

The biggest mistake teams make is treating the subscription system as "done" after launch. The apps that monetize well are running paywall tests every single week. They are analyzing trial-to-paid conversion by cohort, adjusting trial durations by acquisition channel, and iterating on win-back sequences based on churn reason data.

If you are building a subscription app and want to get the monetization infrastructure right from the start, we can help. Our team has shipped subscription apps across fitness, education, productivity, and health categories, and we know where the conversion pitfalls hide. Book a free strategy call and we will walk through your paywall architecture, trial flow design, and monetization roadmap together.