Flutter In-App Purchases 2026: RevenueCat vs Superwall vs Native

Shipping subscriptions in a Flutter app in 2026 is no longer a single-vendor decision. There are three real stacks I see indie developers argue about every week: the Flutter Favorite in_app_purchase package directly, RevenueCat as the default abstraction, and Superwall as the remote-paywall challenger that shipped a first-class Flutter SDK in late 2025. I have shipped production apps on all three and this is the comparison I wish existed when I was picking.

Short version: use RevenueCat if you want the safest, most battle-tested default that handles iOS, Android, and web billing behind one API. Use Superwall if paywall A/B testing and remote UI iteration are the most valuable features for your product. Use native in_app_purchase only if you genuinely want to own every piece of the subscription plumbing and have no need for cross-platform entitlements. Longer version, decision tree, and cost math below.

The three stacks in one paragraph each

Before we compare apples, here is the 30-second pitch for each.

• Native in_app_purchase. The Flutter team's first-party package. Wraps StoreKit 2 on iOS and Google Play Billing v7 on Android. No entitlement server, no dashboard, no web billing. You build all of that yourself if you want it. Works, free, lowest abstraction.
• RevenueCat. The category-defining subscription platform.purchases_flutter is the canonical SDK, handles product fetching, purchase flow, receipt validation server-side, entitlements, web billing, and analytics. Free up to $2,500 per month in tracked revenue, then revenue share kicks in. The industry default for a reason.
• Superwall. Remote-configurable paywalls with built-in A/B testing.superwallkit_flutter is the Flutter SDK. You design paywalls in the Superwall dashboard (or from Figma), publish without shipping an app update, and A/B test prices, copy, and layout without touching your Dart code. Stores entitlements itself. Free up to 1 million monthly tracked events on their newest plan.

Native in_app_purchase: when is it actually enough?

The temptation for a first-time Flutter paywall is to reach straight for in_app_purchase because it is free and official. In 2026 the package is solid. It wraps StoreKit 2 properly, it supports subscriptions, it gives you purchase streams, and it has a working Android implementation. For a narrow set of apps, it is a reasonable choice.

Where native is genuinely fine:

• One-time products only. Unlock a premium mode or a small set of features forever. No renewals, no trials, no entitlement complexity.
• One platform. You are iOS-only or Android-only and will not ship web billing.
• You already have a backend. You run a server, you can validate App Store and Play receipts yourself, you can track entitlements in your own database.

Where native starts to bite:

• Cross-platform entitlements. A user who subscribed on iOS opens the app on Android. Native in_app_purchase has no idea they are entitled. You build the sync layer yourself, and it is more work than most indies expect.
• Server-side receipt validation. Apple's JWS receipts and Google's Play Developer API both require ongoing maintenance, secret rotation, and edge-case handling (refunds, subscription state changes, grace periods).
• Analytics. MRR, churn, LTV, cohort retention: you compute these yourself. You will eventually want a dashboard, and building one is a distraction from your product.
• Paywall experimentation. Every pricing test requires a server orchestration layer and a client release cycle. This is the single biggest reason most indie teams move off native within their first year.

My rule: if your app monetization is a single lifetime unlock and nothing else, native is fine. If you have subscriptions, cross-platform users, or any ambition to iterate on pricing, skip it.

RevenueCat: the default that just works

RevenueCat is the subscription platform I recommend by default in 2026. The purchases_flutter SDK is stable, widely used, and handles the category of problems most indies do not want to own. The shape of a minimal Flutter integration is under 30 lines total across main.dart and your paywall widget, which is the point.

What RevenueCat does for you:

• Cross-platform entitlements. One abstraction works for iOS, Android, and web. User buys on iOS, opens the Android app, subscription is recognized.
• Server-side validation. Every purchase, renewal, refund, and cancel is validated against Apple and Google servers and reflected in your entitlements with no code on your side.
• Analytics dashboard. MRR, churn, LTV, cohort retention, trial-to-paid conversion by offering. All available without a line of analytics code.
• Web billing with Stripe. Web Billing reached GA in 2025 and matured through early 2026. You sell via Stripe on web, RevenueCat syncs entitlements to the Flutter app. Critical for anyone selling outside the stores (EU external purchase links, SaaS with web tier).
• Experiments. Built-in A/B testing of offerings and prices. Not as flexible as Superwall's paywall-level testing, but sufficient for most pricing experiments.
• Webhooks. Real-time purchase events to your backend, perfect for sending receipts, updating Firestore, kicking off onboarding emails.
• Offline grace periods and billing retry. Handles the dozen nasty edge cases of real subscription billing that you did not know existed until they bit you.

Where RevenueCat falls short:

• Paywall UI is yours to build. They have Paywalls v2 which lets you build remote-configurable UIs in their dashboard, and they are good. They are not quite as flexible as Superwall's full pixel-control remote UI.
• A/B testing is product-level, not UI-level. Swap a price, swap an offering, show to a cohort. It is less opinionated on layout and copy than Superwall.
• Revenue share at scale. 1 percent of tracked revenue above $2,500 per month on the Starter plan, dropping with scale tiers. Real money once you are past 100,000 a month, but rarely large enough to justify building all the above yourself.

Superwall: the remote-paywall killer feature

Superwall launched its Flutter SDK in late 2025 and the value proposition is the single thing it does better than anyone: paywall UI iteration without shipping app updates. You design the paywall in the Superwall dashboard (or import Figma), add triggers to your Dart code, and the SDK fetches the UI at runtime. Prices, copy, layout, and A/B test splits are all controlled remotely.

What Superwall does best:

• Remote paywall design. You change your paywall layout on a Thursday and a million users see the new version on Friday. This is impossible with any other stack without a full release.
• Dashboard-based A/B testing. Not just prices. Actual layouts. Headline copy. Testimonial order. Button labels. Conversion rate lift for indies who invest in paywall optimization is typically 20 to 60 percent over three to six months.
• Placements, not buttons. You trigger a paywall from a Dart event ("userHitLimit", "openedSettings"), and Superwall decides what to show based on rules you set in the dashboard. This decouples your paywall strategy from your code.
• Feature gating by entitlement. Like RevenueCat, it handles entitlements end-to-end.

Where Superwall falls short:

• Paywall-first, not billing-first. Superwall handles payments via StoreKit and Play under the hood. Advanced billing features (cross-platform entitlement sync, web billing) are newer and less mature than RevenueCat's equivalents.
• Design investment required. The remote paywall is only as good as the paywalls you design. Indies without a designer have to either commit to learning the editor or use the starter templates, which are good but not unique.
• Flutter SDK maturity. superwallkit_flutter is real and shipping, but it is newer than purchases_flutter. Edge cases around configuration, plugin lifecycle, and platform-specific behavior get fixed faster on the iOS native SDK than on Flutter. Check the GitHub issues before committing.
• Pricing at scale. Free tiers are generous but paid plans are per-event. At high volume you can end up paying meaningful money. Price out your scale before committing.

Can you run RevenueCat and Superwall together?

Yes, and in fact this is the pattern I see most often in production apps that care about both sides of the problem. Superwall handles paywall UI and A/B testing. RevenueCat handles cross-platform entitlement truth and web billing. Purchases flow through Superwall to the native store, RevenueCat observes the transaction via its observer mode, and your app asks RevenueCat for entitlement state.

Superwall ships official integration docs for this pattern. The wiring is a single flag in Superwall's configuration that tells it RevenueCat is the system of record for entitlements. You get the best of both: remote paywall iteration from Superwall and the cross-platform billing backbone from RevenueCat. The cost is double the SDK surface area and a slightly slower cold start.

Feature matrix: the honest comparison

Pricing math for indie-scale apps

Pricing is where the three diverge. Here is a three-scenario table using rough 2026 numbers.

Two takeaways. First, at $1K to $10K MRR both RevenueCat and Superwall are negligible cost. Spend the effort budget on your product, not on billing plumbing. Second, at scale both charge real money, and a hybrid architecture (Superwall for UI + RevenueCat for billing) makes the combined bill non-trivial. Plan the combined math before you adopt both.

The architecture I actually ship

As with AI, the single pattern that survives provider migrations is to put every purchase call behind an interface. Your BLoC or Riverpod feature code should never importpurchases_flutter or superwallkit_flutter directly. It should import a PaywallService abstraction.

// lib/features/billing/domain/paywall_service.dart
abstract class PaywallService {
  Stream<EntitlementState> watchEntitlement();
  Future<void> presentPaywall(String placement);
  Future<void> restorePurchases();
}

// Three implementations, one API
class NativeIapPaywallService implements PaywallService { /* ... */ }
class RevenueCatPaywallService implements PaywallService { /* ... */ }
class SuperwallPaywallService implements PaywallService { /* ... */ }

// Even the hybrid pattern fits the interface
class HybridPaywallService implements PaywallService {
  HybridPaywallService(this.superwall, this.revenueCat);
  final PaywallService superwall;
  final PaywallService revenueCat;

  @override
  Stream<EntitlementState> watchEntitlement() =>
      revenueCat.watchEntitlement();

  @override
  Future<void> presentPaywall(String placement) =>
      superwall.presentPaywall(placement);
}

Your UI calls paywall.presentPaywall('userHitLimit'). Your feature gates check paywall.watchEntitlement(). Switching vendors is a DI change, not a refactor. This is the exact pattern The Flutter Kit ships, and it saved me a week of work the first time I migrated from native to RevenueCat mid-project.

The decision tree I actually use

When a Flutter indie asks me which to pick, four questions resolve it.

1. Do you sell subscriptions, not just one-time products? If yes, native is off the table. Go RevenueCat or Superwall.
2. Do you need cross-platform entitlements (iOS, Android, web)? If yes, RevenueCat is the simpler path. Web Billing handles the web side and native-store sync.
3. Is paywall iteration a core part of your growth plan? If you expect to test prices, copy, and layouts monthly, Superwall is worth its cost. If you will set a paywall once and mostly leave it, RevenueCat's Experiments is sufficient.
4. Can you justify two SDKs? If you answered yes to both 2 and 3, the hybrid (Superwall + RevenueCat) is the power move. Otherwise pick the one that matches your dominant need.

Three common indie profiles:

• Utility app with lifetime unlock. Native in_app_purchase. Save the complexity budget for your product.
• Subscription app, iOS plus Android, occasional pricing tests. RevenueCat. This is the default.
• Subscription app where paywall is the growth lever. Superwall as the primary UI layer, RevenueCat as the entitlement backbone.

EU external purchase link impact

If you care about EU external purchase links in 2026, this is where RevenueCat pulls ahead. RevenueCat Web Billing added native Apple external payment reporting in Q4 2025, which means switching on EU terms is a dashboard flip and a Stripe account, not a three-week engineering project. Superwall supports external links but the reporting pipeline is less mature. Native handles none of this; you build the Apple reporting service yourself.

If your roadmap includes opting into EU terms (covered in detail in the Swift Kit guide on the same topic), RevenueCat is the safer bet. If your app is under $100K in EU revenue, this is not the deciding factor.

What The Flutter Kit ships

The Flutter Kit ships a PaywallService abstraction with three implementations: native in_app_purchase, RevenueCat (default, recommended), and Superwall. A HybridPaywallService option runs Superwall for UI and RevenueCat for entitlement truth. Swap implementations in app_config.dart and the UI code does not change.

You get three production-ready paywall templates, RevenueCat Web Billing pre-wired for web and EU external purchases, subscription-gated AI endpoints, and BLoC-based entitlement streams. $69 one-time, unlimited commercial projects. See every integration on the features page or jump to checkout.

Final recommendation

If you are starting a new Flutter app in 2026 and shipping subscriptions, the right default is RevenueCat behind a PaywallService interface. You get cross-platform entitlements, analytics, web billing, and EU compliance for free. If paywall conversion optimization turns into a real growth lever six months in, you add Superwall as the UI layer without rewriting your billing plumbing, because yourPaywallService already abstracts the caller.

The worst outcome is hard-coding purchases_flutter orsuperwallkit_flutter calls throughout your feature code. Every future migration becomes a sprint. Put the purchase call behind an interface on day one and the decision you make this week is never the decision you live with forever.