June 24, 2026

Why we still pick Flutter + Firebase + AdMob for new mobile apps in 2026

Everyone keeps asking why we haven't moved to React Native or native SwiftUI. Here's the honest stack math after shipping a dozen apps on Flutter, Firebase, and AdMob.

KEY TAKEAWAYS

↳Flutter still ships one codebase to iOS and Android without the 'last 10%' tax we kept paying on React Native.
↳Firebase Auth plus Firestore plus Crashlytics covers about 80% of what a small app needs before you write any backend.
↳AdMob is boring and that is the point: it pays out, the SDK works, and mediation is sane in 2026.
↳The stack breaks down past roughly 100k DAU or when you need real relational queries, and that is fine to plan for later.

Last month a founder asked me, half accusing, why we were still building his app in Flutter. “Isn’t everyone on React Native now? Or Expo? Or that new Apple thing?” I get the question a lot. It usually comes from someone who read three Twitter threads and now thinks Flutter is over.

It isn’t. We’ve shipped roughly a dozen mobile apps over the last two years on Flutter + Firebase + AdMob, and the stack keeps winning the boring fight: time from kickoff to App Store review, cost per bug fix, and how much of the team I need to keep on payroll after launch. Here’s the actual math.

One codebase, and I mean one

Flutter compiles to native ARM for both platforms and renders its own widgets with Skia (now Impeller on iOS). The thing people miss is what that actually buys you in week six of a project, when the client wants to change the bottom nav from four tabs to five and add a long-press menu on the cards.

On Flutter, that’s one PR. One review. One QA pass on a Pixel 7 and an iPhone 14. Done in an afternoon.

On React Native, even with Expo Router, we kept paying what I started calling the last 10% tax. The Android keyboard behaves differently. The iOS swipe-back gesture fights your stack navigator. Some native module is on 0.72 and the rest of the app moved to 0.74. None of these are fatal. They just bleed two days here, three days there, and a senior dev’s patience.

Flutter has its own version of this. Platform channels are annoying. Dart isn’t TypeScript and never will be. But the surface area of “things that behave differently between iOS and Android” is genuinely smaller, because Flutter draws its own pixels.

Firebase is the backend you already have

For a new app, the realistic backend needs are: auth, a database, file storage, push notifications, crash reporting, and analytics. Firebase gives you all six in an afternoon.

Auth handles Google, Apple, email/password, and phone. Firestore is a document store that I have mixed feelings about, but it scales to the size of app where you would have outgrown your first backend anyway. Cloud Storage is fine. FCM is the push system Android uses natively, so you save a hop. Crashlytics is still the best crash reporter I’ve used, including paid ones. Analytics is free and pipes into BigQuery if you want SQL later.

A typical setup looks like this:

final app = await Firebase.initializeApp(
  options: DefaultFirebaseOptions.currentPlatform,
);

FirebaseAuth.instance.authStateChanges().listen((user) {
  if (user == null) return;
  FirebaseAnalytics.instance.setUserId(id: user.uid);
  FirebaseCrashlytics.instance.setUserIdentifier(user.uid);
});

That’s auth, analytics, and crash attribution wired together in ten lines. If I tried to do the equivalent on a custom Node + Postgres + Sentry + OneSignal stack, I’m losing two days minimum and adding four services to the bill.

The trade is real: Firestore’s query model is limited (no real joins, composite indexes you have to remember to deploy), and costs can surprise you if you let a client do unbounded list views. We had one app, a small social thing, where a single buggy stream subscription burned about $80 in reads in a weekend before we caught it. So we now wrap every Firestore stream in a debounced provider and cap page sizes at 20. Lesson paid for, lesson learned.

AdMob still pays

If the app is consumer and free, ads are usually the model. I’ve watched founders try Unity Ads, IronSource, AppLovin MAX, and a few smaller networks. The honest summary: AppLovin MAX has higher eCPMs on some geos, but AdMob’s SDK is the one that doesn’t break on a Flutter upgrade and the one Google actually pays on time.

A utility app we shipped in Q1 2024 has been running native ads on the result screen and interstitials on the home-to-detail transition. eCPM bounces between $4 and $11 in Tier 1, lower elsewhere, which sounds modest until you remember the entire monetization integration was about 200 lines of Dart and the google_mobile_ads plugin.

For anything subscription-shaped we add RevenueCat on top of StoreKit and Play Billing. RevenueCat’s Flutter SDK is good enough that I haven’t had to read the iOS receipt validation docs in two years, which is a gift.

What the stack does not do well

I’m not pretending this is the right pick for everything.

If your app is a thin shell over a complex existing web app and your team is five React developers, use React Native. You’ll move faster on familiar ground than on Dart.

If you need tight Apple-only integrations (Live Activities, complex Widgets, CarPlay, App Intents), SwiftUI native is still the path of least pain. Flutter has packages for some of this, and they range from “fine” to “abandoned in 2023.”

If you’re past 100k DAU with heavy relational queries, Firestore will hurt. We’ve migrated two apps off Firestore onto Postgres + a small Go API on Hetzner once they crossed that line, and both times it took about three weeks and was worth it. Plan for it, don’t dread it.

And Firebase’s pricing past a certain scale gets silly. Cloud Functions cold starts, the new Data Connect product that I still don’t fully trust, Hosting bandwidth that’s more expensive than Cloudflare by a wide margin. We move static assets to Cloudflare R2 + Workers basically by default now, even on Firebase projects.

What an actual kickoff looks like

When a client signs for a new app, day one looks like this:

flutter create with our internal template (Riverpod, GoRouter, Freezed, our analytics wrapper).
Create the Firebase project, enable Auth, Firestore, Storage, Crashlytics, Analytics, Remote Config.
Wire flutterfire configure.
Set up two flavors (dev, prod) with separate Firebase projects so a dev test doesn’t pollute prod analytics.
Add AdMob test IDs from day one. Real IDs only at the App Store submission step.
App icons and splash via flutter_launcher_icons and flutter_native_splash. Twenty minutes.

By end of day one we have a running app on both simulators with auth, a placeholder home screen, and crash reporting. By end of week one there’s usually a TestFlight build.

That speed is the whole argument. The stack isn’t novel. It isn’t going to get a conference talk. It just ships apps that work, on a budget a small business can actually pay.

If you’ve got a half-built mobile app sitting in a repo, or you want to start one and not eat 18 months of stack debate first, come talk to us.

FREQUENTLY ASKED

Common questions

▸Why not just use Expo + React Native in 2026?

Expo is genuinely good now and if your team already writes React, use it. We don't, and we've measured the difference: on identical scope projects, our Flutter builds finish QA roughly 20% faster because we hit fewer iOS-vs-Android edge cases. The deciding factor for us is team skill, not framework hype. Pick the one your senior devs already know.

▸Isn't Firestore too limited for a real app?

For most apps under 100k DAU, no. The limits people complain about (no joins, eventual consistency on some queries, composite index management) matter when you're doing analytics-style queries on hot data. For typical user-scoped reads and writes, Firestore handles it. When an app outgrows it, we migrate to Postgres on Hetzner with a small Go or Node API. Plan the exit, don't avoid the start.

▸How much does this stack actually cost per month for a small app?

For an app under 10k MAU, Firebase usually runs $0-$30/month (most of it stays in the free Spark tier). AdMob costs nothing. Apple Developer is $99/year, Google Play is a one-time $25. RevenueCat is free up to $2.5k MTR. So under $50/month all-in until you have meaningful traction, which is exactly when more cost is a good problem.

▸What about iOS-only features like Live Activities or App Intents?

Flutter packages exist for some of these and they're hit or miss. If those features are core to the product, we either write a thin native iOS module and bridge through platform channels, or recommend going SwiftUI native. We've done both. For a meditation app that needed Live Activities, native iOS was the right call. For most apps, the Flutter packages cover enough.

▸Will Flutter still be supported in five years?

Honest answer: I don't know, and neither does anyone else. Google has shrunk the Flutter team and there's been real concern in the community since 2024. That said, the framework is stable, open source, and used by enough big apps (Alibaba, BMW, Nubank) that it isn't going to vanish. We'd bet on five more years. Past that, code is code, and a rewrite in whatever wins is a known cost.

SOURCES

[1]
google_mobile_ads Flutter packagepub.dev
[2]
Firebase pricingfirebase.google.com
[3]
Flutter Impeller rendering enginedocs.flutter.dev
[4]
RevenueCat Flutter SDKrevenuecat.com

5/23/2026