Visual Studio Code

Code export is a Pro-plan feature in FlutterFlow. If your project is on the Free or Standard ($30/month) plan, navigate to your account settings and upgrade to Pro ($70/month). Once on Pro, open your FlutterFlow project. Look for two export paths in the top toolbar: the Download Code button (looks like a download arrow or is labeled under the top-right menu) lets you download a ZIP of the entire Flutter project right now. Alternatively, click the GitHub icon in the top-right toolbar to connect FlutterFlow to a GitHub repository — this lets you push your project to GitHub with a click, which is the better workflow for ongoing development because it keeps a clean git history. For first-time setup, choose whichever feels more comfortable; you can switch later. If you already have a GitHub integration set up from the GitHub settings (Settings → Integrations → GitHub), you'll see a Push to GitHub button that commits your current FlutterFlow state to the connected repository. Either way, trigger the export now so you have the Flutter project files ready for the next step.

If you downloaded a ZIP, unzip it to a folder on your computer — for example, `~/Projects/my-flutterflow-app/`. If you used GitHub, open a terminal and clone the repository: navigate to your GitHub repo, copy the HTTPS clone URL, and clone it to your Projects folder. Once the folder exists on disk, open VS Code. Go to File → Open Folder, navigate to the folder you just unzipped or cloned, and click Open. VS Code will open the project. You should immediately see the familiar Flutter project structure in the Explorer panel on the left: `pubspec.yaml` at the root, a `lib/` directory containing all the Dart files FlutterFlow generated, plus `android/`, `ios/`, and `web/` directories for platform-specific code. If VS Code shows a popup asking to install recommended extensions, that is the Flutter/Dart prompt — click Install. If that popup doesn't appear, proceed to the next step to install the extensions manually. Do not rename or move any of these folders — the Flutter build system expects this exact structure.

The Flutter and Dart extensions are what turn VS Code from a plain text editor into a full Flutter IDE. Both are published by Dart-Code (publisher ID: Dart-Code) and are free. To install them, click the Extensions icon in the left sidebar (it looks like four squares, or press Cmd+Shift+X on Mac / Ctrl+Shift+X on Windows). In the search box type "Flutter" — you'll see the Flutter extension by Dart-Code at the top of the results. Click Install. This extension automatically installs the Dart extension as a dependency, so you get both in one click. After installation VS Code will prompt you to reload the window — do so. Once reloaded, VS Code needs to know where your Flutter SDK is installed. If Flutter is on your PATH (you ran `flutter doctor` successfully in a terminal before), VS Code will find it automatically and you'll see the Flutter SDK path in the bottom-left status bar. If VS Code shows a banner saying "Couldn't locate the Flutter SDK" or asks you to point it to the SDK, click the banner and browse to the folder where you installed Flutter (e.g., `~/development/flutter`). Once the SDK is located, the status bar at the bottom of VS Code will show a device selector — you can click it to pick a simulator or connected device.

FlutterFlow's exported project comes with a `pubspec.yaml` that lists all the packages your app depends on (things like `cloud_firestore`, `google_fonts`, and any custom packages you added in FlutterFlow's Custom Code dependencies). Before you can run the app, VS Code needs to download these packages. VS Code usually does this automatically when you open a Flutter project — you'll see a progress indicator in the bottom-right saying "Fetching packages" or similar. If it doesn't happen automatically, open the Command Palette (Cmd+Shift+P on Mac / Ctrl+Shift+P on Windows), type "Flutter: Get Packages", and press Enter. This is the equivalent of running `flutter pub get` and may take a minute on first run. Once packages are fetched, open the Run and Debug panel in the left sidebar (the play button with a bug icon) or press F5. VS Code will ask you to select a device if you haven't already — pick your iOS Simulator, Android Emulator, or a connected physical device from the device selector in the status bar. Press the green play button or F5 to build and launch. The app will appear on the simulator. After the first launch, you can use hot reload (press the lightning bolt button in the debug toolbar, or Cmd+S saves will trigger it automatically) to see code changes instantly without a full restart.

Now that the app is running locally, you can edit Dart code in VS Code. The key distinction is WHICH files are safe to edit. FlutterFlow generates the majority of files in `lib/` — pages, widgets, routes, theme — and will overwrite them on every export. The files that belong to you and survive re-exports are the custom action files and custom widget files you create in FlutterFlow's Custom Code section. FlutterFlow places these in dedicated subfolders (typically `lib/custom_code/actions/` and `lib/custom_code/widgets/`) and explicitly avoids regenerating them. In VS Code, you can freely edit any file under `lib/custom_code/` — add logic, import pub.dev packages, add null checks, whatever you need. When you're happy with the changes, copy the updated Dart code back into the FlutterFlow editor (Custom Code panel → paste into the code editor there) so the next export from FlutterFlow will include your version. For generated files like pages and components, edit them locally only for quick debugging — never expect those edits to persist after the next FlutterFlow export. If you want to permanently keep changes to a generated file, stop exporting from FlutterFlow and manage the codebase in VS Code entirely (the "frozen fork" strategy).

1// Example: a custom action in lib/custom_code/actions/calculate_discount.dart
2// This file is safe to edit in VS Code — FlutterFlow won't overwrite it.
3import 'package:flutter/material.dart';
4
5// ignore_for_file: unnecessary_this
6
7Future<double> calculateDiscount(
8  double originalPrice,
9  int userTierLevel,
10) async {
11  // Tier discounts: 0=none, 1=10%, 2=20%, 3=30%
12  final discountRates = {0: 0.0, 1: 0.10, 2: 0.20, 3: 0.30};
13  final rate = discountRates[userTierLevel] ?? 0.0;
14  final discountedPrice = originalPrice * (1 - rate);
15  // Clamp to avoid negative prices
16  return discountedPrice.clamp(0.0, originalPrice);
17}

Before wrapping up, make a conscious decision about how you will manage the two-way tension between FlutterFlow (which owns the generated code) and VS Code (where you do local editing). There are two clean strategies. Strategy 1 — FlutterFlow as source of truth: you use FlutterFlow for all visual edits and only touch `lib/custom_code/` in VS Code. Every FlutterFlow export updates the generated files, and your custom code files are preserved because FlutterFlow skips them. This is the recommended approach for most teams. Strategy 2 — Frozen fork: you export from FlutterFlow once, immediately stop using FlutterFlow's export, and manage the entire Flutter codebase in VS Code going forward. You lose the visual builder benefits but gain full code freedom. This makes sense when FlutterFlow's generated patterns become limiting — for example, if you need to restructure state management or add a complex platform plugin that FlutterFlow can't accommodate. Whichever strategy you choose, document it in a README in the repository so collaborators know the rules. A mixed approach (editing generated files in VS Code AND continuing to export from FlutterFlow) is the one strategy that doesn't work — it leads to silent overwrites and lost work.