skip to content

In Flutter, when would you use flutter attach instead of flutter run, and what does attach need to find and connect to the app?

level: seniorimportance: should knowfreq 30%

answer

  1. app launched by something else
  2. add-to-app host started natively
  3. Dart VM Service URL
  4. --app-id when several advertise
  5. debug or profile, never release

basics

~20 s

Use flutter attach when the app was launched by something other than flutter run, such as a native host embedding a Flutter module. It finds the app's Dart VM Service, or waits for it, and attaches a debug session.

solid answer

~50 s

`flutter run` builds, installs, launches and connects in one step. `flutter attach` does only the last step: it connects to a Flutter app that is already running, or waits for the next one to start, by finding its **Dart VM Service**. That matters for add-to-app, where Xcode or Android Studio launches the native host that starts the Flutter module; for apps started from a native IDE; and for reconnecting after the terminal that ran `flutter run` closed. On Android and iOS a plain `flutter attach -d <device>` usually discovers the app. With several apps advertising a service, pass `--app-id` with the package name or bundle identifier, or give `--debug-url` directly. It attaches to debug and profile builds only, because release builds have no VM Service. `flutter logs` is the lighter alternative when you only need log output.

code

bash · 10 lines
bash
# add-to-app: launch the native host from Xcode or Android Studio, then:
flutter attach -d <device-id>

# several Flutter apps advertising a VM Service on one device
flutter attach -d <device-id> --app-id com.acme.shop

# known service URL, e.g. printed by the app's own log
flutter attach --debug-url http://127.0.0.1:50123/AbCdEf=/

flutter logs -d <device-id> -c   # logs only, no debug session

go deeper

for a junior

Know that flutter attach connects to an app that is already running, and flutter logs shows its output.

for a middle

Explain the VM Service that attach connects to, why release builds cannot be attached, and when to pass -d, --app-id or --debug-url.

for a senior

Run the add-to-app loop: launch the native host from its IDE, attach for Dart debugging, and diagnose attach waiting forever or picking the wrong app.

for a principal

Decide how mixed native and Flutter teams debug together, and which tool owns building and launching in an add-to-app product.

## run versus attach `flutter run` performs the whole loop: build the app, install it on the device, launch it, and connect a **debug session** to the running Dart code. That session is what enables hot reload, DevTools and the interactive console. `flutter attach` performs **only the connection**. It assumes something else launched the app and connects to it, or waits until a Flutter app starts and connects then. ## When attach is the right tool 1. **Add-to-app.** A native iOS or Android app embeds a Flutter module. You build and launch the host from Xcode or Android Studio because its native parts need those tools; then `flutter attach` connects to the Flutter engine inside it. 2. **Launched from a native IDE.** A developer starts the app from Xcode for native debugging and still wants a Flutter session. 3. **Reconnecting.** The terminal running `flutter run` was closed, but the debug build is still running on the device. 4. **Waiting for a start.** Run `flutter attach` first, then launch the app by hand or from a notification; attach connects as soon as the app's service appears. ## How attach finds the app Every debug or profile Flutter app starts a **Dart VM Service**, an HTTP and WebSocket endpoint that debuggers use. Attach needs its address, and gets it in one of these ways: | Option | Use | |---|---| | discovery (no options) | scans the device for a running or starting Flutter app | | `-d <device>` | limits the search to one device when several are connected | | `--app-id <id>` | picks the app by Android package name or iOS bundle identifier when several advertise a service; case-insensitive, and `id@device` narrows it further | | `--debug-url <url>` | connects directly to a known VM Service URL, including its auth code | | `--debug-port <port>` | deprecated; works only if the app was started with service auth codes disabled | A **release build has no VM Service**, so attach offers only debug and profile modes and cannot connect to a release app. ## What you get after attaching The same interactive session as `flutter run`: log output in the terminal, hot reload and restart keys, and a DevTools link. `--pid-file` writes the tool's process ID to a file so scripts can send signals to trigger reload and restart. How reload and restart behave is the same as under `flutter run`. ## flutter logs: output without a session - `flutter logs` streams log output of Flutter apps on the selected device, including `print` and `debugPrint` output. - `-c` / `--clear` clears the log history before reading. - Use `-d` when several devices are connected. It is useful for watching an app started elsewhere when you do not need reload or DevTools. ## Common failures - **Waiting forever** — the app is a release build, the wrong device is selected, or the host never started the Flutter engine. - **Several candidates** — pass `--app-id` or `--debug-url`. - **Wrong code** — attach does not rebuild; stale native builds show old Dart code until the host is rebuilt or you hot restart.

  • Why can flutter attach never connect to a release build?
    Attach connects through the Dart VM Service, and release builds are compiled ahead of time without it. That is why attach offers only debug and profile modes. To inspect a release build you rely on logs or native tools, not a Flutter debug session.
  • In an add-to-app project, why not just use flutter run?
    The app is the native host, built and launched with Xcode or Gradle and often needing native debugging, signing or build steps that live in those tools. `flutter run` expects to own the build of a Flutter app. Launching the host natively and attaching gives you both the native debugger and the Flutter session.

saying these in an interview costs you the question

  • Thinks flutter attach rebuilds and reinstalls the app
  • Expects to attach to a release build
  • Believes attach requires --debug-port in normal use
  • Uses flutter run for an add-to-app host that must be launched natively
  • Confuses flutter logs with a full debug session