We’ve been hard at work preparing to decouple Material and Cupertino from the Framework, and now our first major milestone has arrived! As of April 7th, all contributions to the Material and Cupertino libraries in flutter/flutter are frozen. Our next milestone will be the re-release of these libraries as the material_ui and cupertino_ui packages on pub.dev.

This means that, after the code freeze, no more changes will be allowed to the Material and Cupertino libraries inside of flutter/flutter. Further development on these libraries will resume in the flutter/packages repository once the new packages are released.

If you write Flutter apps or plugins, but don’t contribute to Material or Cupertino itself, you can stop reading now. This won’t affect you… yet.

After the 3.44 stable release, the new packages will be published and developers will eventually need to migrate. The old Material and Cupertino code will be deprecated in the stable release after 3.44 and deleted some time after that. Of course, when the time comes, we’ll follow up with detailed instructions about this migration.

For those who actively contribute to these libraries or are otherwise invested in their development, here are some things you should know:

What if you have PRs in flight?

Despite the code freeze, we want development on Material and Cupertino to continue with minimal interruption! Any open PRs that touch Material or Cupertino should remain open, and reviewers will continue reviewing and giving feedback as usual. Once the new packages are published, we will provide instructions on how to port these kinds of PRs to flutter/packages. Eventually, your change will go out as a part of a new material_ui or cupertino_ui release.

How about new and existing issues related to Material and Cupertino?

Issues that relate to Material or Cupertino will remain in flutter/flutter as always. This unified issue tracker approach is the same pattern that we follow for other packages in the flutter/packages repo and a few other repositories.

Why freeze the code now?

The moment that we release the 1.0.0 versions of the material_ui and cupertino_ui packages, we think it’s important to have a seamless migration process for every Flutter developer who is ready to migrate, regardless of which release channel they’re coming from. This means that we need to keep the risk of breaking changes to an absolute minimum between the Material and Cupertino libraries in flutter/flutter and in flutter/packages. We can achieve this by freezing the code one stable release cycle ahead and copying that frozen code to the new packages.

The first step in the migration process for Flutter developers is to perform a normal SDK migration to v3.44 or above on any channel. Once there, we know that they have a copy of Material and Cupertino that is frozen. Even if they upgrade their SDK again, that Material and Cupertino code will not change (until it’s deprecated and deleted in the long term). What’s more, we know that the frozen Material and Cupertino code is identical to the code in the 1.0.0 material_ui and cupertino_ui packages, or as close to identical as possible. From there, the developer can migrate from the Material and Cupertino code inside their copy of the SDK onto the material_ui and cupertino_ui packages with minimal friction.

How we got here

It’s been a long journey to this point with many contributions and feedback from across the community. A few months ago when I realized that we had test dependencies that would get in the way of decoupling, I posted an issue and figured I was in for a lot of migration work. Instead, contributors from across the community immediately jumped in to help migrate hundreds of tests. The support we received from first-time contributors to veterans was critical to getting us ready for decoupling. THANK YOU!

What’s next?

After the code freeze, we’ll begin preparing for migration to the new material_ui and cupertino_ui packages. This includes tasks like porting the code over, implementing CI/CD, testing, and setting up docs infrastructure to make sure we can keep the same high quality developer experience that you expect from Flutter.

As the new packages near readiness, we’ll publish more information about how to migrate successfully, so keep an eye out. Also, if you see anything that you think we’ve missed, please jump in with an issue or a PR. We couldn’t have gotten this far without help from the amazing Flutter community, and we can’t wait to see where we’ll go from here.

Flutter’s Material and Cupertino code freeze was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last month, we published Flutter and Dart’s 2026 Roadmap, a peek into how our teams are approaching our core mission: Building the most popular, fastest growing, and highest-productivity multi-platform UI framework. But it’s impossible to talk about development in 2026 without acknowledging AI.

To meet this moment, today we are sharing our data-driven and honest thoughts on how our teams approach Dart and Flutter + AI in 2026. This post is intended to be less of a roadmap and more of a collection of thoughts guiding our strategy. Transparency is a core pillar of Flutter, and as an open source project, we believe in the value of experimentation in public. Interpret this as a snapshot of how we’re thinking about AI today; we value your input and feedback but we also recognize that, in this rapidly shifting environment, strategy and approach may change as models, tools, and their use evolve.

The Agentic shift by the numbers

Flutter gained initial traction by staying ahead of the curve and adapting nimbly to the needs of developers building cross-platform. Now, AI represents another variable in how we think about our ecosystem. Not because every developer needs to use AI, but because we need to consider how it’s shifting our goals for those who do.

AI adoption is no longer a future trend; it is the current reality. The 2025 Stack Overflow Developer Survey showed that 84% of all developers use AI tools in some way within their daily workflows, and in our 2025 Flutter User Survey, we found that 79% of Flutter developers specifically report using AI assistants while working with Flutter.

However, this rapid adoption has revealed a significant “trust gap.” While 73% of developers feel more productive because they can reduce the friction of starting new tasks, 46% do not yet trust the accuracy of AI tools for critical tasks like writing, debugging, or fixing code. This leads to a “verification tax” — the time engineers pay auditing the output or fine-tuning instructions to achieve correctness.

Our approach: Who we build for and the principles that guide us

As the premier multi-platform UI framework from Google, Flutter is uniquely positioned to focus on the AI builders in our ecosystem. The principles ensure that Dart and Flutter remain the most reliable choice for developers building apps that run on any screen.

Who we are solving for

Our strategy addresses builders across the spectrum of AI adoption from traditional to agentic development:

• The traditional developer: Earn trust in AI for those who depend on core Dart and Flutter tooling. Traditional developers care deeply about thinking through problems themselves and using developer tools to dig under the hood. We aim to improve the existing foundation for them, which in turn improves the quality of AI and builds trust in agentic development.
• The AI-assisted developer: Improve productivity with AI for those who have adopted AI coding agents in their Dart and Flutter workflows. These engineers rely on AI for repetitive, tedious tasks and boilerplate code so they can spend more time on complex functional and architectural code. Our developer experience team is exploring AI tooling such as MCP servers, Agent Skills and other solutions in this space.
• The AI-first developer : Make AI work for those who haven’t yet discovered Flutter is the best way to build their apps. These builders are creating apps with natural language. By recognizing where their needs overlap other personas, we ensure our framework is ready for the future of AI development. Collaborations here might include guidance on Flutter with Antigravity, and other vibe-coding products that reflect “Vibe once, deploy everywhere” concept introduced at Google I/O 2025.

Our driving principles

• Humans first: Dart remains a “human first” language. We prioritize making code readable and manageable for developers, even when it is generated by agents.
• Add, don’t replace: AI tools should add and improve the experience of building with Dart and Flutter. Each developer should be empowered to use AI assistance as much as they desire, and on a timeline that they choose. We intend to ensure AI is grounded in our documentation and foundational tooling as the source of truth.
• Open standards & agent agnostic: We meet developers where they are. By leveraging open standards like the Model Context Protocol (MCP), we ensure Flutter works well with any agent you choose, not just Gemini. For example, we recently added an MCP tool to ensure hot reload can be used during AI Assisted development.
• Trust through quality: We aim to solve the “verification tax” by ensuring AI-generated code is accurate, idiomatic, and compliant with project standards. Ongoing investments and partnerships with Google Deepmind and Antigravity on model evaluation drive quality from the model through to AI developer tools. If you’re a model engineer, hit us up, we’d love to make your model write beautiful Dart code!

Let us know what you think

We are intentionally experimenting in public because no one knows exactly where this space is going. We invite the community to join us, share your feedback, and help steer the future of Dart and Flutter. Comment here, on social media, or via community forums; we value your thoughts and these conversations.

… Or continue building apps without AI, that’s totally valid too, and we welcome feedback on our developer roadmap in our previous post. For a deeper dive into our plans, you can view the full official 2026 Roadmap.

How Dart and Flutter are thinking about AI in 2026 was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, I’m Kevin Lamenzo! I recently joined the Dart and Flutter teams (🎉), and this January I set out on a quest: build 20 apps in 20 days using Flutter and Antigravity. But why? First, the cost of curiosity has officially hit zero. You can go from idea to app in 10 minutes. Second, as a new member of the team I wanted to learn about the framework by building something. Last, and most importantly, I wanted to test the theory that in 2026, we all can be builders now.

I’m here to share what I learned from the trenches. If you take only one thing from this post, let it be this: stop reading, and go build something.

The spark

My first app was a health tracker.

During a recent check-up, my physician “strongly suggested” that I watch my blood pressure and alcohol intake. My first reaction? “Don’t tell me what to do!” My second reaction? “I’m gonna build my own app for that.” No subscription offers, no data harvesting, no gamified onboarding. Just a simple tool that solved my specific problem.

Why Flutter?

I’m always on the go. I initially built a web app, which is nice, but I needed this tool to be in my pocket. Flutter makes the transition from web app to mobile app feel like magic. Antigravity barely needed to change the code.

After building the mobile version, I even opened a Google Play Developer account ($25), and released the app to myself as a tester. Now my creation is live on my own phone (although I still don’t have a logo or icon).

Tearing through ideas

The success of building the health tracker was intoxicating. By the end of the first week, I had four more apps on my phone and I had launched an internal blog (I called it “App a Day”) to document my journey and share the messiness with my colleagues.

This felt like more than vibecoding — I was building. I was exploring my phone’s sensors, working with haptics, and even using APIs.

Hitting a wall trying to scale

Everything wasn’t rosy. When I tried to take one of my quick idea apps and add to it every day of the week, I hit a wall.

Large scale apps are possible, but you need a different mindset. You have to lean into the architecture. You likely have to ask the agent 100 follow up questions. The more knowledge you bring to this step of the flow, the better an experience you will have. This is your excuse to go learn “traditional” development.

However, the beauty of the “App a Day” mentality is that you don’t always have to scale. Small apps are fast to build, helpful, and you can wake up tomorrow and move to a completely new one.

This leads to my “AI thought leadership soapbox moment”:

Right now we’re all empowered to do amazing things alone, but the next frontier is collaboration. How we use our AI superpowers to work together in new ways is uncharted territory. So, if you go out and “vibe build” an app with your friends or a team, chart your journey and share it with the rest of us.

My recommended flow

I got some questions from colleagues and friends about how I was staying organized. Here’s my flow to building your own app:

1. Get organized (Google Docs) - I haven’t gone fully AI yet. I need something static, something familiar, a place to park my ideas. I started every app, large or small, with a Google doc. I added the date and my quick notes. This gave me a place to return to as needed.
2. Refine my ideas (Gemini) - This step is becoming a classic “AI hack”: don’t write your own prompts; write down your raw thoughts and ask an LLM to create a golden prompt for you.
3. Build! (Antigravity) - Google’s new AI enabled IDE is a workhorse. By comparison, if you ask any of the popular LLMs (Gemini, ChatGPT, etc.) to “write me a book”, they can only output so much. When you ask Antigravity a complex task like this, first it makes a plan, then it works sequentially through each task in that plan. You guide it along the way. I put all of my golden prompts into Antigravity and guided it to build them into apps.
4. Test, iterate, repeat (also Antigravity) - After Antigravity finishes your first build, it’s time to get hands on. Run the software. Try it out. Provide your feedback to Antigravity, and ask it to make the changes you need. Don’t know how to run a Flutter app? Just ask the Agent in Antigravity.
5. (optional) Deploy (Google Play, Firebase - I’ve already mentioned getting my apps on my phone. Another great avenue for sharing is Firebase. Not sure where to start? Ask Gemini to guide you. Firebase makes hosting your apps and adding more advanced services (like authentication, for example) much easier.

Breaking out of my internal blog

The energy I got from this challenge eventually helped me explode right out of it. Instead of an internal blog, I went and launched my own personal site. Here I’m working outside the artificial bounds of building one small thing a day. Instead, I’m working on things big and small, grabbing ideas as they come, and moving on without hesitation.

Come find me at ladevzo.com/scrappy-path if you want to see how I’m applying these lessons outside the corporate firewall.

Conclusion: find your own flow

With that said, let me conclude with this: you don’t need to build 20 apps in 20 days. Start small. Use Gemini for brainstorming. Use Antigravity to build a prototype. Before you get bogged down mastering the code, focus on transitioning from “idea” to “working reality”.

The tools are ready. Are you?

Appendix: list of apps

1. Synonym slider (1 file, 207 LOC) — A simple app to provide the user with a list of synonyms for a given word. Demonstrates basic HTTP integration.
2. Sensor app (1 file, 228 LOC) — Interacts with device hardware using the sensors plus package.
3. Sino shift (1 file, 230 LOC) — A language experiment to translate English phrases and sentences into a Chinese-language-style ideograph format (Chinese languages use far fewer tokens when interacting with LLMs by virtue of their syntax)
4. Vip badge (1 file, 273 LOC) — Implements authentication through Firebase and Google Sign-In.
5. My apps widget (4 files, 305 LOC) — An Android homescreen “container” to hold all of my apps. Utilizes Android Intents to create a home screen widget.
6. Haptic soundboard (2 files, 311 LOC) — A soundboard application featuring audio playback capabilities.
7. Rusty-haiku (4 files, 403 LOC) — A simple haiku generator. Demonstrates API usage and state management with Riverpod.
8. Thought spot (5 files, 481 LOC) — Place a marker on a map and capture (by voice input) a thought. Features speech-to-text, maps, geolocation, and local databases.
9. Jolt (6 files, 494 LOC) — Focuses on local storage with shared preferences and custom UI fonts.
10. Accept changes (2 files, 547 LOC) — An attempt to bounce Antigravity’s push notifications to my phone. Provides device feedback via notification and connects to a Realtime Database.
11. Street slueth (9 files, 574 LOC) — A spin on Geoguesser: a collaborative murder mystery game where you need to use Google Maps to find clues and solve a puzzle. Map-based application with user authentication and Google Street View integration.
12. Learn witt (7 files, 588 LOC) — A learning app for understanding Wittgenstein. Focused on user interface design using custom fonts.
13. Parcheesi game (5 files, 625 LOC) — A Parcheesi remake. This was an attempt at “once shot prompting” with Antigrabity. Manages complex logic and state using Riverpod and Equatable.
14. Health tracker (6 files, 641 LOC) — Personal health tracking app for monitoring daily blood pressure and alcohol intake. Manages local state and utilizes the file system for storage.
15. Magic octo (6 files, 692 LOC) — My take on the magic 8-ball.
16. Meeting helper (5 files, 778 LOC) — Productivity tool using Firebase authentication and Cloud Firestore.
17. Haircut log (6 files, 901 LOC) — A Google Photos integration that helps hair salons manage user haircut photos leveraging the Google Photos Library API.
18. Wwks (6 files, 1121 LOC) — What would Kevin say? My personalized, AI-enabled, chat interface. Combines Google Generative AI with a full Firebase backend.
19. Human speed (15 files, 1124 LOC) — A personal thinking tool. Allows you to self-manage context across LLM threads. Full-stack AI application structured with Riverpod, GoRouter, and Firebase.
20. Math facts AI(11 files, 1520 LOC) — Educational tool leveraging generative AI to teach math facts.
21. Workout buddy (11 files, 1582 LOC) — Workout tracker, featuring Riverpod, Cloud Functions, and Freezed code generation.
22. Pulse (14 files, 1928 LOC) — Large-scale project integrating generative AI, robust state management, and code generation.

20 apps in 20 days with Flutter and Antigravity was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Transparency is a core goal of the Flutter open source project, and today we’re happy to share our roadmap for the next generation of apps. Our mission remains largely unchanged, we’re still working toward our long-term goal of creating the most popular, fastest growing, and highest-productivity multi-platform UI framework. You can check out the freshly updated roadmap on GitHub for all the details, and in this post we will cover the themes driving our mission.

As you dive into our plans for the year, keep in mind that this roadmap is — as it’s always been — our aspirational strategy for what’s ahead. As with any other roadmap, plans tend to shift and adapt throughout the year, so don’t be surprised if some changes happen along the way. While it primarily reflects the work our teams at Google are focusing on, the truth is that the Flutterverse is now so much bigger than any one company.

High-fidelity multiplatform: Impeller, Wasm, and beyond

Our driving mission is to continue to deliver the best multiplatform stack by focusing on native-level quality and performance. In 2026, we are completing the migration to the Impeller renderer on Android. By finally removing the legacy Skia backend on Android 10 and above, we’re ensuring smooth animations and reducing jank for every user. We continue to see Impeller as the best solution for fast startup and consistent performance.

On the web, we intend for WebAssembly (Wasm) to become the default to deliver native-quality experiences and performance. We are also committed to deep platform integration, ensuring day-zero support for Android 17 and upcoming iOS releases, alongside multi-window support for desktop where our partners at Canonical continue to make progress.

GenUI, ephemeral experiences and agentic apps

We are fundamentally changing app architecture to enable agentive UIs — interfaces that aren’t just pre-built, but adapt in real-time to user intent. This is powered by the Flutter GenUI SDK and the A2UI protocol, enabling AI models to generate rich experiences dynamically.

To support this, we are investigating evolving the Dart language by adding support for interpreted bytecode in the Dart runtime. This enables “ephemeral” code delivery, where specific portions of an app can be loaded on demand without requiring a full app store update — a critical technical step for truly agentic apps.

Full-stack Dart: Bring your tooling everywhere

We are broadening our stack to support the evolution towards full-stack and agentive apps. A major focus is Dart Cloud Functions for Firebase, providing ~10ms cold starts to ensure high-performance backend logic. We are also investigating Dart support for the Google Cloud SDK to enable you to easily connect and build your backend on Google Cloud. Additionally, we are working with the Genkit team on enabling Dart support to help you build sophisticated AI features.

AI-reimagined developer experience

AI coding agents are disrupting the way apps are built. We’ll continue to collaborate within Google to ensure Dart and Flutter have top-tier support in Gemini CLI and Antigravity, ensuring core workflows like stateful hot reload work seamlessly with AI agents.

We are also investing in MCP (Model Context Protocol) servers for Dart tooling, enabling AI agents to perform complex refactors and choose secure, performant libraries with high accuracy by “talking” directly to the Dart analyzer.

Sustainable open-source & governance

To unlock Flutter’s full potential, we are moving towards an open and sustainable operating model. This includes decoupling the Material and Cupertino design systems into standalone packages to accelerate development and allow them to evolve independently. We are also improving the extensibility of the Flutter Engine so support for new platforms can be authored “out-of-tree.”

We are deepening our commitment to the ecosystem by formalizing how we collaborate with stakeholders. Central to this is the expansion of our Consultancy Program, Insiders and Google Developer Expert (GDE) network, Customer Advisory Board (CAB), and Partners Advisory Board (PAB), which provide direct feedback to our teams.

Modern syntax & compiled performance

Dart continues to evolve as a high-performance language. In 2026, we plan to ship Primary Constructors to streamline class declarations and Augmentations to simplify code generation. We will continue to focus on improving build_runner and Dart/Wasm compilation, while refactoring the analyzer to improve performance for large-scale applications.

Bringing developers to Flutter and Dart

Our recently completed new Dart and Flutter learning pathway provides a streamlined, guided onboarding path for new builders. In 2026, we plan to continue our outreach both in-person and across digital platforms to improve the experience for developers and their AI tools.

See you at Google Cloud Next & I/O!

While this roadmap is our plan for the year, you won’t have to wait long to see the next big things from the team. Mark your calendars for Google Cloud Next 2026 in Las Vegas (April 22–24) and Google I/O 2026 (May 19–20). These will be the best moments to see Flutter in action next!

With non-Google contributors now outnumbering those of us employed by Google, there is an incredible amount of exciting work happening that isn’t even captured on this list! Accurate forecasting is always a challenge in an open source project, so please take this as a sincere statement of our intent and priorities rather than a fixed guarantee. We are unbelievably excited to keep building the future of apps alongside all of you and can’t wait to see what you’ll build!

What are you most excited for? Let us know on socials with the hashtag #Flutter2026. And if you’re excited about hearing more from us, be sure to follow us on X, check out the repos on GitHub, and keep an eye on this blog for the latest updates. Let’s build the future of apps together! 🚀

Flutter & Dart’s 2026 roadmap was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Empowering the community

Today, we’re excited to announce the release of Flutter 3.41, marking a transformative milestone in our journey together! What an exciting time to be a developer; this release represents our commitment to empowering our community in shaping the direction of Flutter. With 868 commits from 145 unique contributors, Flutter 3.41 provides additional transparency and modularity to further improve the experience of contributing to Flutter.

We are introducing public release windows to make it easier for you to know when changes you contribute would land in a stable release. We are also continuing to decouple our design libraries, which in the long term will help us evolve design systems faster, while also giving you control over which design changes you adopt in your apps. Whether you are pushing the limits of the GPU with new fragment shader improvements or embedding Flutter seamlessly into existing native apps with content-sized views, this release ensures you have the tools to build with confidence and speed.

There is so much to explore, so let’s dig right in…

Structural transparency and modularity

Public Release Windows

Predictability is key to landing complex features safely. We are introducing public release windows to provide the entire community with the visibility needed to plan ahead. By explicitly calling out branch cutoff dates and release targets publicly, we enable the entire community to have clarity on when their changes would land in future stable releases.

So what is a branch cutoff date? This date is the deadline for pull requests to land in the default branches (main for Dart and master for Flutter) to guarantee inclusion in the next stable release. If your PR merges before the cutoff, it will ship in the next stable version. If it merges after, it waits for the following cycle.

For 2026, we plan to release four stable releases (including this one), the dates are as follows:

• Flutter 3.41 — Feb | Branched on 06 January
• Flutter 3.44 — May | Branches on 07 April
• Flutter 3.47 — August | Branches on 07 July
• Flutter 3.50 — November | Branches on 06 October

Decoupling for a leaner core

We’re continuing our project to migrate the Material and Cupertino libraries to separate packages. This modular approach has several benefits:

• Faster release cycles: We no longer need to wait for a quarterly SDK release to ship design updates. We can release new Material or Cupertino features and bug fixes the moment they are ready.
• Independent upgrades: If you’re using an older SDK version due to a project constraint, you can still upgrade your design packages to get the latest look and feel.
• Adaptive design: Versioned packages allow us to react much faster when iOS or Android introduce drastic design shifts like “Liquid Glass” or “Material 3 Expressive”, ensuring your app never looks out of date.

Keep an eye on the GitHub issue to follow the progress.

Embracing ecosystem standards

Part of empowering the community is ensuring Flutter plays nicely with the tools we already rely on.

Swift Package Manager and UIScene

The transition from CocoaPods to Swift Package Manager continues. We strongly encourage Plugin authors to adopt Swift Package Manager, as it is now the standard for the Apple ecosystem. Additionally, to ensure compatibility with future iOS releases, Flutter now fully supports the UIScene lifecycle by default . This update is critical in meeting Apple’s requirements for upcoming iOS versions. To streamline migration from the deprecated AppDelegate lifecycle logic, check out our migration guide.

Android Grade Plugin (AGP) 9 and Kotlin DSL

We continue to align with modern Android standards. With the release of Android Gradle Plugin (AGP) 9, we are working on supporting new strictness requirements and providing guidance on how to navigate them.

Warning: Do not update your Flutter app for Android to AGP 9 as migrating plugins to AGP 9 and Flutter apps on AGP 9 using plugins is not yet supported (#181383). This support is paused while the Flutter team audits the migration for backwards compatibility with older versions of AGP. This migration doc will be updated as guidance changes.

Thanks to contributions from community member Byoungchan Lee (bc-lee@), new plugin projects now default to using the Kotlin DSL for Gradle.

Platform-specific assets

Optimizing is now easier thanks to the work of Alex Frei (hm21@). You can now specify which platforms an asset should be bundled for in your pubspec.yaml. This allows optimizations such as, excluding heavy desktop assets from your mobile builds, significantly reducing app size.

flutter:
  assets:
    - path: assets/logo.png
    - path: assets/web_worker.js
      platforms: [web]
    - path: assets/desktop_icon.png
      platforms: [windows, linux, macos]

Listening to the community

The Flutter team at Google continues to prioritize what matters most to you.

The getting started experience

For years, the community has called out that while Flutter is delightful and productive, it can be difficult to know where to begin the learning journey.

We recently launched a completely reimagined Dart and Flutter Getting Started Experience.

It’s a new learning pathway designed to guide you through the fundamentals of building apps with Flutter and Dart. Let’s take a quick look at some of the changes:

• We’ve introduced a new “quick install” guide that leverages hot-reload on the web, enabling learners to experience the full power of Flutter fast, without setting up a platform-specific environment first. A pathway consisting of written tutorials, low-stakes quizzes, and eight new videos featuring some familiar faces from the Flutter team at Google.
• Learners would finish the learning path having built 4 apps completely from scratch.

Give the new Getting Started Experience a try in the newly redesigned Learn section of our website, powered by Jaspr.

Fragment shader improvements

In Q4 2025, we surveyed developers using the FragmentShader API and asked simply: What is impeding your work? You told us that you needed improved ergonomics when using the API, while also having more flexibility when defining your shaders. In response to that, we made the following changes:

• In 3.41, we added Synchronous Image Decoding. Previously, creating textures for shaders could introduce a frame of lag. With decodeImageFromPixelsSync, you can now generate textures and use them as samplers in the same frame.
• We’ve also added support for High Bitrate Textures (up to 128-bit float), unlocking the ability to use high-resolution lookup tables (LUTs) for GPU-accelerated photo filters and SDFs.

void attachTexture(ui.FragmentShader shader) {
  ui.PictureRecorder recorder = ui.PictureRecorder();
  Canvas canvas = Canvas(recorder);
  canvas.drawCircle(const Offset(64, 64), 64, Paint()..color = Colors.red);
  ui.Picture picture = recorder.endRecording();
  ui.Image image = picture.toImageSync(
    128,
    128,
    targetFormat: ui.TargetPixelFormat.rFloat32,
  );
  shader.setImageSampler(0, image);
}

Widget Previews (Experimental)

Based on your early feedback, we are iterating rapidly on Widget Previews. With this release, Widget Previews have improved as follows:

• Flutter Inspector support: The Widget Preview environment now has access to an embedded Flutter Inspector instance, making it easy to inspect layouts and the state of previewed widgets. Important note: it might be necessary to configure additional package directories to see widgets from your project by default. To do this, open the Flutter Inspector settings by clicking the gear icon and add a new package directory pointing to your project.

• Support for applications with dart:ffi dependencies: Previously, previews that included widgets with transitive dependencies on libraries importing dart:ffi would cause compilation errors and prevent the preview environment from updating. This occurred because dart:ffi isn’t supported on web platforms (flutter/flutter#166431). The widget previewer can now handle previews that have dependencies on platform-specific libraries, including dart:ffi and dart:io. Important note: invoking APIs from these libraries isn’t supported in the widget previewer and will result in an error being displayed for previews calling these platform-specific APIs. See the Dart documentation on conditional imports for examples of how to write code that’s compatible with both native and web platforms.

Framework fidelity and polish

We continue to refine the present experience with a focus on platform fidelity and developer efficiency.

iOS polish

In Flutter 3.41 we’ve made visual improvements with the new “bounded blur” style. Previously, translucent widgets using the BackdropFilter could suffer from color bleeding at the edges. Thanks to improvements in the Impeller rendering engine, we have eliminated this artifact.

We’ve also added support for native styled drag handling for CupertinoSheet through the showDragHandle property.

Add-to-App

Adding Flutter views to existing Android and iOS apps is now easier! Flutter views embedded in existing native apps can now automatically resize themselves based on their content. Previously, a Flutter view needed a fixed size provided by its native parent. This made some scenarios difficult, like adding Flutter views to a native scrollable view.

To use this, your root widget must support unbounded constraints. Avoid using widgets that require a pre-defined size (like ListView or LayoutBuilder) at the top of your tree, as they will conflict with the dynamic sizing logic.

To enable this behavior on iOS, setFlutterViewController.isAutoResizable to true. For Android, enable content sizing in your Android Manifest and set the width or height of your FlutterView to content_wrap.

Navigation and scrolling

We’ve worked hard to smooth out the rough edges in core interaction models through the following changes:

• We’ve introduced Navigator.popUntilWithResult, allowing you to pop multiple screens and pass a value back to the destination route in a single call, drastically simplifying state management in multi-step flows.
• We reimplemented StretchingOverscrollIndicator using a simulation-based approach ported from Android 12. This ensures a more natural and fluid overscroll effect that responds correctly to high-velocity flings.

• We fixed an issue with pinned headers in NestedScrollView and SliverMainAxisGroup, ensuring headers correctly overlap subsequent slivers.

Accessibility

Helping you build accessible experiences that reach users on any screen is at the heart of our mission. In this update, we’ve added the following:

• Native accessibility support for CircularProgressIndicator and LinearProgressIndicator, allowing assistive technologies to announce progress updates.
• Flutter now respects web users’ text spacing overrides to improve the reading experience.
• We’ve introduced new matchers like isSemantics and accessibilityAnnouncement in flutter_test to make validating accessibility easier.

Material and animation

We have introduced new primitives and properties to expand control over animations and layout. Thanks to the work of community member Bernardo Ferrari (bernaferrari@), RepeatingAnimationBuilder introduces a declarative way to create continuous animations like a loading indicator, a pulsing button, or a shimmering placeholder effect.

For example, here’s how you can make a square slide back-and-forth:

RepeatingAnimationBuilder<Offset>(
  animatable: Tween<Offset>(
    begin: const Offset(-1.0, 0.0), 
    end: const Offset(1.0, 0.0),
  ),
  duration: const Duration(seconds: 1),
  repeatMode: RepeatMode.reverse,
  curve: Curves.easeInOut,
  builder: (BuildContext context, Offset offset, Widget child) {
    return FractionalTranslation(
      translation: offset,
      child: child,
    );
  },
  child: const ColoredBox(
    color: Colors.green,
    child: SizedBox.square(dimension: 100),
  ),
),

We also updated CarouselView with a .builder constructor, making it easier to create carousels with dynamic content. DropdownMenuFormField now supports a custom errorBuilder, and RawAutoComplete now includes an OptionsViewOpenDirection.mostSpace option to intelligently position options based on available screen space.

Community-led evolution

One of the strongest examples of Flutter open source partnerships is our longstanding relationship with Canonical. Their team continues to drive the Flutter Desktop roadmap forward, delivering critical features that benefit the entire ecosystem.

Thanks to Canonical’s engineering leadership, we are closing the gap on complex desktop UI requirements. This release introduces experimental APIs for creating popup windows and tooltip windows, along with cross-platform support for dialog windows on Linux, macOS, and Windows. Finally, new APIs were added to let you test multi-window apps. If you’d like a sneak peek of these upcoming windowing APIs, check out Flutter’s multiple_windows example app!

Flutter Linux now also enables merged threads by default, simplifying the threading model and improving performance while also working to improve Windows stability. We intend to remove the merged threads opt-out in a future release. If you have any issues with merged threads, please let us know.

DevTools

Devtools has seen improvements in performance and stability:

• Flutter’s DevTools are compiled using dart2wasm, resulting in performance improvements. You can still opt out and revert to the dart2js-compiled DevTools by using the settings dialog.
• Dropped connections to the Dart Tooling Daemon (DTD) are now automatically retried to improve the experience when your machine resumes after sleeping.

These are just a couple highlights from this release. To learn about all the updates included in Flutter 3.41, check out the release notes for DevTools 2.52.0, 2.53.0, and 2.54.0.

Next Stop: flutter upgrade

Flutter 3.41 is a step toward improving our open source contributing experience, while also improving Flutter’s foundational feature to enhance your development experience whether you are migrating a plugin to Swift Package Manager, optimizing assets for specific platforms, or pushing pixels with new Shader APIs. We are grateful for the amazing community we’ve built together.

For a comprehensive list of all the changes, be sure to check out the detailed breaking changes and release notes. To try out the new features in Flutter 3.41, all it takes is a flutter upgrade!

What’s new in Flutter 3.41 was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

In time, I’ve come to understand the definition of ‘Dart and Flutter developers’ to include those who don’t yet even call themselves Dart and Flutter developers; they’re just Flutter-curious.

Today, we’ve landed something that we think improves the lives of those future Flutter developers: the Dart and Flutter Getting Started experience.

What we built

The Getting Started experience is a multi-disciplinary learning pathway for programmers who don’t yet know anything about Dart or Flutter. It spans both the Dart and Flutter websites, and combines written tutorials, video series, quizzes, and documentation to take you from setting up Flutter to building a handful of apps designed to teach the fundamentals.

A quick install guide for those who just want to try Flutter out.

Since the release of hot reload on the web, Flutter learners can have the full Flutter experience without having to download platform-specific development environments until they need them. We wrote a new quick install guide to reduce the friction of trying Flutter. We don’t want it to feel like a commitment before you even start!

Two full tutorials: one for Dart, one for Flutter.

The Dart tutorial was designed to lead into the Flutter tutorial, but they aren’t dependent on one another. If you’re already confident using a different modern, object-oriented language, you’re free to jump straight into the Flutter tutorial.

Four apps that you’ll build from scratch.

Of all the design questions we asked ourselves, we spent the most time thinking about what the reader will actually build. Will it be one giant app, several discreet cookbook recipe-like pieces of Flutter code, or something in between?

Ultimately, we came to the conclusion that smaller apps provide a better experience for new learners for a few reasons:

• With larger apps, there’s more room for things to go wrong, which can cause a new learner to become frustrated.
• The larger the app, there’s more required code that isn’t actually pertinent to what the tutorial is trying to teach.
• We didn’t want to ask the user to clone a repository with 25 projects with names like flutter_tutorial_step_1. Then you have to bring git and terminal commands into the picture, you have to ask the reader to copy the commands that work their operating system, and so on. It’s just a bunch of unnecessary cruft that gets in the way of learning.

At the same time, the apps need to be more than single-feature apps, else we’ll fail to connect the dots of a feature to the bigger picture.

Eight videos accompanying major topics.

The videos in the Getting Started experience were written to provide the most crucial context, so the reader would understand what they were doing when they got to the hands-on-coding part.

Including these videos is important to me on a personal level too. Many years ago when I was learning Flutter, I felt in awe of the early DevRel team. They cared deeply about teaching Flutter, and they were so genuine and supportive that I wanted to be part of whatever it was they were doing. Since this learning pathway is often going to be the first thing a new Flutter developer interacts with, I wanted to honor that feeling and make Flutter-curious developers feel excited and welcomed to join the community.

To that end, we use the videos as a way to teach Flutter, but also to introduce a handful of the real-life humans that work to make the Flutter and Dart better everyday — engineers, tech writers, and product managers are all featured.

Small quizzes throughout to confirm what you’ve learned.

We added simple quizzes at the end of each tutorial page. They’re low-stakes and non-blocking. They exist only to give you a bit of feedback and confidence. If you don’t like ’em, skip ‘em!

The existing How Flutter Works YouTube series as a conclusion.

We cap the learning tutorial off with Craig Labenz’s fantastic video series, released a few months ago, called ‘How Flutter Works’. This series teaches you the inner workings of Flutter with just enough depth that it’s still approachable, yet upgrades your ability to write Flutter apps. This is must-learn knowledge on the way to becoming an advanced Flutter developer.

Website updates

This tutorial is shipping alongside several updates to the Dart and Flutter websites. You may know that we’ve been migrating our website infrastructure from JavaScript-based static site generators (SSGs) to Jaspr, a Dart SSG. The timing of that migration isn’t random! We knew we wanted to do it, and it seemed like the right thing to do before we started work on the considerable updates to the website we made for the Getting Started tutorials.

As a reader, the most noticeable update is the separation of the main docs articles and the Learn section of the website. The learn section of the site is reached by clicking on the Learn button in the site’s header navigation, as seen in this screenshot:

The Learn section is where we’ll organize all existing and future tutorial-style documentation and articles, in order to keep the main docs easier to navigate. In the header navigation the main docs can be reached with the “User Guides” button (or by clicking the site title).

Try it out

The learning pathway is live at docs.flutter.dev/learn/pathway. If you go through it — or even just part of it — please fill out the feedback survey linked on that page. We’re listening, and we’re already thinking about what comes next.

Announcing our new Dart and Flutter Getting Started experience was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summary

In the era of agentic AI, the bottleneck for scaling projects has shifted from code volume to code integrity. To move at the speed AI allows without introducing systemic friction, we must stop treating AI as a magic wand and start treating it as a high-performance engine that requires a perfectly calibrated track.

• Close the gap: Engineering teams are splitting — traditionalists on one end and high-velocity agentic power users on the other. For production apps, your infrastructure must connect both, creating a shared space where traditional rigor and agentic speed don’t just coexist, but actively harden each other.
• Lean into reproducible systems: An agent is only as good as its feedback loop. If your tests aren’t reproducible and your CI lacks a high-signal feedback loop, your agents are flying blind.
• Prompts as infrastructure: Stop treating your best AI instructions as ephemeral chat one-offs that disappear when a session ends. Instead, move these automated workflow instructions into a version-controlled file, transforming your individual tribal knowledge into executable documentation that ensures every team member can trigger the same high-integrity results reliably across the project.
• Shift to Skill-based architecture: Success means graduating your proven workflows into shared Skills. By moving from individual prompts to project-wide Skills, you provide your entire team with a standard, high-integrity playbook that agents can execute automatically.

Recently, I’ve been reflecting on what it truly means to scale an open-source project for a new wave of contributors. We are moving into an era where agentic AI can generate code so rapidly that sheer volume is no longer the bottleneck; instead, the real challenge is ensuring this influx doesn’t compromise our codebases, or our shared values as teammates. Many teams are splitting into a dumbbell shape: traditional manual coding on one end and high-velocity agentic power-users on the other.

For large apps, our infrastructure must serve as the handle that connects these two ends of the spectrum, creating a shared space where traditional rigor and agentic speed don’t just coexist, but actively harden each other. To scale effectively, we must lean into the basics by anchoring our workflows in the fundamentals of reproducible software development. To move at the speed these tools allow without drowning in technical debt or unreadable codebases, our environments must provide a definitive, high-signal feedback loop.

In this agentic context, source code health is measured strictly by passing tests, deterministic coverage metrics, and clean analysis. If these fundamentals are missing, it’s like asking a high-performance engine to drive at breakneck speed through the dark. It is perfectly reasonable — and often responsible — to feel the need to push back against these new tools if the environment isn’t ready for them.

The goal here isn’t to force a tool onto a project for the sake of speed; it’s to build the digital sensors that allow us to adopt that new velocity safely. More importantly, this transition is about bringing our teammates along for the ride. Infrastructure shouldn’t be a barrier that separates the “AI power users” from the rest of the team; it should be the common ground where we all feel confident. Being a good teammate in the agentic era means ensuring that though our repositories might move faster, our culture remains supportive. We build these systems so that everyone can move with confidence, ensuring that “agentic speed” is a win for the whole team, not just a new risk for an existing functioning software product.

However, these digital sensors are only as reliable as the environment in which they live. This is why we must anchor our trust in our CI systems. In a truly reproducible workflow, the CI is the only version of reality that matters; it is the final arbiter for an agent that lacks human intuition. If a change doesn’t pass the automated gates, it effectively doesn’t exist. By treating the CI as a high-signal feedback loop, we remove the human bottleneck of manual verification and replace it with a reproducible gate. This absolute source of truth allows us to scale more responsibly — enabling agents to fail fast, iterate, and ultimately succeed without compromising the integrity of the project or the peace of mind of the team.

The ask

A one-off prompting success is just a fluke. True scale comes from creating a flywheel: every time you or a teammate returns to the repository, the agent should be more capable than it was the last time because knowledge debt has been paid forward into a shared repository of prompts. You are building a shared institutional memory that isn’t trapped in a single developer’s head.

To make this repeatable for any developer on your team, you need a library of prompt instructions that acts as executable documentation. While many teams rush to create global “config” and “rules” files, I find these often lead to inconsistent results — an agent might “forget” a rule or misapply it to the wrong context. As scientifically minded engineers, we should prefer to remove variables. By controlling the exact prompting for a specific task, you ensure the agent has exactly what it needs for that particular task within your repository. Doing so in an intentional manner in a project is what helps both individuals and teams build genuine confidence in these new tools.

Enter Agent Skills

In late 2025, Anthropic introduced Agent Skills — an open standard designed to provide AI agents with specialized, modular expertise. Rather than just generic tools, Skills package instructions and resources together to ensure complex tasks are performed consistently. This is moving fast; as of early 2026, many tools are already adding support for this standard to enable cross-platform portability.

• Flexibility: You can use Skills with many agents, including Antigravity, Cursor, Claude Code Gemini CLI and VS Code, because they are an open standard.
• Shared knowledge: Skills can be easily shared with collaborators, or saved into a user folder for use across projects.
• Repeatable workflows: Skills ensure that agents consistently perform complex, multi-step tasks by instructing them with clear procedural steps.
• Additional resources: Skills can include scripts, templates, or other data alongside instructions.
• Just-in-time access: When Skills are first loaded, only the metadata is loaded into the agent’s context. This means that the specific instructions are only added to the context when needed, which saves tokens.
• Maintain code quality: The construction of these can be used as a set of tools to help contributors have the right context to put together higher quality PRs, tests, and documentation following your best practices.

Documentation for current major tools that support Skills

See documentation for your tool to see where to add these files.

• Antigravity — https://antigravity.google/docs/skills
• Cursor — https://cursor.com/docs/context/skills
• Claude Code- https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• Gemini CLI — https://geminicli.com/docs/cli/skills/
• VS Code — https://code.visualstudio.com/docs/copilot/customization/agent-skills

The anatomy of an effective Skill

To ensure your Skills library remains a “Runbook for Robots” rather than just a list of suggestions, every prompt in this collection follows a strict set of best practices:

• Known good state: Before an agent touches a line of code, it must verify that the existing tests pass and the analyzer is clean. If the foundation is cracked, the agent fixes the foundation before building on top of it.
• Actionable verification: Anchor instructions in commands like flutter test --coverage or dart fix --apply to provide the agent with the deterministic feedback it needs to self-correct.
• Finite scoping: To ensure that the agent maintains high context and focus, prompts are designed with clear boundaries — targeting specific functions, files, or coverage gaps. This ensures that the agent remains focused on a single goal, preventing scope creep and ensuring the output is easy to review.
• The report & review loop: The agent’s job ends with a structured summary, not a commit. By requiring the agent to explain its changes and provide a suggested commit message without actually pushing code, we keep the human engineer in the role of the final decision maker.

Example Skill: Prepare current work for PR

---
name: pr-prep
description: Prepare current work for PR
---
## Prepare current work for PR: Verify Tests Passing and Cleanup

**Objective:** Verify the current test suite status with `flutter test`, clean up any temporary modifications, and harden test coverage for active files.

**Instructions:**
1.  **Baseline:**
    *   Run `dart fix --apply` to apply automated fixes.
    *   Run `flutter analyze` to ensure no analysis issues.
    *   Run `flutter test` to establish the current passing state.
    *   Run `flutter test integration_test/app_test.dart` to verify integration integrity.
2.  **Fix Failures:** If there are any test failures or analysis errors, investigate and resolve them. Prioritize fixing code over deleting tests.
3.  **Cleanup:** Review any currently modified files (run `git status` or check the diff). Remove any:
    *   `print` / `debugPrint` statements.
    *   Unused imports.
    *   Commented-out code blocks.
    *   Temporary "hack" fixes that should be replaced with proper solutions.
4.  **Verify & Expand:**
    *   For the files you touched or cleaned up, check if there are obvious edge cases missing from their unit tests. Add tests to cover these cases.
    *   Run `flutter analyze` again to ensure clean code.
    *   Run `flutter test` again to ensure cleanup didn't break anything.
    *   Repeat this step as necessary.
5.  **Report & Review:**
    *   Summarize the cleanup status (e.g., "Tests passing, removed 3 debug prints").
    *   **Action:** Ask the user to review the changes closely to ensure no intended code was accidentally removed.
    *   **Do not commit or push.**
    *   Provide a suggested Git commit message (e.g., "Prepare for PR: Fix tests and remove debug code").

Example Skill: Single file test coverage

---
name: single-file-test-coverage
description: Write a new test or modify an existing test
---
## Single File Test Coverage Improvement

**Objective:** Write a new single test file, or modify an existing file, to improve coverage for a specific target class.

**Instructions:**
1.  **Identify Target:** Choose a single source file (Dart) in `lib/` that has low or no test coverage and is suitable for unit testing (e.g., utility classes, logic helpers).
3.  **Establish Baseline:**
    *   Run `flutter analyze` to ensure validity.
    *   Run `flutter test` to ensure the project is stable.
    *   Run `flutter test --coverage` and check `coverage/lcov.info`.
4.  **Implement/Update Test:** Create a new test file in `test/` or update the existing one. Focus on:
    *   Edge cases (null inputs, empty strings, boundary values).
    *   Branch coverage (ensure if/else paths are exercised).
    *   Mocking dependencies where necessary (using `mockito` or `mocktail`).
5.  **Verify & Iterate:**
    *   Run the tests to ensure they pass.
    *   Run `flutter analyze` to ensure no regressions.
    *   If coverage is still low, **iterate a few times**: analyze missed lines/branches and add targeted test cases.
5.  **Report & Review:**
    *   Summarize what was fixed/covered and report coverage progress (e.g., `X% -> Y%` for `<filename>`).
    *   **Action:** Ask the user to review the new tests closely.
    *   **Do not commit or push.**
    *   Provide a suggested Git commit message (e.g., "Improve test coverage for [Class Name]").

Example Skill: Migrate to modern Dart features

---
name: migrate-to-modern-dart-features
description: Migrate to modern Dart features (Dart 3+)
---
## Migrate to Modern Dart Features

**Objective:** Optimize consistency and conciseness by migrating to modern Dart features (Dart 3+).

**Candidates for Migration:**
*   `if-else` chains -> `switch` expressions.
*   Data classes with manual `==`/`hashCode` -> `Records` or `equatable` (or class modifiers).
*   Null checks -> pattern matching.

**Instructions:**
1.  **Baseline:** Run `flutter test` and `flutter analyze`.
2.  **Select Target:** Identify a *single* migration opportunity.
3.  **Constraint:** Keep the change extremely small (**max 50 lines**).
4.  **Migrate:** Refactor to use the new feature.
5.  **Verify:**
    *   Run `flutter analyze`.
    *   Run `flutter test` to ensure no regressions.
6.  **Report & Review:**
    *   Summarize the migration.
    *   **Action:** Ask the user to review the changes closely.
    *   **Test Location:** Explicitly state where in the app the user should go to manually test the change (e.g., "Click the bottom button after the app opens").
    *   **Do not commit or push.**
    *   Provide a suggested Git commit message (e.g., "Refactor: Use switch expression in [Class Name]").

In summary

The long game of the agentic era isn’t about the volume of code you produce today; it’s about responsibly architecting the infrastructure and cultural expectations for the repositories of tomorrow. By building the handle of the dumbbell, ensuring that as our tools move faster, they remain anchored to our shared values and technical rigor.

In the very near future, agents will move from reactive assistants to proactive contributors — checking in on your repository and resolving issues while you sleep. By hardening your high-signal feedback loops and documenting your workflows in a version-controlled suite of Skills, you are doing more than just saving time; you are training the agents of the future to respect your specific architecture, your vision, and your standards. Most importantly, you are ensuring that as the engine of development accelerates, your entire team has the digital sensors and shared knowledge to move forward with collective confidence and a stronger, more resilient engineering culture.

Jaime’s build context: Prompt engineering as infrastructure was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, Flutter community! My name is Emma Twersky, and I’m back with monthly updates from the Flutterverse. I’m so thankful for the warm welcome, and excited to be a part of this community.

This post is a bit of a two-for-one: we’re diving into hot new content from today’s livestream, “Flutter Flight Plans,” helping you take flight on some of our most requested topics. Then we’ll take a moment to reflect on what a truly landmark year 2025 has been. We’re all-in on making Dart & Flutter the best way to build amazing multi-platform apps, and we’re excited to show you what’s new and what’s next.

10 Highlights from Flutter & Dart in 2025

What a year! Let’s dig into just 10 of the top moments, although it was hard narrowing it down…

As you might know, Dart and Flutter ship quarterly updates. In 2025, we shipped eight packed stable releases:

1. Flutter 3.29 & Dart 3.7 (Feb 2025): This release was all about performance and fidelity, with big Impeller updates, the move of Dart execution to the main thread on mobile to improve native interop, and a new Dart formatter.

2. Flutter 3.32 & Dart 3.8 (May 2025): We got experimental web hot reload, Cupertino “Squircles,” stylus support on Android, cross-compilation for Dart, and null-aware elements.

3. Flutter 3.35 & Dart 3.9 (Aug 2025): Web hot reload became default, we launched experimental Widget Previews, introduced the Dart & Flutter MCP server, and announced the Material/Cupertino decoupling.

4. Flutter 3.38 & Dart 3.10 (Nov 2025): Dart added dot shorthands, web tooling improved, and Widget Previews got IDE integration! Plus, crucial iOS 26/Xcode 26 support and the UIScene migration path.

5. We laid out our vision early in the year, sharing our Flutter 2025 Roadmap Update and it’s exciting to see how much has been delivered and the continued focus on multi-platform excellence and AI integration.

… and since many of you have been asking, yes, we plan to be back in early 2026 with a similar annual post as we continue to adjust our roadmap based on your feedback. Our goal is ultimately to continue building the best cross-platform framework with the best developer experience and feature set.

6. Speaking of you… the Flutter community and ecosystem are thriving! At Google I/O, we shared that nearly 30% of new free iOS apps are built with Flutter.

We’re constantly amazed by what you’re building. In 2025, we worked with some amazing companies to showcase how they’re building and betting on Flutter and Dart in big ways, including NotebookLM, teamLab, Agape, Universal Destinations & Experiences, Reflection.app, and GE Appliances.

Some highlights from this year include:

talabat is MENA’s leading on demand delivery platform. With millions of daily users, talabat uses Flutter to connects millions of customers to food, groceries, and more across 8 countries.

Google’s NotebookLM used Flutter to meet explosive user demand, delivering a delightful 4.8-star mobile experience in under 7 months.

teamLab uses Flutter in art and digital solutions, extending experiences to over 35 million people.

Flutter is woven into Agapé Wellness’s mission to help people feel close, even when apart.

7. As we continue growing, it’s important to understand How Flutter Works. So, we made a whole series on that.

Now that we know how it works, let’s make it more flexible for the future.

8. The work to decouple design systems and move Material and Cupertino into their own packages is underway, as announced in Flutter 3.35. This is a big step for the maturity and flexibility of the ecosystem. I’ll let Justin explain exactly what this means:

9. We know speed matters… so we made build_runner faster (two or more times in some cases!). John shares how we’re accelerating Dart code generation in this great video:

10. Another thing that sped up in 2025 is the pace of AI.

AI truly took center stage in the Flutter and Dart ecosystem. The Building Agentic Apps series and our announcements at Google I/O really set the tone, and we’re ending the year with two Flutter Flight Plans to prepare for take off into the future of apps. 2025 brought a massive leap in AI-assisted development. Read all about it in our Create with AI section of the Flutter documentation.

The Dart and Flutter MCP Server is now stable, empowering tools like Gemini CLI, Antigravity, and wherever you’re building with AI.
It’s been incredible to see Gemini in Android Studio supercharge Dart and Flutter development. And the Flutter Extension for Gemini CLI? Game changer for AI-assisted app building.

We’re also announcing the Flutter AI Toolkit v1.0, now ready for your production workloads. The Flutter AI Toolkit is a set of AI-related widgets to make it easy to add an GenAI features to your Flutter app. Since our last beta release, the AI Toolkit has migrated to the Firebase AI Logic SDK, adding new features along the way, including multi-turn function calling for agentic workflows, the ability to plug-in custom speech-to-text translators, and full support for turning LLM responses into widgets.

And speaking of new tools, Google introduced Antigravity, a new IDE experience aimed at boosting developer workflows with AI. We’re partnering with teams across Google to make Flutter development a world-class experience in all of the ways that Google AI is available. Watch the Observable<Flutter> livestream for more.

I want to share one more thing that we’re most excited about heading into 2026…

11. We launched the alpha of the GenUI SDK for Flutter on pub.dev, opening doors for creating dynamic UIs with LLMs.

GenUI is here to help you generate Flutter UI from natural language or structured data, potentially speeding up your development flow significantly. I’ll let Khanh dive into the details:

It’s fantastic to see the community already building on GenUI!
Check out two community members doing just that:

• Khalid built an AI Concierge Agent using GenUI, including a great recap video. Definitely check it out!
• dartantic by Chris Sells
  The dartantic_ai package is an agent framework designed to build multi-model agentic apps that run wherever Dart runs, including mobile, web, desktop, the CLI, or on the server. With the new 2.0 release, dartantic provides a ContentGenerator for implementation in the new Flutter GenUI project. This enables you to plug in any provider or model as well as taking advantage of advanced features like server-side tools — like web search and code execution — and media generation, including out of the box support for Google’s new Nano Banana Pro.

We’re working to make our GenUI SDK an industry leader.

One way is partnering with the teams behind ADK and A2UI, offering a more template-driven approach to UI generation. Rody’s talk explores how Flutter is leveraging ADK:

What are you building over winter break?

I ended that list feeling inspired and overwhelmed. There’s so much innovation it’s sometimes hard to keep up. But luckily, the holidays are a perfect time to tinker!

We’re all excited for the holidays for different reasons, some are headed skiing, spending time with loved ones, but it’s also a chance to dig in and learn something new.

If that’s you, we’d love to see what you build. Here are some ideas we’ve brainstormed:

1. Rebuild your personal site in Jaspr — and use Antigravity to make it easier to change up your tech stack
Take an existing website and use an agent to migrate it to Jaspr in a fraction of the time it would take manually, we’ve found Antigravity is very good at this.

2. Start learning about the future of Dynamic UI with GenUI
Build a GenUI Live Sketch Pad app where typed UI descriptions are rendered in real-time by GenUI. Or, if you build something else with the SDK, let us know on socials. The package is alpha so we’re actively looking for feedback on your experience using it!

3. Build an Agentic Workflow: Install the Dart MCP server and create a workflow that takes a screenshot of your app, gets a critique from Gemini, and applies the changes with hot reload.

4. Generate UIs from Thin Air: Take your workflow one step further by using Stitch to design a UI, then ask Gemini to write the Flutter code for you.

5. Become a Flutter contributor: Make your first contribution to Flutter. Find and fix an open documentation issue or tackle a “good first bug.”

6. Crush Performance Bugs: Use DevTools to profile your app’s performance. Identify and fix a performance bottleneck using tracing and your coding agent.

7. Modernize Your Codebase: Supercharge your existing Flutter project by refactoring it with Dart 3.10’s dot shorthands for cleaner, more concise code.

8. Exploring Gemini APIs in Flutter Build a voice app showcasing different Gemini API features using the Flutter AI Playground sample app which uses the Firebase AI Logic SDK.

9. Build Your Own Code Assistant: Train an agent on your GitHub repository to automatically manage your package dependencies or perform other tedious tasks.

10. Level Up Your App with the Ecosystem: Integrate a service from a Flutter-based business like Shorebird for over-the-air updates or Serverpod for a scalable backend.

Share your winter break projects with the community using the hashtag #Flutter2026.

Thank you for being a part of Flutter in 2025, see you in 2026!

With the foundations laid in 2025, we’re incredibly excited for 2026 as we push the boundaries of multi-platform development, dive deeper into AI-driven ephemeral experiences, and empower you to build the truly full-stack, cross-platform applications of the future.

A huge THANK YOU to the incredible Flutter and Dart communities. Your passion, feedback, and contributions made 2025 amazing. We feel so lucky to be a part of this community. 💙

Wishing you all a wonderful and innovative winter break. We can’t wait to see what you back and building in 2026!

The Top Ten Highlights from Flutter & Dart in 2025 was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, I’m Jaime Wren, a long-time developer tooling software engineer on the Flutter team. I’ve seen many shifts in the software industry over the years, but the whole industry has just stepped into a new Wild West at breakneck speed and this is both exciting and nerve-wracking.

In my opinion, we developers are complicated creatures driven by two forces: the need for productivity with our tasks and our inherent joy of programming itself. We thrive when we can slip into a fast, uninterrupted loop. To realize our full potential as developers, we need our entire toolchain to come together without introducing friction. As we transition into the Agentic Era, this need for a cohesive loop is non-negotiable; this is where Flutter has a distinct advantage.

I’ve tested a lot of AI tools these last few years, waiting for something that actually will save Flutter developers time rather than just shifting where time is spent. Nothing turned the corner for me until Antigravity, Google’s new Agentic IDE. It bridges the gap between raw model capability and actual engineering utility. I can finally see all of the infrastructure and tooling around the LLMs coming together to remove friction, rather than adding to it.

From my own testing, Flutter isn’t just “compatible” with AI tools like Antigravity; it is uniquely equipped to power them. Why? It comes down to Flutter’s strict structures and robust tooling. A core philosophy of Antigravity is a reliance on verification to know if a piece of code actually works. Flutter’s tools provide the immediate feedback that Antigravity’s agents need to validate these actions. All it takes to get started are a few settings to configure extensions and the MCP server.

Some cool things you can do

There are several cool things that I and other members of the Flutter community have learned to do with Antigravity to speed our development process. I’ve listed a few of them below, but I request that if you have any additional tips, please add them in the comments attached to this post.

Run tests & fix the problematic code

You can use Antigravity to run existing tests, fix any problematic code that is breaking your tests, and then verify that the tests are passing again. Here is the prompt that I use:

Execute the full test suite with `flutter test`. If failures occur,
fix them one by one. After applying each fix, re-run the full suite one
last time to ensure no regressions.

Fix errors and warnings

To prepare a PR before pushing it, you can use Antigravity to fix your errors, warnings and lints. Here is my prompt for this:

Run `flutter analyze` over my project. If it fails, fix any errors and 
warnings, then validate that they are fixed.

Discover lints and use them

There are a lot of lints out there but I don’t have time to research them all and figure out which ones are best for each project. I discovered that this cool prompt helps Antigravity quickly scan my project, suggest, and enable lints that make sense for it:

Read https://dart.dev/tools/linter-rules and identify rules I am
implicitly following but haven't enabled. Add them to analysis_options.yaml,
run flutter analyze, and fix any resulting violations.

Discover good pub.dev packages for my project

There are tons of pub.dev packages out there, and like the lints, researching them takes time and effort. I wanted a way to figure out which ones might be best for my projects while not leaving my IDE. This prompt worked well for me:

I need preferences to be shared from one instance of my app to the next,
please go search for this feature in https://pub.dev/, then run
`flutter pub get`, validate that the pub status is in a good status.
Then, find an example in my project to use this new package,
fix any issues that appear from `flutter analyze`, and fix them.
Finally, add a test for the new feature.

Thoughts about my journey with Flutter over the years and why I’m excited

I remember when Flutter entered the scene about 10 years ago. From the beginning and in my opinion, Flutter brought together the right language, framework and tools to be usable-by-default. An often overlooked factor in Flutter’s success is that these pieces weren’t bolted together from different vendors. Instead, the framework, rendering engine, CLI tooling, IDE tooling, language and ecosystem have always been driven by the same organization that has enabled these teams to coordinate to enable the usable-by-default cohesive vision. It’s because of this that I believe there is a “I finally get Hot Reload” moment for every new Flutter developer that makes them excited and hopeful because:

• The Flutter infrastructure is capable of patching code in milliseconds.
• The errors and warnings appear as you type and ensure that code is valid before a save occurs.
• The language helps prevent syntax errors and frictions.
• Obvious overflow errors are displayed as yellow and black stripes that signal layout issues that need to be addressed.

In the past year, the promise of generative AI in software development has been akin to the Wild West–demos and products have shown a lot of progress, but have not followed the usable-by-default mantra that has been core to Flutter’s success. With model improvements such as larger context windows that allow a model to actually read a project, and with concepts in the space converging, frameworks like Flutter have had an entry point to add value to agents and workflows. The Flutter team followed suit this year with the GenUI effort, the Dart and Flutter MCP Server, and AI rules suggestions.

Now, with Antigravity entering the arena, we have something that is more than a chatbot built into a window in your IDE. Antigravity inhabits the IDE, running commands and using knowledge about other Flutter and Dart projects to correctly follow your direction and take actions on your behalf in the project space.

As Flutter engineers, we take for granted the ability to know how to immediately run static analysis (dart analyze) or launch an app (flutter run) in a project we’ve never seen before. While none of these restrictions have limited what developers could create with Flutter, the natural consequence with LLMs and agentic tooling is that our collective uniformity gives these interfaces a huge leap forward in understanding and acting on the structure of our projects.

To reap the benefits of LLM tooling, agents require a verification through a positive feedback loop. If a model is producing value on every tenth piece of output and hallucinating the other nine instances, I might be amused, but I won’t be using the tool again. With Antigravity, verification is a core philosophy designed to give agents a feedback loop, allowing them to iterate before finishing work. This is where the benefit of existing robust Flutter tools comes into play, when using Antigravity to assist in writing code, the agent literally iterates until analysis is clean, formatting is consistent, tests pass, and the output from `flutter run` confirms that pixels are being drawn.

In summary

Without a doubt, these new AI tools are redefining how we identify as productive developers who enjoy the practice of programming. Equally without doubt, a robust, fast, uninterrupted loop will continue to be the centerpiece of that experience.

Antigravity doesn’t replace the programmer; it removes the drudgery that stands between your idea and reality. The loop is getting faster, the ramp is already built, and the future of Flutter is more usable — and more joyful — than ever.

Jaime’s build context: A Flutter developer’s thoughts about Antigravity + Tips! was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re thrilled to introduce GenUI SDK for Flutter, now available in alpha on pub.dev. This new SDK for Flutter helps you generate dynamic, personalized UI with Gemini (or other LLMs) to significantly improve the usability and satisfaction of your GenAI and agent-based user experiences, which also adheres to your established brand guidelines and using your own widget catalog.

Today’s app users expect not only beautiful and fast UIs, but also more dynamic, deeply personalized, and adaptive experiences. We are building GenUI SDK for Flutter, a suite of packages, to make it easier for you to build and deliver this new generation of experiences to all of your users.

A great example of a powerful generative UI experience built with Flutter and Gemini is the new experimental visual layout feature in the Gemini app (App Store, Play Store), rolling out today. It generates an immersive, magazine-style view of the information, complete with photos and modules. These generative elements don’t just look great; they are interactive and help you further customize the experience. Gemini’s new visual layout feature inspired us to build the GenUI SDK for Flutter, so that anyone can also build the same kinds of dynamic, interactive, generative experiences.

How does GenUI SDK for Flutter work?

At its core, the GenUI SDK for Flutter is an orchestration layer. It coordinates the flow of information between your user, your Flutter widgets, and an AI agent, transforming text-based conversations into rich, interactive experiences.

1. The app sends a request: The user provides a prompt (for example, “Help me plan a trip to Tokyo!”). Your app calls your AI agent with the prompt and additional information about the catalog of widgets it can use and compose together in response.
2. The AI agent generates both content and UI to display it: The AI agent generates a response, but instead of just relying on text, it uses tools provided by the GenUI SDK to describe the UI most suited to the content it generated.
3. UI is dynamically rendered: The GenUI SDK receives the response, deserializes it, and builds the appropriate widgets. Some are informational, some are layout, and some can be interactive (and might include sliders, buttons, or a date picker).
4. The user interacts with the dynamic UI: The user taps on buttons and other controls, which can trigger followup requests to the agent, which result in more UI updates, and so on.

This loop enables you to move beyond simple text responses. By defining your own custom widgets, the GenUI SDK for Flutter ensures the dynamically generated UI is compliant with your branding guidelines.

For a more detailed explanation and walkthrough of the GenUI SDK for Flutter, check out the following video:

The UI protocol under the covers

The GenUI SDK for Flutter is built around the upcoming A2UI protocol in collaboration with Google’s A2A team and the Opal team at Google Labs. A2UI is a new (soon to be open source) toolkit to facilitate implementing LLM-generated UIs in any framework. We use A2UI as the serialization format for UI that is generated by the LLM, and the GenUI SDK for Flutter is using an early version of an A2UI renderer.

How do I get started with building GenUI experiences?

We want to make it easy to experiment with the GenUI SDK for Flutter, so we’ve bundled in content generators for LLMs, sample apps to see it in action, and markdown docs for coding agents (and humans!)

• First, grab the main pub package for genui.
• Next, choose a content generator. The following are the content generator options we provide that support a variety of use cases:
  - Google Gemini API: Useful for experimentation and local testing as you’re mapping out your experience.
  - Firebase AI logic: Useful for production apps where interactions with the LLM are all in your Flutter client, without requiring a server. Firebase also makes it easier to ship your AI features securely since Firebase handles the management of your Gemini API key.
  - A2UI: Useful for client/server architectures where your agent is running on the server.
  - Build your own: Of course, you can also build your own adapter to connect to your preferred LLM provider. Expect more from us and the community soon.

To make it easy for your coding agent to build with the GenUI SDK for Flutter, we also included markdown docs. These markdown files teach your coding agent how to use the various GenUI SDK APIs.

The flutter/genui repo has sample apps that you can use to give you a good starting point for building GenUI experiences. The following video shows the Landscape design app , which gives you an example of a Flutter client interacting with a Python-based server using A2A (Agent-to-Agent) and ADK, with UI generated dynamically by the AI agent. In this demo app, the user can upload a picture of their yard, Gemini analyzes it, and then through the GenUI SDK for Flutter provides a custom UI for the user to enter their constraints and requirements for updating their yard’s landscaping. Once the user inputs their preferences, then they would see a result that takes into account their selections. This app demonstrates how a GenUI-based experience improves the collaboration between human and agent.

What’s coming next?

We are building the GenUI SDK for Flutter to help you deliver personalized, dynamic, AI-driven app experiences across mobile, web, and desktop from a single codebase. Here are some of the things we are considering for our roadmap:

• Agent Development Kit (ADK) plugin: turnkey integration with ADK.
• Expanded LLM framework support: Official adapters for other popular AI models and backend frameworks.
• Reduced perceived latency: Progressively rendering standard UI components as the LLM generates them, rather than waiting for the full response.
• Full-screen composition: Moving beyond individual widgets in a stream to let the LLM compose entire screen layouts and handle complex app navigation based on user intent.
• Dart bytecode: Providing true server-driven UI by allowing the backend to send entirely new widget logic over the wire, not just configurations for widgets already in your binary.
• Genkit integration: Integration with Genkit, an open-source AI framework.

The project is still in its early phases, so we’re excited to hear your thoughts and feedback. We can’t wait to see the GenUI experiences you build with Flutter!

Rich and dynamic user interfaces with Flutter and generative UI was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.