IntelliJ IDEA

IntelliJ IDEA only enters the picture once you have the Flutter source code on your local machine — and that code comes from FlutterFlow's code export, which requires the Pro plan ($70/mo). If you're on Free or Standard, open your FlutterFlow account settings and upgrade first. Once on Pro, you have two export paths. The first is Download Code: in your FlutterFlow project, look for the Download Code button in the top toolbar (the exact icon varies by FlutterFlow version, but it's usually near the Publish/Deploy controls). Click it and FlutterFlow downloads a ZIP file of the entire Flutter project. Unzip it to a folder on your machine — somewhere stable like ~/Projects/my-app-flutter. The second path is the GitHub integration: if you've connected FlutterFlow to GitHub (Settings → Integrations → GitHub) and pushed at least once, you can clone the GitHub repo to your machine using git clone with the repo URL. The GitHub path is better for ongoing development because you can pull new FlutterFlow exports without downloading and unzipping each time. For a first-time setup, either path works — use the ZIP if you haven't set up GitHub yet. After export or clone, confirm you can see the standard Flutter project structure in the folder: pubspec.yaml at the root, lib/ containing main.dart and screen files, android/, ios/, and web/ directories.

Open IntelliJ IDEA. Before opening the project, you need the JetBrains Flutter and Dart plugins installed. Go to IntelliJ IDEA menu → Settings (or Preferences on macOS) → Plugins. In the Plugins dialog, click the Marketplace tab and search for 'Flutter'. You'll find the Flutter plugin published by JetBrains — click Install. IntelliJ will tell you that Flutter requires the Dart plugin and offer to install both together — accept. After installation, click 'Restart IDE' to activate the plugins. When IntelliJ restarts, the status bar at the bottom will now include a device selector (shows 'No devices' until you configure a device or emulator). You may also see a notification asking you to set the Flutter SDK path — click it, or navigate to Settings → Languages & Frameworks → Flutter and set the 'Flutter SDK path' to the directory where you installed the Flutter SDK (e.g. /Users/yourname/flutter or C:\flutter). IntelliJ uses this path to find the flutter executable, the Dart SDK bundled inside it, and the flutter pub command for resolving dependencies. If you installed Flutter from flutter.dev and added it to your PATH, IntelliJ can often detect it automatically — look for a green checkmark next to the path field confirming detection.

In IntelliJ IDEA, go to File → Open and navigate to the root of your exported Flutter project folder — the one containing pubspec.yaml. Select that folder (not a file inside it) and click OK. IntelliJ will detect it as a Flutter project and offer to run pub get — click 'Get dependencies' when prompted, or if not prompted, open the Terminal panel at the bottom of IntelliJ and run the pub get command manually. This step downloads all the pub.dev packages that FlutterFlow's generated code depends on — things like supabase_flutter, firebase_core, go_router, and any custom action dependencies you've added. Pub get may take 1–3 minutes on a fresh install. While it runs, IntelliJ's Dart analysis engine starts indexing the project — you'll see 'Indexing...' in the status bar. Wait for indexing to complete before running the app. If you see red error underlines in main.dart immediately after opening, they usually resolve once pub get and indexing finish. After pub get succeeds, check the Gradle side for the Android target: in the right side panel, look for the Gradle tool window (or go to View → Tool Windows → Gradle). If Gradle shows a sync needed, click 'Sync Now'. Gradle downloads the Android build dependencies — this can take several minutes the first time. A successful Gradle sync shows a green checkmark in the Build output.

With the project open and dependencies resolved, you're ready to run the app on a local emulator or connected device. For an Android emulator, open the Device Manager in IntelliJ (View → Tool Windows → Device Manager, or the phone icon in the right toolbar). Click 'Create Virtual Device', choose a phone model (Pixel 6 is a good default), select a system image (download one if not available — choose a recent Android API level, e.g. API 34), and click Finish. The AVD (Android Virtual Device) appears in the device list — click the green play triangle to start the emulator. Once the emulator boots and shows the Android home screen, select it in IntelliJ's device dropdown in the top toolbar. Now click the green Run button (or press Shift+F10 on Windows/Linux, Control+R on macOS) to build and launch the FlutterFlow app on the emulator. The first build compiles the Dart code to native Android — this takes 1–3 minutes. Subsequent runs use hot reload (press 'r' in the Run console, or click the lightning bolt icon) which injects code changes in under a second without losing app state. For iOS simulation on macOS, you need Xcode installed — open the Device Manager and choose an iOS Simulator instead. Use hot reload extensively while debugging custom actions: edit the Dart file in IntelliJ, save, and the emulator updates almost instantly.

The primary reason to use IntelliJ over FlutterFlow's browser-based editor is debugging capability. FlutterFlow's Local Run preview is useful for basic UI testing, but it cannot hit breakpoints in Dart code, inspect variable values at runtime, or surface platform channel errors clearly. IntelliJ can do all of these. To set a breakpoint, open a file in lib/custom_code/actions/ (your custom Dart files), click in the gutter to the left of a line number — a red dot appears. Run the app in Debug mode (Shift+F9 on Windows/Linux, Control+D on macOS, or use the bug icon instead of the play button). When the app hits the breakpoint, execution pauses and you can inspect the call stack, hover over variables to see their runtime values, and step through code line by line using F8 (step over) and F7 (step into). Common issues to debug this way: incorrect API response parsing in a custom action that calls a third-party API, null reference exceptions when a widget binds to a data field that hasn't loaded yet, and MissingPluginException errors that mean a pub.dev package's native platform code wasn't linked correctly in the Android build. For Gradle-level Android build errors — like version conflicts between FlutterFlow's generated Gradle config and your local Android Gradle Plugin — open the Gradle tool window, expand the Tasks tree, and look at the build output. IntelliJ shows the full Gradle error stack with clickable file links, which is far more actionable than a generic terminal error.

1// Example: custom action in lib/custom_code/actions/send_push_notification.dart
2// Breakpoint here to inspect the payload before the API call
3import 'dart:convert';
4import 'package:http/http.dart' as http;
5
6Future<bool> sendPushNotification({
7  required String deviceToken,
8  required String title,
9  required String body,
10}) async {
11  // Set a breakpoint on the line below to inspect deviceToken at runtime
12  final payload = json.encode({
13    'to': deviceToken,
14    'notification': {'title': title, 'body': body},
15  });
16
17  // Note: this calls a server proxy — never put FCM server key here.
18  // The actual key lives in your Firebase Cloud Function.
19  final response = await http.post(
20    Uri.parse('https://your-project.cloudfunctions.net/sendNotification'),
21    headers: {'Content-Type': 'application/json'},
22    body: payload,
23  );
24
25  return response.statusCode == 200;
26}

The final and most important step is deciding how changes flow between your IntelliJ session and FlutterFlow. There are two valid strategies. Strategy A — FlutterFlow as source of truth (recommended for most founders): all screen and logic work happens in FlutterFlow's browser editor. IntelliJ is read-only for generated files — you open it to debug, run, and review, but you never save changes to `lib/pages/` or `lib/app_state.dart`. When you need to add custom Dart logic, you write it in FlutterFlow's Custom Code panel (left nav → Custom Code), test it with FlutterFlow's Local Run, then export a new ZIP or push to GitHub to get the updated code in IntelliJ. Strategy B — Frozen fork (for developers who have outgrown FlutterFlow's editor): you export once from FlutterFlow, then treat the exported project as the new source of truth. You never push from FlutterFlow again — all future development happens directly in IntelliJ on the exported Dart code. This is a one-way door: you lose the visual FlutterFlow editor but gain full Dart codebase control. Most non-technical founders should stay with Strategy A. One universal rule for both strategies: never hardcode API keys, Firebase credentials, or any secret in Dart files, even temporarily for local testing. The same Dart file that runs in IntelliJ ships to users — use App State variables that read from a backend call, or route secret operations through a Firebase Cloud Function. A key in a Dart file is a key in the compiled binary that anyone can extract.