flutter/samples: a runnable reference for Flutter patterns you can copy

What flutter/samples actually is, and who should clone it

flutter/samples is a monorepo of Flutter examples maintained under the flutter organisation. It is not a package you add to pubspec.yaml, and it publishes no API you import. The README describes it as "a collection of open source samples that illustrate best practices for Flutter", and the index lists roughly thirty directories grouped into Quickstarts, Native platform samples, Demo galleries and Demo apps.

The audience is narrow and specific. If you are learning a Flutter feature and want to see the smallest working code for it, the quickstarts are aimed at you: the README defines them as answering "What is the minimal amount of code needed to implement this feature?". If you want to see a product-shaped app, the demo apps such as compass_app and veggieseasons are meant to be built and run, and the README says they demo the product rather than how to write code. That distinction matters, because reading a demo app for idiomatic patterns will give you a lot of incidental code that is not the point of the sample.

It is a poor fit if you need a maintained library, a versioned release, or a scaffold you intend to keep. The repository has no published GitHub releases, and the README is explicit that "in most cases, we're not currently adding new samples to this repository" while the team rethinks sample code. So the value is in the code that already exists, not in the roadmap.

How the repository is organised, and what that tells you about each sample

The top level mixes per-sample directories with shared tooling. Alongside directories such as navigation_and_routing, platform_channels and add_to_app, there are analysis_defaults/, analysis_options.yaml, pubspec.yaml, tool/, docs/ and a CHANGELOG.md. That layout says each sample is its own Flutter project with its own pubspec, while lint rules and analysis configuration are shared across the repo through the analysis_defaults directory and the root analysis_options.yaml.

The add_to_app directory is the one place where the structure changes shape. It holds fullscreen, prebuilt_module, plugin, books, multiple_flutters and android_view, each demonstrating a different way to embed Flutter into an existing iOS or Android app. The README flags this group separately: "If you want to run an add-to-app sample, there are additional requirements." That is a real constraint, not a formality. These samples assume a host native project and, in the case of books, Pigeon-based communication between Flutter and the host application. Reading them without reading the linked add-to-app documentation will leave you with a project that does not build.

Some samples also depend on things outside the repository. google_maps demonstrates the Google Maps for Flutter plugin, and dynamic_theme calls on-device Flutter APIs based on output from the Gemini API. Those are the samples where you should expect to supply your own keys or platform configuration; the README does not document per-sample setup steps, so the sample directory itself is the place to look.

Running a sample: install the tool, then flutter run inside the sample

The install path is Flutter itself, not the repository. The README points at the getting started guide to install the flutter tool, and then gives one instruction for every sample: use flutter run inside that example's directory. There is no package to add and no build step unique to this repo.

Move into a single sample directory, for example navigation_and_routing or testing_app, and run the command the README gives.

flutter run

What you should see is a normal Flutter launch: the tool resolves dependencies, builds for the selected device, and starts the app. If you want to inspect the dependency set before building, each sample has its own pubspec.yaml, and the README does not describe a shared lockfile, so read that file rather than assuming versions.

If you plan to run an add-to-app sample, expect additional requirements beyond the plain flutter run flow. The README suggests reading the add-to-app documentation first, because those samples assume a host Android or iOS project.

Where flutter/samples stops being the right tool

The repository is a set of examples, and it behaves like one. The README states that new samples are mostly not being added, so a feature you cannot find in the index is unlikely to arrive. If your problem is a bug in Flutter itself, this is the wrong tracker: the README routes general questions to the FlutterDev Discord or the Flutter Community forum, and bugs in a sample to the flutter/samples issue tracker. Filing a framework bug here will not reach the right people.

There is also a maintenance asymmetry. The README says samples "are maintained on an ongoing basis to reflect changing APIs and best practices", but the same document says new samples are largely paused. Those two statements pull in different directions, and the practical consequence is that you should check a sample's freshness yourself rather than assume it tracks the current stable Flutter. The repository ships a CHANGELOG.md, but the repository has no published GitHub releases, so there is no version number to pin against.

The last push to the repository was on 2026-10-20, which is recent, but a recent push to a monorepo does not mean the specific sample you care about was touched. Treat each directory as its own maintenance unit.

flutter/samples versus flutter/demos, and versus a starter template

The README names the closest sibling directly: Googlers can freely add samples to the flutter/demos repository. That is the real alternative for new sample code, and the difference is about contribution policy rather than technique. flutter/samples is in a deliberate holding pattern for new additions; flutter/demos is where new samples are directed. If you are inside Google and want to publish a sample, the README tells you which repository to use.

For everyone else, the meaningful comparison is against a starter template or a scaffolding tool. A template gives you one opinionated project shape and you build inside it. flutter/samples gives you many small projects, each scoped to one feature, with no shared application architecture to inherit. That is better when you want to extract a technique, and worse when you want a foundation. If you copy from navigation_and_routing, you are taking a routing pattern, not an app skeleton; you still have to make the structural decisions yourself.

The demo apps sit between the two. compass_app implements MVVM architecture, so it is closer to a template in shape, but the README classifies it as a demo app meant to be built and run. Reading it for architecture is reasonable; treating it as a starter you will maintain is not what it is for.

Licence and the cost of keeping a sample current

The repository contains a LICENSE file, AUTHORS and PATENTS at the top level, and the licence is reported as NOASSERTION, meaning the automated classification could not map it to a standard identifier. That is a signal to open LICENSE and read it yourself before you copy code into a product. I am not giving legal advice here; the point is that the licence text is in the repository and the classification alone will not tell you your obligations.

Upgrade cost is per sample. Because each directory has its own pubspec.yaml and there is no published GitHub release to pin, keeping a copied sample working means tracking Flutter and Dart API changes yourself. The README's claim that samples are maintained to reflect changing APIs reduces that burden for the samples the maintainers touch, but it does not remove the work from your fork.

The cheapest way to keep the cost down is to copy the technique rather than the project. Take the MethodChannel pattern from platform_channels, or the go_router setup from navigation_and_routing, and reimplement it in your own app with your own dependency versions. That way a change in the sample never becomes a migration in your codebase.

Editorial conclusion

Adopt flutter/samples if you learn by reading short, runnable Dart and want a working reference for a specific Flutter feature, such as go_router navigation in navigation_and_routing or MethodChannel usage in platform_channels. Do not adopt it as a dependency, a starter template you will keep, or a place to send new samples: the README states new samples are mostly not being added while the project rethinks sample code in the new LLM world. Before you clone, check the sample's own pubspec.yaml and the Flutter version it expects, and confirm whether the sample you picked is a quickstart or a demo app, because the two are maintained with different intent.

Frequently asked questions

Official sources

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