Starting from a sample in Flutter

Starting from a sample in Flutter — 2026 edition

Back when I first wrote this, spinning up a Flutter project with Firebase integration required a fair amount of manual configuration across every platform. In 2026, the tooling has matured considerably — Flutter 3.44 is the current stable release, the FlutterFire CLI handles most of the Firebase wiring automatically, and the flutterfire configure command has replaced the old hand-editing of platform config files for the majority of cases. That said, the core workflow of starting from a Flutter sample and layering Firebase on top remains a solid approach, so this article is worth revisiting with fresh eyes.

TL:DR – This article walks through iterating towards a Flutter app that bootstraps Firebase data for a companion FlutterFlow project. The original thinking was to keep a simple Flutter app for back-end admin work and use FlutterFlow for the prettier end-user front end. In practice, that split didn't hold up — it's easier and more maintainable to build admin functionality as role-based or user-elevated capabilities directly inside FlutterFlow. All the logic lives in one place, and you get much better adherence to DRY principles. The setup steps below are still useful if you want a standalone Flutter admin app, but go in with eyes open.

What's changed in 2026

The biggest practical change since this article was first written is the FlutterFire CLI. Rather than manually downloading GoogleService-Info.plist and google-services.json, dragging files around in Xcode, and hand-editing Gradle files, you now run flutterfire configure from your project root. The CLI reads your Firebase project, detects your target platforms, and writes all the configuration files for you. It's not perfect — you still need to handle entitlements on macOS, and Xcode occasionally needs a nudge — but it eliminates the most error-prone manual steps.

Flutter 3.44 also brings improved support for agentic coding environments. Antigravity is now a supported development environment for Flutter, reflecting how much AI-assisted coding has become part of the everyday workflow. If you're starting a new project in 2026, it's worth checking whether your editor or coding assistant has Flutter-specific support baked in.

On the Android side, the old Gradle plugin syntax (apply plugin:) has been superseded by the plugins block DSL, and the minimum supported SDK guidance has moved on — targeting SDK 23 (Android 6.0) or higher is now the practical baseline, with SDK 21 considered legacy. The multidex concern that required setting minSdkVersion to 21 is largely moot for modern projects.

For web, the old CDN script tags pointing to specific Firebase JS SDK versions in web/index.html have been replaced by the modular Firebase JS SDK (v9+), and the FlutterFire web integration handles initialisation differently. The hand-written firebaseConfig block in index.html is no longer the recommended approach.

Create

You can use the command line to set up your app's parameters correctly from the start. For example:

flutter create --org uk.co.yourcompanyname --sample=widgets.Navigator.1 --description "Firebase Admin tools for YellowGreen" yellowgreenadmin

Eventually you'll be able to run the sample across all platforms, which is what the image below shows — but there's configuration work to do first. One set of source code producing Android, iOS, macOS, and web apps is genuinely worth the setup effort. Fair warning: this configuration took me about a day and a half the first time, largely because I applied it to the wrong app initially and used the wrong sample on the second attempt. Third time was the charm.

Setting up your Flutter project

Integrate Firebase

Set up Firebase to work with this Flutter app alongside the front-end FlutterFlow app you've already started. The recommended path in 2026 is to use the FlutterFire CLI rather than configuring each platform by hand.

Install the CLI if you haven't already:

dart pub global activate flutterfire_cli

Then, from your Flutter project root, run:

flutterfire configure

This command will prompt you to select your Firebase project and target platforms, then generate and place all the necessary configuration files automatically. For most setups this replaces steps 1–8 of the old iOS, Android, and web configuration sequences described below.

If you prefer to configure manually — or if the CLI doesn't cover an edge case in your setup — the platform-by-platform steps are retained below for reference.

FlutterFire dependencies

Check the current stable versions of the FlutterFire plugins at firebase.flutter.dev and add the dependencies you need to pubspec.yaml. The version numbers below are illustrative — always pull the latest stable versions from the dashboard or pub.dev at the time you're setting up:

dependencies:
  flutter:
    sdk: flutter
  cloud_firestore: ^5.0.0
  firebase_auth: ^5.0.0
  firebase_core: ^3.0.0

Note that firebase_core is now an explicit dependency rather than something that gets pulled in implicitly. The FlutterFire CLI will also add these dependencies for you if you use the automated path.

Configure the platforms for Firebase

If you ran flutterfire configure above, most of the following is handled for you. These manual steps are retained as a reference for edge cases or for those who prefer to understand what the CLI is doing under the hood.

Configure iOS and macOS to use Firebase

1. In the Firebase console, click Add App and select the iOS platform.
2. Enter your iOS bundle ID. You can find this from the organisation ID and project name you provided when creating the project, or by opening ios/Runner.xcworkspace in Xcode: open ios/Runner.xcworkspace
3. Download GoogleService-Info.plist from Firebase. Ensure the filename is exactly GoogleService-Info.plist — it may have been renamed if you've downloaded it before. Drag it into the Runner subfolder inside Xcode (not via Finder or the terminal — Xcode needs to register the file reference).
4. Click through the remaining Firebase console steps to return to the project overview.
5. For macOS, repeat the process using open macos/Runner.xcworkspace. This opens the macOS Runner — a separate workspace from the iOS one. Drag the same GoogleService-Info.plist into the macOS Runner subfolder in Xcode.
6. Add the required network entitlement to both DebugProfile.entitlements and Release.entitlements. In each file, add a Boolean row for com.apple.security.network.client and set its value to YES (true).
7. Quit Xcode. iOS and macOS configuration is complete.

Configure Android to use Firebase

1. In the Firebase console, click Add App and select Android.
2. Enter your Android package name. You can find this in android/app/src/main/AndroidManifest.xml on the package= line.
3. Download google-services.json and place it in the android/app/ directory.
4. In 2026, the recommended Gradle configuration uses the plugins block DSL. Edit your project-level android/build.gradle (or settings.gradle depending on your Gradle version) to include the Google Services plugin. Your project may already use the newer plugins block — if so, add the plugin there rather than using the legacy classpath approach.
5. In android/app/build.gradle, apply the plugin:

   plugins {
       id 'com.android.application'
       id 'kotlin-android'
       id 'com.google.gms.google-services'
   }
   

6. Set minSdkVersion to at least 23 (Android 6.0). SDK 21 is the absolute floor for Firebase on modern plugin versions, but SDK 23 is the practical current baseline and avoids compatibility warnings.
7. Android configuration is complete.

Configure a web app to use Firebase

1. In the Firebase console, click Add App and select Web.
2. Register the app and note your Firebase config object.
3. In 2026, the FlutterFire web integration initialises Firebase through Dart rather than via CDN script tags in web/index.html. The flutterfire configure command generates a firebase_options.dart file containing your configuration, and you initialise Firebase in main.dart:

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

4. If you're migrating an older project that still uses the CDN script approach in index.html, migrate to the Dart initialisation path — the legacy CDN approach is no longer recommended and may cause version conflicts.
5. Web configuration is complete.

Cocoapods — still relevant, but less painful

Flutter builds on Apple platforms still use CocoaPods, though the process is more stable than it used to be. The main thing to be aware of is keeping your deployment targets consistent.

macOS

Update the platform target in macos/Podfile. Current Firebase plugins require macOS 10.14 or later — check the specific requirement for the plugin versions you're using:

platform :osx, '10.14'

Open macos/Runner.xcodeproj in Xcode and set the Deployment Target under the Runner target's General tab to match.

iOS

Current Firebase plugins require iOS 13.0 or later. Update ios/Podfile accordingly:

platform :ios, '13.0'

Open ios/Runner.xcodeproj in Xcode and set the Deployment Target to 13.0 or later. If you've attempted a build before making this change, run flutter clean followed by pod repo update to clear any cached state.

Where you end up

Once all platforms are configured, you have a single Flutter codebase producing Android, iOS, macOS, and web applications — all connected to Firebase. The first time you get all four running cleanly, it feels disproportionately satisfying for what is ultimately a configuration exercise. As a former colleague once said of getting his first print job working after a week of effort: "I learned a lot." The sentiment holds.

At this point you'll have multiple registered apps in your Firebase console — an admin Flutter app and a FlutterFlow app, each with iOS, Android, and web entries. That's a solid foundation from which to add Firebase CRUD functionality.

One honest reflection looking back: the premise of maintaining a separate Flutter admin app alongside a FlutterFlow front-end app turned out to be more friction than it was worth. Role-based admin functionality built directly into FlutterFlow keeps all the logic in one place and is far easier to maintain. If you're starting fresh in 2026, consider whether a separate admin app is genuinely necessary before committing to such a dual-app architecture.