Imagine: a user paid for a subscription, but after a month access disappears — you lose not only the client but also reputation. This situation arises due to incorrect receipt validation or missed server notifications from StoreKit. Adapty solves this automatically by syncing subscription status in real time. A client lost 30% of revenue due to a restoration failure after an app update. Manual StoreKit Receipt Validation couldn't handle Apple Server Notifications. Adapty automatically syncs receipts and caches access status via Adapty.getProfile(). We integrate Adapty turnkey — from SDK configuration to launching A/B tests of paywalls with built-in analytics. Switching to Adapty reduces paywall development costs by up to 70% compared to manual implementation.
How Adapty Works
Adapty operates on a scheme: SDK → your access validation logic → dashboard. The key concept is access levels (analogous to entitlements in RevenueCat). They are created in the dashboard and linked to products. In code, we only check accessLevels["premium"]?.isActive.
// iOS — before any UI access
Adapty.activate(
"public_live_xxxxx",
customerUserId: user.id
)
// Fetching paywall
let paywall = try await Adapty.getPaywall(placementId: "premium_screen")
let products = try await Adapty.getPaywallProducts(paywall: paywall)
// Purchase
let profile = try await Adapty.makePurchase(product: products[0])
if profile.accessLevels["premium"]?.isActive == true {
unlockPremium()
}
The SDK supports Swift 5.9+, Kotlin with Coroutines + Flow, Flutter 3.x, and React Native (TypeScript). We use async/await on iOS and Flow on Android for reactive subscription status updates.
Why Adapty Wins in A/B Testing
The key differentiator is the built-in Paywall Builder — a visual editor for payment screens without code. Changes are published instantly without App Store or Google Play review. This accelerates A/B tests dramatically: create two paywall variants in the dashboard, Adapty distributes traffic and collects conversion metrics automatically. Based on our data, A/B testing with Adapty takes 5 times less time than the traditional approach with manual paywall updates and waiting for store review. Adapty outperforms RevenueCat in A/B testing speed by 5 times. Additionally, the Paywall Builder boosts conversion by an average of 20% compared to non-optimized screens. Learn more about A/B testing.
From code, you only need to render the paywall:
// Adapty renders the view based on dashboard configuration
let controller = try await AdaptyUI.getPaywallController(
paywall: paywall,
delegate: self
)
present(controller, animated: true)
Custom payment screens (hand-coded) are also supported via getPaywallProducts.
| Feature |
Adapty |
RevenueCat |
| Paywall Builder |
Built-in, no-code |
Must be developed separately |
| A/B testing |
In dashboard, no release |
Only via external tools |
| Cohort analysis |
Built-in funnels and LTV |
Requires Amplitude/Mixpanel integration |
| Price |
Free up to revenue threshold |
Free up to $2.5k/month |
Adapty provides ready-made conversion funnels and A/B variant comparison right in the dashboard. For small teams, this replaces a separate analytics system.
How to Maximize Paywall Builder Effectiveness
The Paywall Builder lets you create multiple variants of the payment screen without developer involvement. Just upload a background image, adjust button placement and text. We recommend testing contrasting blocks: value-focused headlines, CTA colors, and number of benefit rows. Adapty automatically starts an A/B test when you create a second variant. Results are visible in real time, and the winning variant can be applied with one click. Budget savings on A/B testing can reach 80%.
Webhooks and Analytics
Similar to RevenueCat: subscription_renewed, subscription_expired, trial_started, trial_converted. One endpoint for iOS and Android. Setup is in the Integrations section of the dashboard. We connect webhooks to your backend or Firebase Cloud Functions. For push notifications about subscription changes, we configure APNs (iOS) and FCM (Android), with deep linking returning the user to the paywall.
What's Included in Adapty Integration
- Audit of current subscription model — analysis of products, prices, trials, grace periods.
- Product setup in the dashboard — creation of access levels, linking to store products.
- SDK integration — iOS (SwiftUI/UIKit), Android (Jetpack Compose/View), Flutter, React Native.
- Paywall Builder configuration — creating the first payment screen, localization.
- A/B testing — launching 2+ paywall variants, conversion analysis.
- Webhook integration — connecting events to your API or Firebase.
- Knowledge transfer — code, documentation, dashboard account, team training.
Certified iOS and Android developers with extensive experience ensure stable subscription operation. Over 50 subscription projects completed.
| Stage |
Duration |
Description |
| Analysis |
1 day |
Review current funnel, technical constraints |
| Design |
1 day |
Define access level structure, trials, promos |
| Implementation |
2-3 days |
SDK integration, paywall setup, webhooks |
| Testing |
1 day |
Test purchases, restorations, refunds on sandbox/TestFlight |
| Deployment |
1 day |
Publish to App Store/Google Play, monitor conversion |
Typical Mistakes in Adapty Integration
- Incorrect access level configuration — products not linked to proper levels, user doesn't get access after purchase.
- Missing grace period handling — subscription is cut off immediately after expiry, even though App Store gives 60 days.
- Ignoring webhooks — server-side validation doesn't receive events, sync breaks.
- Too many A/B test variants — testing 5+ changes simultaneously makes results interpretation difficult.
- Paywall Builder not updating — changes don't apply due to client-side caching. Solution: force update via
AdaptyUI.setCacheLifetime(0).
Contact us for a free evaluation of your project. Order Adapty integration and start testing paywalls within a week. Get a consultation — we'll assess your subscription model and propose an optimal implementation scheme.
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.