We integrate Soft Paywall with skip capability into mobile apps, balancing monetization and user experience. This approach avoids scaring users away at the start, offering a paid subscription after they appreciate the product's value. With extensive experience, we have implemented 20+ projects with paywall mechanics, and A/B test results show: conversion with proper triggers increases 2–3 times. In one edtech app, switching from hard paywall to Soft Paywall with skip button increased conversion 4x (from 2% to 8%). Subscription price starts at $4.99/month, and users can save up to 50% with annual plans.
Soft Paywall with Skip Mechanism
Soft Paywall differs from hard paywall in that the user can close the paywall without purchasing and continue using the app's functionality. According to App Store Review Guidelines Section 4.2, the skip button must be immediately visible and conveniently placed. This reduces frustration and improves app perception.
Effective Soft Paywall Triggers
A typical mistake is showing soft paywall on the first launch. The user hasn't yet understood the value, dismisses — the 'seen paywall' metric increases, but conversion does not. Proper triggers:
- After reaching an aha-moment (user created their first project, generated first result, completed their first lesson).
- When attempting to use a premium feature.
- After N sessions (3–5 opens) — user returned, so they felt value.
- By time: on the 3rd day using the free trial.
All these triggers are managed via PaywallTriggerManager — logic on the server or in Firebase Remote Config. When to show, how often, after how many sessions — these parameters are A/B tested.
Configuring Display Triggers Properly
Triggers are of two types: event-based and time-based. Event-based — after a specific user action (creation, completion). Time-based — after a certain number of days or sessions. The best result comes from a combination: first display event-based, repeat displays time-based with cooldown.
| Trigger type |
Example |
Conversion (A/B) |
| Event-based |
After creating a project |
8–12% |
| Time-based |
3rd day of use |
5–7% |
| Intent-based |
Attempting premium feature |
15–20% |
For instance, in a meditation app, an intent-based trigger when trying to open a premium course showed 18% conversion, which is 25% higher than the market average.
Why the Skip Button Must Be Available
The 'Skip' / 'Continue for free' button must not be hidden. Apple rejects UI where Skip is deliberately placed inconveniently, in small font, or appears with a delay. The rule: if the free version functionally works — the user must see a way back without obstacles.
Technically: pressing Skip is logged in analytics (Analytics.logEvent("paywall_skipped", parameters: ["trigger": triggerName, "variant": variantId])). This data is for A/B testing — different paywall variants have different skip rates and conversion rates. Both numbers are important: a paywall with zero skip rate and 1% conversion is worse than a paywall with 40% skip rate and 5% conversion. Soft paywall with skip button converts 2–3 times better than hard paywall without alternatives.
Display Frequency
Showing soft paywall every time a premium feature is accessed is aggressive and annoying. Standard scheme: show if lastPaywallShownAt was more than N days ago OR if the user manually accessed a premium feature (intent-triggered). lastPaywallShownAt is stored in UserDefaults / SharedPreferences, updated on each display.
Server-side configuration via Remote Config: soft_paywall_cooldown_days: 3, max_impressions_per_week: 2 — can be changed without a release during A/B testing.
Overlay vs Full-Screen
Soft paywall can be:
-
Half-sheet / bottom sheet —
UISheetPresentationController (iOS 15+) with .medium detent. The user sees content underneath, reducing anxiety from being 'locked in'.
-
Full-screen modal with transparent background (blur overlay) over content — for feature-triggered paywall, showing exactly what is available in premium.
-
Inline banner in the feed at a specific position — least aggressive option, lower conversion but doesn't interrupt UX.
On iOS, UISheetPresentationController with prefersGrabberVisible = true signals that the sheet can be dismissed. This is not accidental — people interact more with UI when they understand they can exit.
| Overlay type |
Conversion |
User experience |
| Bottom sheet |
8–12% |
Low aggression |
| Full-screen modal |
12–18% |
Medium, but effective |
| Inline banner |
3–5% |
Minimal intrusion |
Soft paywall with inline banner showed a 30% lower churn rate compared to full-screen modal in one of our projects.
Logic After Skip
User skipped the paywall — do not aggressively show the 'Upgrade' button everywhere. Save a record of intent (user_intent_score) and use it for more precise targeting of the next display: if the user attempted to use a premium feature 3 times — show the next paywall earlier than the standard cooldown.
PaywallTriggerManager increments premium_feature_attempt_count on each attempt. When reaching a threshold — shows paywall regardless of cooldown.
Our Workflow
- Determine display triggers together with the product owner.
- Develop PaywallTriggerManager + Remote Config integration.
- UI for paywall + skip logic.
- Analytics events (skip rate, conversion).
- Set up A/B test (minimum 2 variants).
- QA and publish.
More on trigger configuration via Remote Config
In Remote Config, we set parameters: paywall_triggers (JSON with list of events and time conditions), cooldown_days, max_impressions_per_week. Each trigger has priority, weight for A/B tests, and enabled flag. This allows changing logic without a release.
Estimated Timelines
Soft paywall with configurable triggers, event analytics, and Remote Config management — from 2 to 3 business days with ready IAP integration and Server API.
| Stage |
Duration |
Result |
| Analytics and design |
4–8 hours |
Trigger and UI specification |
| Component development |
1–2 days |
PaywallTriggerManager + screen |
| Remote Config integration |
2–4 hours |
Parameters in console |
| A/B test setup |
2–4 hours |
Ready split |
| QA and release |
4–8 hours |
Pass review |
What's Included
- PaywallTriggerManager (iOS/Android)
- Remote Config integration
- Event analytics (Firebase, Amplitude)
- A/B test (minimum 2 variants)
- QA and documentation
- Post-release support (2 weeks)
We guarantee stable operation and compliance with App Store Review Guidelines. For a consultation on your project, contact us. Experience of 20+ paywall integrations — let's discuss your case. Get an engineer consultation to choose the optimal triggers for your app.
Mobile App Monetization: IAP, Subscriptions, and Ad Mediation
An app with poorly implemented purchases loses money not because users don't want to pay, but because a StoreKit transaction hangs, Receipt Validation fails with an error, or restore purchases doesn't work — and the user writes to support or leaves a 1-star review. Our experience (over 7 years in mobile development) shows that proper monetization increases LTV by 30–60% within the first three months after implementation. Get a consultation on monetizing your app — we'll analyze the current model and find growth points.
Why StoreKit 2 is the Best Choice for IAP?
StoreKit 2 (iOS 15+) is a modern API with async/await and device-side verified transactions without a server. Transaction.currentEntitlements returns all active purchases. Key change compared to StoreKit 1: JWS signature verification on device via VerificationResult<Transaction> — no need to send receipt to server for basic validation.
But server-side validation is still needed for consumable purchases and fraud prevention. App Store Server API replaces the old /verifyReceipt endpoint. Webhooks via App Store Server Notifications v2 provide real-time events: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — without polling.
A typical mistake: not handling paymentQueue(_:updatedTransactions:) in the background for unfinished transactions. User bought a consumable, app crashed before finishTransaction — purchase remains in queue, restores on next launch and requires reprocessing on server. Without server idempotency — double crediting.
How Not to Lose Revenue on Subscriptions?
The subscription model requires tracking states: trial → active → grace period → expired → refunded. RevenueCat is the de facto standard for managing subscriptions in production. It abstracts StoreKit and Google Play Billing, providing a unified API, webhooks, cohort analytics, and A/B testing of paywalls.
Alternatives to RevenueCat include custom implementations with Adapty or Qonversion. Fully custom only if data must not leave the infrastructure or there is non-standard logic. We guarantee that webhook setup and subscription lifecycle event handling is done without losses — verified on projects with over 500k DAU.
Google Play Billing Library 6+ requires handling PurchasesUpdatedListener and explicitly calling acknowledgePurchase() or consumePurchase() within 3 days — otherwise Google automatically cancels the purchase and refunds. The average cost of such an error is a significant loss per user per month (based on our project data).
Ad Mediation: Boosting CPM via Bidding
Showing ads from a single source means losing revenue. Mediation (waterfall or bidding) requests ads from multiple networks and displays the best bid. Google AdMob is the foundation for banner, interstitial, rewarded ads. Mediation via AdMob Mediation or MAX (AppLovin) is the second de facto standard. MAX uses In-App Bidding — a real-time auction without waterfall. In practice, MAX yields significantly higher CPM than classic waterfall (depending on geo and audience). For example, for rewarded video in the US, the improvement can be substantial. With 100,000 rewarded video impressions per day, switching from waterfall to In-App Bidding can generate additional daily revenue.
ironSource (Unity Ads) has a strong position in the gaming segment, especially rewarded video. Mintegral covers the Asian audience well.
Setting up mediation requires ATT (App Tracking Transparency) on iOS 14+. Without requestTrackingAuthorization, ad CPM drops by 3-5 times for non-consenting users. SKAdNetwork and Privacy Manifest (iOS 17) are mandatory requirements; without them, review fails.
| Network |
Ad Type |
Feature |
| AdMob |
banner, interstitial, rewarded |
Wide network, easy start |
| MAX (AppLovin) |
rewarded, interstitial |
In-App Bidding, high fill rate |
| ironSource |
rewarded video |
Best for games |
| Mintegral |
rewarded, native |
Asia, programmatic |
How We Implement Monetization: Step-by-Step Process
- Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
- Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
- IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
- Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
- Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
- A/B testing of paywall — use Remote Config for experiments without a release.
- Launch and monitoring — 2 weeks of free support after launch, bug fixes by 24-hour SLA.
How to Design a Freemium Model and Paywall?
Freemium works when the boundary between free and paid is properly drawn. Too strict a paywall at the start — users delete. Too generous a free tier — no incentive to pay.
A technically sound pattern: server-side feature flags (Remote Config in Firebase or LaunchDarkly) control access to features. This allows A/B testing of paywall without a release, changing trial conditions, and running promotions.
Implementation at the code level: EntitlementManager — a single point for checking access to features, aware of subscription status, flags, and promos. No scattered isPremium checks throughout the code. Experience shows this approach reduces paywall-related bugs by 80% (confirmed on 30+ projects).
Checklist of Typical Monetization Mistakes
- Missing handling of
unfinished transactions — revenue loss of 5-10%.
- No server-side idempotency for consumable processing — double crediting.
- Forgot to call
acknowledgePurchase() on Android — purchase cancelled after 3 days.
- Not handling
REFUND and DID_RENEW events — incorrect subscription status.
- Paywall without A/B testing — leaving 20-40% of monetization potential.
- Ads from a single source (e.g., AdMob without mediation) — CPM 15-30% lower.
Scope of Monetization Work
- Current model audit — analysis of funnel, paywall, price tiers.
- IAP integration — StoreKit 2 / Google Billing 6, receipt validation, webhooks.
- Ad mediation — configure MAX / AdMob, connect 3-6 networks, test fill rate.
- Analytics setup — RevenueCat, Amplitude / Firebase, cohort analysis.
- Documentation — description of entitlements, restoration procedure, review checklist.
- Team training — analysis of typical mistakes, support recommendations.
- Guarantee — 2 weeks free support after launch, bug fixes by 24-hour SLA.
Estimated Timelines
| Stage |
Duration |
| Basic IAP (one store) |
1–2 weeks |
| Subscription system + RevenueCat + paywall |
3–5 weeks |
| Ad mediation (MAX + 3 networks) |
1–2 weeks |
| Full cycle (IAP + ads + analytics) |
4–8 weeks |
Cost is calculated individually. We have been working in this field for over 8 years and have implemented monetization in over 40 projects — many of which passed App Store Review without a single rejection. Contact us for an audit or order a consultation — we'll tell you what growth points exist in your app.
