Flutter and Dart command and concept reference

Purpose. Reports Flutter framework, engine, Dart SDK, and related tool versions.

When to use it. At project start, in failure reports, and before comparing results across developer machines or CI.

What to record. Channel, Flutter version, and Dart version. A reproducible application declares its toolchain, not only package dependencies.

Purpose. Inspects the installation and checks whether toolchains for known targets are available. It can evaluate Flutter SDK, Android SDK, Xcode on macOS, browsers, IDEs, and devices.

How to read it. ✓ means a check passed; ! calls for attention or indicates incomplete setup; ✗ marks a failure. An iOS warning does not block a course targeting only Android and web.

Useful variant. flutter doctor -v shows paths, versions, and details that help uncover duplicate SDKs or a wrong environment variable.

What it doesn’t do. It does not install or automatically fix every dependency. Interpret diagnostics against the platforms you actually intend to ship.

Practice. Run the verbose form and classify every non-✓ result as target blocker, optional improvement, or irrelevant for now.

Purpose. Displays or changes persistent Flutter CLI configuration, including platform enablement and paths supported by the installed version.

Caution. Global configuration affects other projects on the machine. Run flutter config without arguments and record the previous state before changing it.

Purpose. Lists connected targets Flutter can use, including name, identifier, and platform.

Common use. Copy an identifier and run flutter run -d <deviceId>. If a device is missing, verify connection, authorization, drivers, USB debugging, or browser availability.

Purpose. Lists configured emulators and can start one through flutter emulators --launch <emulatorId>.

Important distinction. An emulator is a registered virtual environment; a device is a target currently available to run. After launch, confirm it with flutter devices.

Purpose. Generates a Flutter application structure and resolves dependencies by default.

What to inspect. pubspec.yaml, lib/main.dart, test/, and platform folders. Shared code does not remove native integration points.

Decision. Read flutter create --help before choosing platforms, organization identifier, or template. Changing package identifiers later can affect signing, Firebase, and publishing.

Expected output. The directory is created, dependencies resolve, and the CLI prints next steps. Read the output instead of treating it as noise.

Purpose. Builds and runs the application on a device while keeping a development session attached.

Default mode. It generally runs in debug with asserts, VM service, and Hot Reload. This mode favors diagnosis; it does not represent production performance or size.

During the session. r requests Hot Reload, R requests Hot Restart, and q quits. Hot Reload injects updated code and rebuilds the tree but might not reapply initializers or native changes.

Common failure. Multiple available devices without explicit selection. Use flutter devices and -d to make the target predictable.

Purpose. Connects Flutter tools to an engine already running. This helps in add-to-app scenarios or when the native host started the application.

Don’t confuse them. run starts and follows an app; attach finds an existing execution.

Purpose. Resolves pubspec.yaml constraints, downloads missing packages, and materializes the resolution in a lockfile where appropriate.

When to run it. After changing dependencies or checking out a revision whose lockfile changed. For Flutter apps, prefer flutter pub over dart pub because the Flutter CLI includes Flutter SDK constraints.

Don’t confuse them. get honors the available resolution and lockfile; upgrade searches for newer versions allowed by constraints and can change the lockfile.

Purpose. Adds a dependency to pubspec.yaml and resolves packages.

Before adding it. Review maintenance, supported platforms, license, security history, API, and integration cost. Popularity is not technical evaluation.

Purpose. Compares current, upgradable, resolvable, and latest versions. It separates “a new release exists” from “current constraints can accept it.”

Responsible use. Update in small groups, read changelogs, and run analysis, tests, and a smoke test. An updated package does not mean a validated application.

Purpose. Generates localization classes from project configuration and ARB files.

Common failure. Missing keys, incompatible placeholders across languages, or divergent configuration. Never hand-edit generated files; fix the source and generate again.

Purpose. Runs static analysis through the Dart analyzer and analysis_options.yaml. It finds type errors, invalid usage, warnings, and lints without running the app.

How to read it. Inspect file, line, severity, diagnostic code, and message. Fix the cause; don’t silence a rule only to make CI green.

Limit. Static analysis does not prove behavior, integration, or experience. It complements tests and review.

Purpose. Runs Dart and Flutter tests in the package. It can receive a file, directory, name, and platform options.

Variants. flutter test --coverage produces coverage data; flutter test test/products/ narrows the loop during development.

Expected output. Test count and final result. A flaky test remains a failure: repeating it until green does not fix the cause.

Purpose. Follows logs from Flutter applications on connected devices.

Caution. Logs can expose personal data, tokens, and payloads. Redaction belongs in code; clearing a terminal does not remove exposure from remote observability.

Purpose. Produces an artifact for a target such as appbundle, apk, ipa, web, windows, macos, or linux when supported by host and project.

Release is not publishing. The command creates artifacts; signing, distribution, store review, rollout, and post-release observation are separate stages.

Before building. Confirm environment, configuration, version, signing, secrets, analysis, and tests. Record the produced artifact path and hash.

Purpose. Installs a Flutter app on a connected device. It helps validate an artifact or a run closer to distribution.

Limit. Successful installation does not prove startup, migration, sign-in, or critical journeys; run a smoke test afterward.

Purpose. Removes build output and build-system generated files to force reconstruction.

When to use it. When evidence points to stale cache or inconsistent intermediate artifacts, especially after deep toolchain or native configuration changes.

When to avoid it. Don’t make clean the first response to every error. It slows the next build and can hide a problem you still don’t understand.

Purpose. Updates Flutter SDK on the current channel.

Caution. The toolchain is a project dependency. Upgrade through a controlled change, read release notes, record versions, and run full validation. Don’t silently upgrade midway through diagnosis.

Runs a Dart program, project script, or executable supplied by a dependency. Arguments after the target reach main(List<String> args).

Use --enable-asserts when you need asserts in a context that doesn’t enable them by default. To observe a command-line program with DevTools, explore dart run --observe.

Formats files through the official formatter. Formatting removes style debates; it does not replace code review.

In CI, dart format --output=none --set-exit-if-changed . checks without rewriting and fails when it finds drift.

Analyzes a Dart package without Flutter UI dependencies. This is useful for course domain packages and tooling.

dart analyze and flutter analyze share the analyzer, but the Flutter command prepares a Flutter application context.

Shows automated fixes available for diagnostics and known migrations. Review the proposal before running dart fix --apply.

Automated fixes do not understand business intent. Review the diff and run tests afterward.

Runs tests in a Dart package. Use it to validate domain logic, utilities, and code that doesn’t need Flutter loaded.

Prefer small, deterministic tests. Network, clock, and randomness should be controlled through replaceable dependencies.

Generates API documentation from public libraries and documentation comments. Warnings reveal broken references or poorly documented APIs.

Documenting everything is not the goal; document contracts, decisions, limits, and behavior names don’t make obvious.

Compiles Dart programs to supported formats such as native executable, AOT snapshot, kernel, or JavaScript, depending on platform and version.

Choose the format for the runtime environment. AOT artifacts favor startup and distribution; JIT execution favors development and diagnosis.