- Home of the Wiki
- API Reference (stable)
- API Reference (master)
- Contributor Guide
- Chat on Discord
- Design documents
- Code of Conduct
- Issue triage reports
- Our Values
- Tree hygiene
- Issue hygiene and Triage
- Style guide for Flutter repo
- Project teams
- Contributor access
- What should I work on?
- Popular issues
- Running and writing tests
- Release process
- Rolling Dart
- Manual Engine Roll with Breaking Commits
- Updating Material Design Fonts & Icons
- Postmortems and Retrospectives
- Hotfix Documentation Best Practices
- Setting up the Framework development environment
- The Framework architecture
- The flutter tool
- API Docs code block generation
- Running examples
- Using the Dart analyzer
- The flutter run variants
- Test coverage for package:flutter
- Writing a golden-file test for package:flutter
- Managing template image assets
- Setting up the Engine development environment
- Compiling the engine
- Debugging the engine
- Using Sanitizers with the Flutter Engine
- Testing the engine
- The Engine architecture
- Flutter's modes
- Engine disk footprint
- Comparing AOT Snapshot Sizes
- Custom Flutter engine embedders
- Custom Flutter Engine Embedding in AOT Mode
- Flutter engine operation in AOT Mode
- Engine-specific Service Protocol extensions
- Supporting legacy platforms
- Metal on iOS FAQ
- Engine Clang Tidy Linter
- Why we have a separate engine repo
- Reduce Flutter engine size with MLGO
- Setting up the Plugins development environment
- Setting up the Packages development environment
- Plugins and Packages repository structure
- Plugin Tests
- Contributing to Plugins and Packages
- Releasing a Plugin or Package
- Unexpected Plugins and Packages failures
- Infra Ticket Queue
- Flutter's Build Infrastructure
- Flutter Installation Bundles
- GitHub Action Workflows
- Android Fast Start
- Apple Silicon support
- Desktop shells
- Deferred Components
- JIT release builds
- Making animated GIFs of Flutter apps
- Multi-device debugging in VS Code
- Null safety package migration status
- Running Flutter Driver tests with Web
- Data-driven Fixes
- Flutter CLI custom embedder support
- Bad Builds
Clone this wiki locally
This tells us what we are creating. It helps narrow our focus.
The best way to develop user interfaces is a productive way of developing.
The best way to develop user interfaces creates beautiful applications.
The best way to develop user interfaces creates fast applications.
The best way to develop user interfaces enables developers to create applications fast.
The best way to develop user interfaces is extensible, so that we are not a barrier to developers.
Our user is the developer. Our developer's user is the end user of the application written with Flutter.
Our first priority is to our developer's user, the end user. Our second priority is to our user, the developer.
Caring about the end user means having high quality support for accessibility, top performance, stability, high fidelity and compatibility with the user's platform, supporting low-end devices, and so forth.
Caring about the developer means creating a joyful and productive development experience with quick iteration cycles, creating usable, simple, reliable, predictable APIs, giving the developer full access to the underlying platform, and so forth.
We respect our users, whoever they are.
Flutter is an open source project, in the full senses of the word: we are open to ideas, we are open to contributions, our code and our roadmap are open, our priorities are open. Transparency leads to a higher quality product. While the most active part of our team is currently primarily formed of employees from Google, we are growing and welcome anyone to join the team; at this point, the majority of people with commit access are not part of Google's Flutter team. Flutter's stewardship is managed by a team at Google.
A mediocre product cannot be the best way to develop user interfaces, so we must build processes around maintaining high levels of quality.
This manifests in various ways. One is that we are feature-driven, not date-driven: we do not plan work based on deadlines. We may sometimes host events where we announce new features, but these events will announce features that have become available, rather than the features becoming available in order to be announced. This means sometimes a feature we intended to announce will slip and not be announced, but we prefer this to announcing a rushed feature.
We may sometimes gate features behind flags until we are confident of their quality.
Last, but definitely not least, we want to make sure that our work environment is pleasant for everyone involved. Your health and the health of your family and friends is more important than Flutter. Our community is welcoming. We don't know everything; all of us can make mistakes.
When we think about whether we claim to "support" something, e.g. whether Flutter supports Windows 7, we use the following frame of reference. We document which platforms we consider to fall into each category on flutter.dev.
We distinguish several categories along which one can describe a level of support:
- Supporting for deployment (we support a platform for deployment if you can run release builds of applications on that platform).
- Supporting for development (we support a platform for development if you can run debug builds of applications on that platform, connect them to a debugger, hot reload, view logs, and so forth; we support a plugin for development if it can be stepped through in a debugger).
- Supporting for hosting development (we support a platform for hosting development if it is one on which you can compile a Flutter application; we support an IDE for hosting development if it has a Flutter plugin).
- Supporting for Flutter development (we support a platform for Flutter development if one can contribute to Flutter itself from that platform).
The list of supported platforms on flutter.dev is describing the platforms supported for deployment.
For each area, we consider the level to which we provide support:
- We will literally help you with your code if things don't work. This is very rare. (See also "top-tier customers".)
- We will make a best effort to ensure that well written code works (e.g. we have testing on that platform). This is a common level for target platforms that have reached a label of "stable" (e.g. Android, iOS) on devices that are widely available (e.g. 64bit ARM). This corresponds to the "Supported Google-tested platforms" category on the list of supported platforms.
- We will not go out of our way to prevent code from working, but if it works it's because of luck and our best intentions rather than a coordinated effort (e.g. we do no testing on that platform). This is a common level of support for less commonly-used devices. For example, we do minimal testing of 32bit iOS devices. This corresponds to the "Best effort platforms tested by the community" category on the list of supported platforms.
- We will pay no attention to whether code works, but we will accept patches. This is a common level of support for the many esoteric embedded platforms that we have no way to even manually test. For example, if you have your own SoC and are running Flutter, we want you to succeed but we don't have any way to ensure it keeps working. If you are willing to provide reliable CI support for your platform, we are more than happy to work with you to move that platform to level 2.
- We won't accept patches. This is the appropriate response for features and platforms that are wildly outside our roadmap. For example, maintaining a Rust port of the framework is not something the Flutter project would accept patches for. This corresponds to the "Unsupported platforms" category on the list of supported platforms.