flutter/samples: The Official Flutter Code Sample Repository

What the Repository Contains and Who It Is For

flutter/samples is maintained by the Flutter team and serves as the primary source of short, runnable Flutter reference code. It targets Flutter developers who know the basics of the framework and need a working example of a specific capability rather than a blank project. The README distinguishes between two kinds of samples: quickstarts answer the question of what is the minimal code needed to implement a feature, and demo apps demonstrate the product rather than how to write code. Both types are meant to be cloned, opened in an IDE, and run as-is.

The repository is not a documentation replacement. It points to flutter.dev and the add-to-app documentation for detailed guidance, and uses the sample code itself to show the mechanism. A developer looking for architecture patterns will find the `compass_app` demo useful; a developer debugging a specific API will find the quickstarts more direct.

Repository Layout: Quickstarts and Demo Apps

The repository is organized as a flat collection of independent top-level directories, one per sample. There is no shared library and no parent project file that builds everything together. Each sample is a complete, self-contained Flutter application with its own `pubspec.yaml`. The top-level `pubspec.yaml` at the repository root exists for analysis tooling, not for running samples.

Quickstarts make up the majority of the collection. Representative examples include `background_isolate_channels` for long-lived isolate communication, `navigation_and_routing` for the go_router API, `platform_channels` for MethodChannel, EventChannel, BasicMessageChannel, and MessageCodec, `testing_app` for widget and integration tests, and `web_embedding` for embedding Flutter in existing web pages without iframes. Demo apps such as `compass_app` (MVVM architecture) and `animations` (animation feature gallery) are meant to be built and run rather than studied line by line.

Running a Sample

Every sample in the repository is fully runnable. The README gives a single instruction for running any sample:

flutter run

This command is executed inside the sample's own directory, not at the repository root. Running it at the root will not work because there is no application entry point there. The flutter tool must already be installed; the README links to the getting started guide at docs.flutter.dev/get-started/install.

For add-to-app samples under `add_to_app/`, the README notes there are additional requirements beyond a working Flutter installation, and directs readers to the add-to-app documentation before proceeding. The five add-to-app examples cover full-screen embedding, prebuilt modules, plugin usage within embedded Flutter, multiple Flutter engine instances via the Engine Group API, and view-level Android integration. Each has its own setup that involves a native iOS or Android project alongside the Flutter module.

Native Platform and Web Samples

The `platform_channels` sample is one of the more technically detailed entries in the collection. It demonstrates all four Flutter channel types in a single app, covering MethodChannel for request-response calls, EventChannel for streams, BasicMessageChannel for byte-level communication, and MessageCodec for custom serialization. This makes it the reference point for developers bridging Flutter to a platform SDK not yet covered by an existing plugin.

The `web_embedding` directory contains two examples: `element_embedding_demo` modifies `index.html` to launch Flutter inside a custom host element, and `ng-flutter` wraps the same technique in an Angular component. The `pedometer` quickstart is notable because it uses FFIgen and JNIgen to call platform APIs directly from Dart code, bypassing the plugin model entirely. The `simple_sdf` and `simple_shader` samples cover the Flutter fragment shader API, which lets Dart code drive custom GLSL shaders via the FragmentShader API.

Current Scope and What Is Missing

The README states plainly that the team is not currently adding new samples while it rethinks sample code in the new LLM world. This is not a temporary pause with a stated timeline; new contributors should read the contributing guide before submitting anything, and should not expect new topic areas to be added in the near term. Googlers are directed to the separate flutter/demos repository instead.

The collection covers widgets, navigation, testing, platform integration, shaders, and isolate communication. It does not include samples for state management beyond what the `compass_app` MVVM example shows, Dart-side FFI beyond the `pedometer` demo, desktop-platform-specific APIs beyond what `desktop_photo_search` demonstrates, or advanced rendering topics. Developers looking for those areas will need to look at third-party community examples or the Flutter cookbook at docs.flutter.dev.

Contribution Policy and Maintenance

The README asks contributors to read the contributing guide at developers.forem.com before submitting. For existing samples, the team welcomes fixes and necessary improvements. New samples are outside the current scope. The last push to the repository was on 2026-09-14.

The repository carries two top-level legal files: LICENSE and PATENTS. The license type is listed as NOASSERTION in the repository metadata, meaning the license identifier is not a standard SPDX string. Any team planning to use the sample code in a commercial product should review the LICENSE file directly rather than relying on the metadata label. The AUTHORS file lists contributors.

How flutter/samples Compares to the Flutter Cookbook

The Flutter cookbook at docs.flutter.dev provides short, single-topic code snippets embedded in documentation pages, often without a runnable project. flutter/samples provides complete, runnable applications for each topic. The distinction matters when the integration between parts of a feature matters as much as the individual API calls. A snippet showing how to set up go_router tells you the API shape; the `navigation_and_routing` sample shows how routing interacts with shell routes, redirect logic, and state restoration in a project that actually compiles.

The trade-off is discovery. Finding a specific pattern in the cookbook is straightforward because it is part of the documentation hierarchy. Finding a pattern in flutter/samples requires scanning the sample index in the README to identify whether the relevant sample exists. Developers who need a jumping-off point for a full-feature area and are comfortable navigating a real codebase will find flutter/samples more useful.

Editorial conclusion

flutter/samples is the right starting point for Flutter developers who need a runnable, team-maintained reference for a specific feature, particularly add-to-app embedding, platform channel communication, or go_router-based navigation. It is not a production template: the README explicitly labels quickstarts as minimal starting points, not deployable apps, and the team is not adding new samples while it reconsiders sample code in the context of LLM tooling. Before cloning, check the sample index to confirm the feature you need is already covered, and read the add-to-app documentation before attempting those samples because they carry additional platform-specific requirements.

Frequently asked questions

Official sources

1. flutter/samples on GitHub
2. Issues
3. Project website
4. README