flutter-intellij: Flutter plugin for IntelliJ and Android Studio with hot reload

A Flutter development environment inside IntelliJ IDEA and Android Studio

Flutter is a multi-platform app SDK for building iOS, Android and web apps, and this plugin brings its tooling into JetBrains IDEs. Without it, Flutter development requires using the CLI from a terminal alongside whatever editor the developer prefers. The plugin adds IDE-native integration: hot reload triggered from within the IDE, run configurations and access to Flutter SDK commands from the IDE interface.

The plugin targets both IntelliJ IDEA (Community and Ultimate editions) and Android Studio, which are the two JetBrains IDEs that Flutter's official documentation directs developers to for IDE-based work. The project's homepage at docs.flutter.dev/tools/android-studio is hosted on Flutter's own documentation site, making this an official part of the Flutter toolchain rather than a third-party addition.

flutter-intellij is BSD-3-Clause licenced, has no GitHub releases (all builds are distributed through the JetBrains plugin marketplace), and was last pushed on 2026-10-05.

The repository is maintained by the Flutter organization itself on GitHub. The issue tracker splits three categories: Flutter IntelliJ issues go to this repository's tracker, general Flutter issues go to the Flutter core tracker, and Dart IntelliJ issues go to a separate tracker for that plugin.

Hot reload updates the running app without resetting application state

Hot reload is the central feature. Flutter's hot reload delivers sub-second reload times without losing state, working across emulators, simulators and physical hardware for both iOS and Android. Sub-second turnaround means a layout change appears in the running app before a developer would finish typing a terminal command.

'Without losing state' is the part that matters for iterating on UI code. Restarting an app to see a color change means navigating back to the target screen each time. With hot reload, the change goes into the running app and the screen stays exactly where it was, so a developer can adjust a padding value, trigger reload and see the result immediately without navigation overhead.

The plugin's role is to expose the hot reload trigger in IntelliJ's own UI. A button or keyboard shortcut replaces a command typed in a terminal. The technical implementation behind the reload lives in the Flutter SDK itself; the plugin is an IDE wrapper that connects the IDE to that mechanism.

The project's getting started guide lives at docs.flutter.dev/tools/android-studio rather than in the repository README, so the README's quick start section is a summary, not the complete reference.

Install requires flutter doctor, the JetBrains Marketplace and an SDK path

Installation starts with the Flutter SDK, not the plugin. Before opening the IDE, verify that Flutter is installed and the PATH is correct:

flutter doctor

This command checks the Flutter installation and reports problems that would prevent the plugin from finding the SDK. Once Flutter is verified, open the plugin preferences inside the IDE, at `Preferences > Plugins` on macOS or `File > Settings > Plugins` on Linux. From there, select "Browse repositories..." and search for the 'Flutter' plugin in the JetBrains marketplace. After installing, choose the option to restart the IDE.

After the restart, configure the Flutter SDK path. On macOS, go to `Preferences`, then `Languages & Frameworks > Flutter`, and set the path to the root of the Flutter repository. On Linux, the starting point is `File > Settings` instead.

The plugin has no install command of its own. All installation happens through IDE menus and the JetBrains marketplace UI. The only command-line step in the quick start is `flutter doctor`.

A supported IDE is required before installing the plugin: either the latest stable IntelliJ IDEA (Community or Ultimate) or the latest stable Android Studio. Pre-release IDE builds carry specific caveats covered in the section below.

EAP and Canary IDE builds are documented as unreliable targets

The quick start requires a stable IDE for a reason. IntelliJ EAP (Early Access Program) builds are noted as not always supported. That qualifier is meaningful: the plugin sometimes works with EAP builds and sometimes does not. No curated list of EAP-specific failures exists in the known issues section, so there is no way to predict which EAP features trigger incompatibilities.

For Android Studio, the restriction is stricter. Canary builds are generally not supported, which is a stronger statement than 'not always.' Android Studio ships Canary builds on a frequent cadence as its development channel, and this plugin treats them as an unreliable target.

A developer who wants to stay current with IDE features while relying on the Flutter plugin must choose between EAP or Canary access and plugin stability. Staying on stable IDE builds is the only configuration the project documents as supported.

The known issues section does not document specific EAP or Canary failures. Testing on the specific EAP or Canary build in use is the only way to find out whether the combination works, and that check needs to be repeated after each new EAP or Canary update.

A compatibility table covers five SDK ranges with three undocumented gaps between them

A compatibility table in the repository README maps Flutter SDK version ranges to the plugin generations required for each. Five rows span from the earliest documented SDK cutoff through the current active range.

Reading the rows in sequence shows three SDK ranges that no row covers: between v3.7.12 and v3.10.0, between v3.10.6 and v3.13.0, and between v3.13.9 and v3.16.0.

A Flutter upgrade that lands within one of those undocumented ranges leaves a developer without a specific plugin recommendation from the table. The table does not indicate whether to use the row above or the row below for SDK versions that fall in a gap. The README points to docs.flutter.dev/tools/sdk#sdk-support-for-flutter-developer-tools as the reference for SDK support questions beyond what the table shows.

Plugin builds are distributed through the JetBrains plugin marketplace, not through GitHub. There are no repository tags to correlate plugin behavior with source commits, which makes it harder to bisect a regression to a specific change.

PATH is read once at IDE startup, and proxies require https_proxy set before launch

Two failure modes are documented in the known issues section, each with an issue tracker reference.

The first is documented as issue 601: IntelliJ reads the PATH variable once when it starts. If Flutter is added to PATH after the IDE is already open, IntelliJ does not detect the change. Flutter-related commands fail until the IDE restarts. This catches developers who install Flutter while the IDE is running, or who update a shell configuration file and expect the running IDE to pick up the change immediately.

The PATH is frozen at whatever state it had when IntelliJ launched. Project reload and settings refresh do not re-read PATH. A full IDE restart is the only fix.

The second failure mode is issue 2914: environments that require outbound traffic to go through a proxy must set the `https_proxy` variable before launching IntelliJ. The README points to dart.dev/tools/pub/troubleshoot#pub-get-fails-from-behind-a-corporate-firewall for the configuration details. Proxy settings inside IntelliJ's own settings UI are separate from this requirement.

Both failures require an environment-level fix. Neither has a workaround that can be applied from inside IntelliJ after the IDE is already running.

The dev channel ships daily builds and the repository includes AI coding skills for contributors

Developers who want access to new plugin features before a stable build can use the dev channel. It draws from the main branch daily, with minimal testing. That phrasing sets an honest expectation: daily cadence means faster access to changes, and minimal testing means no formal QA pass between a commit landing and a build going out. Setup instructions live at docs/Dev-Channel.md in the repository.

The repository also includes custom automation skills for AI coding agents, located in the .agents/skills/ directory. The README names Gemini Code Assist and Antigravity as the primary targets. Eleven skills are listed, covering unit test addition, accessibility audit, dependency audit, UI thread safety audit, code inspection cleanup, unused asset cleanup, code review, repository context loading, IntelliJ util migration, removal of outdated platform support and plugin publishing workflows. Each skill is a SKILL.md file that an agentic workflow can load and execute.

A CLAUDE.md file is also present at the top level, alongside the .agents/ directory, which indicates that the project has been configured for at least two separate AI coding platforms.

These automation tools are for contributors building and maintaining the plugin, not for end users of the plugin in their own Flutter projects.

Editorial conclusion

flutter-intellij suits Flutter developers working in IntelliJ IDEA or Android Studio who want hot reload, run controls and Flutter Doctor integration inside the IDE. Teams that update the Flutter SDK regularly should check the compatibility table before each upgrade, because three SDK ranges in the table are undocumented and docs.flutter.dev/tools/sdk is the reference for those gaps. Developers on EAP IntelliJ or Android Studio Canary builds should confirm plugin compatibility before committing to those IDE versions, since EAP support is not guaranteed and Canary support is generally excluded.

Frequently asked questions

Official sources

1. flutter/flutter-intellij on GitHub
2. Issues
3. License: BSD-3-Clause
4. Project website
5. README