Best Mobile App Boilerplates in 2026

TL;DR

ShipFlutter is the best paid starter for Flutter SaaS — includes RevenueCat, FCM push, Firebase Auth, and CI/CD out of the box for $149
t4-app is the best option for teams that want shared Next.js + React Native code in a Turborepo monorepo
Expo Router with EAS Build is the right baseline for React Native projects that don't need a paid starter
Very Good CLI is the production architecture reference for larger Flutter teams that need BLoC, feature-first structure, and testing conventions enforced from day one
App store billing via RevenueCat is non-negotiable — you cannot use Stripe for digital goods inside mobile apps

The Mobile SaaS Stack Decision

The framework decision is the most consequential choice you'll make for a mobile project. Unlike the web, where you can migrate between frameworks or gradually rewrite sections, switching mobile frameworks mid-project means rewriting every screen. Get this right before writing a line of product code.

In 2026, the realistic decision is between Flutter and React Native with Expo. Native iOS (Swift) and Native Android (Kotlin) are only justified for apps with extreme performance requirements, a platform-specific hire already on the team, or an iOS-only or Android-only strategy from the start. Cross-platform wins for most SaaS products because you ship to both stores simultaneously.

Flutter 3.x in 2026 has matured considerably. The Flutter team's semantic versioning now tracks major releases properly, and Flutter 3.22+ ships with Impeller as the default rendering engine on both iOS and Android. Impeller replaced Skia and eliminates the shader compilation jank that plagued Flutter's early reputation — the stutters on first animation render that made Flutter feel "not quite native" are largely gone. The result is that Flutter animation performance in 2026 is genuinely excellent, and the performance gap between Flutter and native is negligible for typical SaaS UI patterns. Where Flutter still underperforms native is in very complex custom gesture handling and deep OS-level integrations like CarPlay or Android Auto, but those are edge cases.

The Dart language is no longer a hiring concern it once was. Dart 3.x with sound null safety, records, and pattern matching has matured into a genuinely ergonomic language. Most experienced mobile engineers can become productive in Dart within a week. The package ecosystem on pub.dev covers virtually every SaaS need — Firebase, RevenueCat, Supabase, Sentry, Mixpanel — with official or well-maintained packages.

React Native with Expo SDK 52+ in 2026 benefits enormously from the New Architecture being stable. The New Architecture (Fabric renderer + JSI Turbo Modules) replaces the old bridge with a synchronous, high-performance communication layer between JavaScript and native code. This eliminates the largest performance complaint about React Native — the async bridge latency that caused janky scrolling and animation. If you evaluated React Native 3-4 years ago and decided against it on performance grounds, it's worth re-evaluating.

Expo's real value proposition is its ecosystem of managed workflow tools. Expo SDK 52 ships with Expo Router v3 for file-based navigation, EAS Build for cloud compilation without maintaining macOS build machines, EAS Update for over-the-air JavaScript bundle updates, and a library of native modules that cover >90% of SaaS requirements without ejecting. The "managed workflow" means a JavaScript-only developer can ship to both app stores without touching Xcode or Android Studio. For small teams, this dramatically reduces the specialized knowledge required.

The React Native advantage for web teams is code sharing — not just component sharing, but genuine shared business logic, hooks, API clients, and validation schemas. Tools like t4-app and Solito push this further with shared routing logic between Next.js and Expo. If you already have a web product and want to add a mobile app, React Native with Expo is the natural choice because the JavaScript/TypeScript ecosystem is identical.

The hiring pool consideration: React Native draws from the much larger JavaScript/TypeScript ecosystem. You can onboard a web developer onto React Native in days. Flutter requires finding engineers who know Dart, and while the pool has grown, it remains smaller than React Native's. For startups trying to move fast with a generalist team, React Native has the edge. For teams willing to invest in hiring Flutter specialists, Flutter's performance ceiling and consistent UI rendering (Flutter draws its own widgets, so iOS and Android look identical) are genuine advantages.

The bottom line: choose Flutter if performance is paramount, your team can hire Dart engineers, and you want pixel-identical UI across platforms. Choose React Native + Expo if your team is JavaScript-native, you're building on top of an existing web product, or you need maximum hiring flexibility.

Quick Comparison

Starter	Framework	Price	Billing	Auth	Push	Best For
ShipFlutter	Flutter	$149	RevenueCat	Firebase/Supabase	FCM	Flutter SaaS
Very Good CLI	Flutter	Free	Manual	Manual	Manual	Production architecture
Expo Router	RN	Free	Manual	Manual	Manual	React Native baseline
t4-app	RN + Next.js	Free	Manual	Clerk/Supabase	Manual	Web + mobile monorepo

ShipFlutter — Best Mobile SaaS Starter

Price: $149 | Creator: IndependentDevs

Purpose-built Flutter SaaS with everything mobile-specific:

In-app purchases: RevenueCat integration for iOS StoreKit + Android Billing
Auth: Firebase Auth or Supabase Auth (your choice)
Push notifications: Firebase Cloud Messaging (FCM)
Analytics: Firebase Analytics + Mixpanel
Onboarding flows: Multi-step user onboarding screens
Remote config: Feature flags and A/B testing without app updates
CI/CD: Fastlane + GitHub Actions for App Store and Play Store

What RevenueCat handles for you:

StoreKit 2 (iOS) integration
Google Billing Library 5 (Android) integration
Cross-platform subscription state
Receipt validation
Subscription status webhooks

ShipFlutter's biggest time-saver isn't any single feature — it's the combination of RevenueCat setup, FCM configuration, and the Fastlane lanes all pre-wired. Each of those pieces alone takes 2-4 hours to configure correctly from scratch, and it's easy to get them subtly wrong in ways that only surface in production. A developer who knows Flutter can expect to have a working app submitted to TestFlight within a day of purchasing ShipFlutter, compared to a week or more starting from scratch.

The included onboarding screens deserve special mention. Mobile apps live and die by their first session — if a user installs your app and doesn't understand what it does within 60 seconds, they uninstall and never return. ShipFlutter's multi-step onboarding flow with permission requests (notifications, tracking) placed at the right moments, rather than all upfront, meaningfully improves opt-in rates. These screens are built, not stubbed — you get real screens with real flows you can adapt.

For CI/CD, ShipFlutter's Fastlane configuration handles the notoriously finicky provisioning profile management, App Store Connect API key setup, and Play Store service account configuration. These are all things that can easily consume an entire day when set up manually for the first time.

t4-app — Best Web + Mobile Monorepo

Price: Free | Creator: Tim Moreton

t4-app is a Turborepo-based monorepo combining Next.js, Expo, and a shared package layer — giving you one codebase that produces a web app, an iOS app, and an Android app with shared business logic and components.

The architecture is a workspace with three primary packages: apps/next for the web app, apps/expo for the mobile app, and packages/app for shared code. The shared package contains your screens (built with Solito for cross-platform navigation compatibility), your Zustand stores, your tRPC client, and your Tamagui design system components. Tamagui compiles React Native-compatible primitives to both native views and web DOM elements, meaning a <Button> component in your shared package renders correctly on iOS, Android, and the web without platform-specific code.

tRPC is the secret weapon here. Because both Next.js and Expo are TypeScript, you can share a single tRPC client across platforms. Your API calls are type-safe end-to-end, and a type error in your schema is caught before it reaches either the web app or the mobile app. This eliminates an entire class of "it works on web but breaks on mobile" bugs that come from having two separate API integration layers.

The practical workflow with t4-app: you build a screen in packages/app/screens/. That screen uses Solito's Link and useRouter abstractions that map to React Navigation on mobile and Next.js router on web. You use Tamagui primitives (Stack, Text, Button) that render natively on each platform. Your data fetching uses the shared tRPC client. A single PR ships UI changes to all three platforms simultaneously.

t4-app is the right choice when your users genuinely live on both mobile and web. If you're building a productivity tool, a journaling app, or a project management SaaS, users will want their data accessible everywhere. Building the web and mobile apps as separate codebases creates divergence — features land on web first and take months to reach mobile, or the mobile and web UIs evolve inconsistently. t4-app prevents this architectural drift from day one.

The tradeoff: t4-app's complexity is higher than a single-platform starter. Turborepo workspace configuration, Tamagui's compilation setup, and Solito's navigation abstractions all have learning curves. For a mobile-only product, t4-app is overkill. For a product that needs web and mobile from the start, it's a significant head start.

Expo + React Native Ecosystem

Price: Free | Creator: Expo team (managed by Expo, Inc.)

For React Native projects, the Expo SDK and its surrounding tooling have become the default ecosystem. The free tier covers everything you need to ship a production app.

Expo Router v3 brings file-based routing to React Native — the same mental model as Next.js, where your file path determines your route. Create app/settings/profile.tsx and you get a /settings/profile route automatically, with typed params. This is a significant ergonomic improvement over React Navigation's manual route registration. Deep linking is configured automatically based on your file structure, and universal links (iOS) and app links (Android) require minimal additional configuration.

EAS Build solves the most painful part of React Native development for web developers: compilation. Building a React Native app for the App Store requires Xcode on macOS, which means Linux CI environments can't build iOS apps natively. EAS Build runs your build in Expo's cloud infrastructure — you push code, they build it, you get a .ipa or .apk back. For small teams without a dedicated macOS build machine, EAS Build is effectively mandatory. The free tier includes 30 builds per month, which is usually sufficient for early-stage development.

EAS Update provides over-the-air JavaScript bundle updates. Because React Native apps separate the JavaScript bundle from the native binary, you can push updates to your JavaScript code without going through app store review. This is the mobile equivalent of deploying a web update — critical bugs in business logic, UI fixes, copy changes can go out in minutes rather than the 24-72 hour review cycle. The constraint: you cannot change native code (native modules, entitlements, permissions) via OTA. Structure your app to keep native changes infrequent and you can move at near-web speed for most updates.

expo-notifications handles the full push notification stack — requesting permissions with the appropriate iOS/Android dialogs, registering with Expo's push service (which proxies to APNs and FCM), receiving and handling notifications in foreground, background, and terminated states. The API surface is clean and cross-platform, which is more than can be said for the raw APNs/FCM integration.

Very Good CLI — Flutter Architecture at Scale

Price: Free | Creator: Very Good Ventures (VGV)

Very Good CLI (VGC) is less of a starter kit and more of an opinionated Flutter project generator that enforces production-grade architecture from the first commit. VGV builds Flutter apps for major enterprises and has codified their architectural learnings into the CLI.

The generated project uses a feature-first directory structure: each feature of your app lives in its own directory with its own bloc/, view/, and data/ subdirectories. A login feature has features/login/bloc/login_bloc.dart, features/login/view/login_page.dart, and features/login/data/auth_repository.dart. This is in contrast to layer-first organization (grouping all blocs in one directory, all views in another) which creates long-distance dependencies that make refactoring difficult in large codebases.

BLoC pattern (Business Logic Component) is the state management foundation. BLoC separates business logic from UI using a unidirectional event/state stream: the UI dispatches events, the BLoC processes them and emits new states, the UI rebuilds based on state. This enforced separation makes Flutter code significantly more testable than setState or even Provider-based architectures. Each BLoC can be tested in isolation without mounting widgets — you feed in events and assert on the emitted states.

The testing conventions built into VGC projects are worth highlighting for anyone who has experienced untested Flutter codebases. The generated project includes unit tests for each BLoC, widget tests for each screen, and integration tests using patrol (VGV's own integration testing library). Code coverage is tracked automatically. VGC's philosophy is that testability is an architectural property — if your code is hard to test, your architecture is wrong. The BLoC + feature-first combination makes test coverage natural rather than retrofitted.

For teams scaling beyond a single developer, the consistency enforced by VGC's architecture is invaluable. A new engineer can navigate any feature in the codebase immediately because every feature follows the same structure. The alternative — each developer picks their own state management pattern — leads to the kind of inconsistent codebases that make onboarding painful and refactoring dangerous.

Mobile-Specific Requirements

App Store Billing

You cannot use Stripe for in-app payments in a mobile app. Apple and Google require their own billing for digital goods:

// Flutter - RevenueCat cross-platform billing
import 'package:purchases_flutter/purchases_flutter.dart';

// Initialize RevenueCat
await Purchases.configure(PurchasesConfiguration(apiKey));

// Get available products
final offerings = await Purchases.getOfferings();
final monthly = offerings.current?.monthly;

// Purchase
final customerInfo = await Purchases.purchasePackage(monthly!);
final isPro = customerInfo.entitlements.active['pro'] != null;

Push Notifications

// Flutter - Firebase push notifications
import 'package:firebase_messaging/firebase_messaging.dart';

final messaging = FirebaseMessaging.instance;

// Request permission (iOS)
await messaging.requestPermission();

// Get FCM token
final token = await messaging.getToken();
await saveTokenToServer(userId, token);

// Handle foreground messages
FirebaseMessaging.onMessage.listen((message) {
  showLocalNotification(message.notification!);
});

App Store Distribution

Getting your app into users' hands involves more than writing code. The distribution process has its own set of gotchas that catch mobile developers off guard.

TestFlight vs Internal Testing: Apple's TestFlight allows up to 10,000 external testers and is the standard beta distribution mechanism. External TestFlight builds require a brief Apple review (usually 24-48 hours) before testers can download them. Internal TestFlight builds (limited to your 25 App Store Connect team members) skip review entirely, making them useful for rapid iteration among your team. Google's equivalent — internal testing tracks — are available instantly. For staging and QA, configure your CI to automatically push to internal tracks so your team always has the latest build.

Staged rollouts: Both Apple and Google support staged rollouts for production releases — you can push an update to 5% of users initially, monitor for crashes and ratings, and gradually increase to 100%. This is a critical safety net for mobile apps where rolling back is impossible (users who updated cannot be forced to downgrade). Always use staged rollouts for major releases. For critical bug fixes, you can roll out at 100% immediately.

App Store review traps: The most common rejection reasons in 2026 are: incomplete demo account credentials in the review notes (Apple requires you to provide test credentials if your app requires login), missing privacy policy URL (mandatory for any app that collects personal data — and "login" counts), using private APIs or undocumented OS features, and apps that "don't do enough" (Apple will reject apps that are too thin relative to what a mobile app should offer versus a webpage). The single-purpose policy catches apps that try to do too many unrelated things; it also catches apps that do too little.

ASO basics: App Store Optimization follows similar principles to SEO but operates within tighter constraints. Your app title (30 characters for iOS, 50 for Android) and subtitle (30 characters for iOS) carry the most keyword weight. Keyword metadata on iOS gives you an additional 100 characters of hidden keyword space. Screenshots are the primary conversion driver on your App Store listing — invest in high-quality screenshots with feature callouts, not just raw app screenshots. Ratings directly impact search ranking; use SKStoreReviewController.requestReview() (iOS) triggered at moments of genuine user success, not randomly.

Mobile Analytics and Monitoring

Mobile analytics differs from web analytics in important ways: sessions are interrupted by phone calls, background app refresh, and lock screens; attribution is complicated by App Store privacy changes (iOS 14.5+ ATT); and crashes happen silently on user devices rather than in server logs you can watch.

Sentry for crash monitoring is the standard. Sentry's Flutter and React Native SDKs capture unhandled exceptions with full stack traces, device information (OS version, device model, memory), breadcrumbs showing what the user did before the crash, and release tracking so you can see which version introduced a regression. Configure Sentry in CI to automatically create source maps for React Native and dSYM symbol uploads for Flutter, so crashes display human-readable stack traces rather than memory addresses.

Firebase Analytics provides event-based analytics with zero marginal cost. The automatic events (session start, first open, app update) cover baseline funnel analytics without any custom instrumentation. Custom events should track your key product flows: onboarding completion, feature activation, subscription conversion, paywall views. The integration between Firebase Analytics and Firebase Remote Config enables A/B tests where you change app behavior (paywall positioning, onboarding length) and measure conversion impact across cohorts.

Mixpanel adds user-centric behavioral analytics that Firebase's session-centric model doesn't support well. Where Firebase tells you how many times an event fired, Mixpanel tells you which users completed a funnel, how long they took, and where they dropped off. For SaaS apps, the user retention and cohort analysis features in Mixpanel are essential for understanding churn patterns. Both Firebase Analytics and Mixpanel are used together in many production apps — Firebase for cheap high-volume event capture, Mixpanel for deeper retention analysis.

Monetization Models

Mobile monetization has different constraints and opportunities than web SaaS. The app stores take 15-30% of all subscription revenue (15% for subscriptions older than one year on both Apple and Google, reduced from 30%). This margin hit is a real factor in pricing — a $10/month web SaaS subscription needs to be $12-13/month in-app to net the same revenue.

Subscription vs one-time purchase vs freemium: Subscriptions dominate SaaS mobile monetization because they align with the recurring value delivery model and provide predictable revenue. One-time purchases work for tools with clear, discrete value (a video editor, a specific utility) but are increasingly rare in SaaS. Freemium with a subscription upgrade is the standard model: a meaningful free tier that demonstrates value, with a clearly scoped paid tier that unlocks advanced features. The free tier needs to be genuinely useful — apps that give users nothing for free and immediately push a subscription prompt get poor reviews and high churn.

RevenueCat Paywalls are pre-built, customizable paywall screens that integrate with RevenueCat's offering and entitlement system. Instead of building your own paywall UI and wiring it to StoreKit/Play Billing, you configure your paywall in the RevenueCat dashboard and display it with a single SDK call. The paywall screens are remotely configurable — you can change copy, pricing display, and layout without an app update. This is significant because paywall optimization (testing different copy, layout, price anchoring) is one of the highest-leverage activities for mobile SaaS revenue, and doing it without app store review cycles dramatically accelerates iteration.

Paywall A/B testing via RevenueCat Experiments lets you test different offerings (monthly vs annual emphasis, different price points, different feature lists) across randomly split user cohorts. A properly run paywall A/B test can increase conversion rate by 20-50%. The statistical significance requirements are the same as web A/B tests — you need enough conversions per variant before drawing conclusions — but RevenueCat's dashboard handles the analysis.

App Store Review Time

Plan for app store delays:

iOS App Store: 24-48 hours (first submission: up to 7 days)
Google Play Store: 3-7 days for new apps, hours for updates

This means mobile SaaS requires more planning than web SaaS — bugs can't be hotfixed instantly.

Methodology

Mobile boilerplate comparison based on direct evaluation of ShipFlutter, Very Good CLI, Expo SDK 52, and t4-app as of Q1 2026. Framework comparison based on Flutter 3.22 and React Native New Architecture (stable as of React Native 0.73). Pricing sourced from official repositories and documentation. App store policies and review times based on Apple and Google developer documentation as of Q1 2026.

For dedicated Flutter coverage see Best Flutter Boilerplates in 2026. For React Native–specific starters see Best React Native Boilerplates in 2026. Browse all mobile and SaaS boilerplates in the StarterPick directory. If you are also building a web SaaS companion alongside your mobile app, see our best SaaS boilerplates guide for the leading full-stack options.

The SaaS Boilerplate Matrix (Free PDF)