In the interest of transparency, we want to share high-level details of our roadmap, so that others can see our priorities and make plans based off the work we are doing.

Our plans will evolve over time based on customer feedback and new market opportunities. We use our quarterly surveys and feedback on GitHub issues to prioritize work. The list here shouldn't be viewed either as exhaustive, nor a promise that we will complete all this work. If you have feedback about what you think we should be working on, we encourage you to get in touch (e.g. by filing an issue, or using the "thumbs-up" emoji reaction on an issue's first comment). Flutter is an open source project, we invite contributions both towards the themes presented below and in other areas.

If you are a contributor or team of contributors with long-term plans for contributing to Flutter, and would like your planned efforts reflected in the roadmap, please reach out to Hixie (ian@hixie.ch).

2023

This roadmap is aspirational; it represents some of what our most active contributors to Flutter have told us they plan to work on this year. It is in general difficult to make any guarantees about engineering work, and it is all the more so for an open source project with hundreds of contributors.

Our Flutter Forward keynote demoed some of these future plans!

Technical debt and team velocity

As always, the most important work we can do is increasing the overall velocity of the project. This includes reducing technical debt like flaky tests, but it also means improving our processes to help new people join the team and be productive faster. To this end, we will be starting a regular meeting for team members where velocity issues can be raised, documented, and addressed. Meetings are announced to team members on our Discord using the Discord Events feature.

Depending on the economic and epidemiological climates, we may also organize a summit to bring the team together.

We also plan to spend some time this year going through our issue backlog, closing issues that are obsolete or not actionable, and prioritizing the remaining issues.

Performance

Our top priority for Flutter improvements this year is performance.

We want to completely remove shader compiler jank, first on iOS and then on Android and desktop.

For web, we are working on supporting Wasm as a target, and have plans to investigate the use of multi-threaded rendering, reduce the download size for a basic Flutter application, and improve the performance of custom shaders.

For our VM-based backends, we are looking to make improvements to our memory allocation strategy to improve responsiveness and app startup performance.

Quality

Accessibility is critical to Flutter applications, and we will continue to invest heavily in making it easy for Flutter applications to be accessible, improving the quality of our accessibility support on all our platforms. Similarly, it is important to us to continue to improve our documentation. In both cases, the improvements are largely expected to be in the form of bug fixes and small patches, rather than large projects that are easy to describe on a roadmap, but that does not make them any less important.

We will also continue to implement features needed for full fidelity on each platform, especially the fast-moving Android and iOS. For example, we expect to make significant progress on our Cupertino widget set this year, bringing it up to date and growing the number of supported widgets, and we plan to implement support for Android's predictive back gesture and Android handwriting input. We also plan to port the camera plugin to Android's latest CameraX APIs.

Security

We will continue to work on SLSA compliance (supply chain integrity), with a goal to reach SLSA-3 for our main repositories this year, with an eye to continue to SLSA-4 next year. We also want to extend our tooling to enable Flutter package and application developers to achieve the same level of security.

Features

We do expect to spend some time on a few new features. These are generally driven by one of three motivations: popularity (we look at how many "thumbs-up" reactions an issue has received to help prioritize efforts), parity and portability (once one platform supports a feature, we feel it is important to make it work everywhere), and supporting some other effort (e.g. a new feature that can enable further performance improvements).

The most notable features we expect to implement this year are:

• Custom asset transformers, because they enable some performance improvements.
• Efficient 2D scrolling widgets (e.g. tables and trees), to improve the performance of applications with this kind of interface.
• Multiple windows, especially for desktop platforms, because this is a very highly requested feature.
• Platform Views on macOS and Windows, by popular demand.
• Drag and drop, also by popular demand.
• Wireless debugging on iOS, our second-most-requested feature.
• Custom "flutter create" templates, which makes it much easier for third-parties (e.g. the Flame engine) to bootstrap developers.
• Supporting element embedding (see also #32329), which allows Flutter content to be added to any standard web <div>, by popular demand.

Research

A lot of developers have expressed an interest in creating applications that integrate closely with the look and feel of their target platform, while supporting multiple platforms, without having to reimplement their interface multiple times. We want to study whether some form of adaptive layout would be able to address these needs, starting with Android vs iOS.

With our new graphics backend comes the opportunity for new features, and one in particular that we are interested in studying more closely is the integration of 3D into Flutter scenes. We expect to begin experiments with 3D this year. Similarly, we believe our new graphics backend may enable improvements to the low-level dart:ui API, and new shader features.

Relatedly, we are investigating implementing wide color gamut support (probably starting with iOS), as it is a highly requested feature.

We are also actively investigating migrating from ICU4C to ICU4X (the new Rust-based ICU backend), which will require research into how to embed Rust into our build pipeline across all our platforms, how to share Rust code between our engine and Dart FFI packages, and how to perform tree-shaking for binary code used in such packages.

Finally, we expect to spend some time investigating how to update Flutter to take advantage of new features coming from Dart this year, such as updating our APIs to make use of records and patterns, updating our toolchain to support RISC-V, or making use of new FFI features for plugins.

Releases

We plan to have four stable releases and 12 beta releases during 2023. In 2023 we will probably move to announcing new features when they reach the beta channel rather than waiting for them to be on the stable release channel. In general we encourage people looking for a faster update cycle to use the beta channel.

Non-goals

We unfortunately have had to shelve our current efforts to implement hot reload on web, as our web compiler experts are all working on Wasm production support. We also have no plans currently to implement code push, built-in support for wearables (Apple Watch, Android Wear) or automotive integrations, built-in support for SEO on web, or installation via homebrew. (Some of these have excellent packages available though.)

In general we prioritize issues with the most thumbs-up reactions on GitHub, and the astute among you may notice that the list of non-goals includes a number of these highest-rated issues. Unfortunately, we have discovered a pattern that we did not expect, though it is obvious in retrospect: when we address all the highest-ranked issues except for those that are technically infeasible or intractable for whatever reason, the result is that the highest-ranked issues that are left are all issues that are infeasible or somehow intractable.

See also: Popular issues, which discusses each of the top 10 issues.

---

We maintain an archive of roadmaps from previous years in a separate page.