Improving AI with domain expertise

AI agents are generalists, but when it comes to professional Flutter development, “general” isn’t enough. To build production-grade apps, you need an assistant that understands the nuance of localization, the latest Dart language features, and how to add integration tests.

Today, we’re introducing Agent Skills for Flutter and Dart — a new way to give your AI tools domain-specific expertise.

Beyond the knowledge gap

One of the primary challenges in AI development is the “knowledge gap.” Flutter and Dart can launch new features more quickly than LLMs can update their fixed training data. As a part of how we are thinking about AI, we are looking for ways to not only address the knowledge gap but also ensure the agent applies that knowledge to achieve the task accurately and efficiently following the most optimal workflows.

A little over a year ago, Model Context Protocols (MCP) were the way to provide more AI domain-specific expertise. While MCP gives an agent access to specialized tools, an Agent Skill teaches the agent how to use those tools for a specific task. Think of it this way: MCP provides the hammer and nails (the tools), while a Skill provides the blueprint and the professional know-how to build the house.

Skills improve context efficiency through “progressive disclosure”. This is similar to how deferred loading works in Flutter, where apps can load libraries when needed, coding agents load Skills when they are relevant to what you’re trying to do .

For Flutter and Dart, these Skills provide tailored instructions for common workflows, and enhance the tools provided in the Dart MCP server to reduce the knowledge gap, which improves accuracy and lowers token usage.

A task-oriented approach

Our early experimentation revealed that Skills that only provide documentation don’t add as much value as we initially assumed. Since Flutter’s comprehensive and well written documentation is open-sourced, modern models are already highly capable of finding relevant information for most questions and tasks.

So, we pivoted to creating Skills that are “task-oriented”. Every skill in our GitHub Flutter Skills or Dart Skills repositories focuses on developer tasks like building adaptive layouts- by providing instructions for agents to reliably complete the task. We have conducted extensive manual evaluations to define our initial set of launched skills, and are working on an automated evaluation pipeline that we will share soon.

Using the Skills

To start using these Skills in your workflow, first install the Skill set in your project directory:

npx skills add flutter/skills - skill '*' - agent universal
npx skills add dart-lang/skills - skill '*' - agent universal

You will be asked to select the Skills you want to install. Pick all or select the specific ones you might find most useful.

Then choose the agent that you prefer to develop with.

Now, prompt your AI agent as usual. Here are 5 ways you can use these Skills today:

Skill #1: flutter-add-integration-test

Configures Flutter Driver for app interaction and converts MCP actions into permanent integration tests.

Add an integration test for the checkout flow in my app

Skill #2: flutter-setup-localiztion

Adds localization support to your Flutter project

Set up localization in my app

Skill #3: flutter-build-responsive-layout

Uses LayoutBuilder, MediaQuery, or Expanded/Flexible to create a layout that adapts to different screen sizes.

Ensure that the checkout screen uses repsonsive layout

Skill #4: dart-use-pattern-matching

Refactors code to use Dart’s pattern matching language capabilities where appropriate

Refactor my code so that it uses pattern matching where possible

Skill #5: dart-collect-coverage

Uses the coverage package to collect unit test coverage and generate an LCOV report.

Collect test coverage for my project

For more prompt examples, check out the readme Flutter Skills or Dart Skills repositories on GitHub.

Tell us what you think

These initial core Skills, designed to handle the most common Flutter development hurdles, are just the beginning. We want to build the future of AI-assisted development with you, our community. As you use these Skills and create new ones for your projects, file issues (Dart Skills repo, Flutter Skills repo), and let us know what additional work you’d like to see. We look forward to helping improve your productivity as you use these Skills!

Introducing Skills for Dart and Flutter was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Starting with the next stable Flutter release, 3.44, Swift Package Manager (SwiftPM) replaces CocoaPods as the default dependency manager for iOS and macOS apps. This means no more messing around with Ruby or CocoaPods installations just to get your app running!

CocoaPods is officially in maintenance mode, and its registry will permanently become read-only on December 2, 2026. While existing builds will still work, no new versions or pods will be added to the trunk after this date. To ensure that your apps continue receiving dependency updates and to provide access to the Swift package ecosystem, Flutter is transitioning to Apple’s supported dependency management solution: Swift Package Manager.

If you’ve already migrated your plugin(s) to use SwiftPM, read the “Plugin developers” section below for new migration requirements.

Here is how to manage the transition.

App developers

For app developers, the Flutter CLI handles the migration. When you run or build your iOS or macOS app, the CLI automatically updates your Xcode project to use Swift Package Manager. Check out the Flutter migration docs for app developers for more details.

If your app relies on plugins that haven’t adopted Swift Package Manager yet, Flutter will print a warning listing exactly which of your dependencies are unsupported. Flutter will temporarily fall back to CocoaPods for plugins that have not adopted Swift packages yet. Because CocoaPods support will eventually be removed entirely, if a plugin hasn’t updated and breaks your build, file an issue with the dependency’s maintainer to request Swift package support or find an alternative package.

We know that migrations can sometimes hit a snag. If SwiftPM causes a breaking issue, you can temporarily disable it for your project. Open your pubspec.yaml file, navigate to the flutter section, and set enable-swift-package-manager to false under the config block:

flutter:
  config:
    enable-swift-package-manager: false

If you opt out, please file a bug report using the Flutter GitHub issue template and let us know! Include the error details, a list of your plugins and versions, and copies of your Xcode project files to help us resolve the issue before CocoaPods is completely removed.

Plugin developers

For plugin authors who maintain an iOS or macOS plugin, you must add Swift Package Manager support if you haven’t already. So far, 61% of the top 100 iOS plugins have migrated. We need the remaining plugins on board so app developers aren’t stuck relying on a deprecated tool. To encourage adoption, packages without Swift Package Manager support now receive lower pub.dev scores until they migrate.

To add this support, add a Package.swift file and move your source files to match the standard Swift package structure. If you already migrated your plugin during the 2025 pilot, you need to complete one new step: you must add FlutterFramework as a dependency in your Package.swift file. Read the Flutter migration docs for plugin authors for full instructions.

Thank you for helping with this migration to Swift Package Manager. We hope this simplifies and improves your development experience on iOS and macOS!

Saying goodbye to CocoaPods: Swift Package Manager is soon the default in Flutter! was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our team has been hard at work this Spring, preparing to meet over 30,000 of you in Las Vegas for Google Cloud Next. For those who couldn’t make it in-person, here is a breakdown of the major highlights, announcements, and experiences from the Flutter and Dart team.

Big announcements

• Full-stack Dart: The team announced a preview of Dart support for Firebase Functions. Yep, that’s right: experience using Dart for both your frontend and backend. We also introduced deeper integrations with Firebase using the Dart Admin SDK to reduce context switching and improve development velocity.
  Check out the announcement blog, and documentation, and stay tuned for a full breakout session all about this feature at Google I/O.

Onsite experiences

• GenLatte: We built an AI-powered specialty coffee shop in the center of Next, created with Flutter GenUI. Attendees ordered drinks using a GenUI Flutter app, then watched baristas make a latte and print a custom nanobanana-generated image on the foam.

• Agentic mobile & web demos galore: The expo floor was packed with energy, including three Dart and Flutter demos, showcasing Fullstack Dart, GenUI, and a special appearance by our friends over at VGV.

• The Builder hub: This served as the “home base” for the developer community on the Expo floor. It featured dedicated booths for Flutter and our friends at Firebase and Go, providing a space for developers to connect with experts and explore new tools.

Key sessions & customer stories

• Developer keynote: Emma Twersky hosted the Developer keynote, showcasing how Flutter is part of Google Cloud’s big bet on the future of agents.

• Toyota & Talabat: Real-world enterprise success was a major theme. Abdallah Shaban took the stage alongside industry leaders to showcase how Flutter is transforming their core products. Toyota shared how they are revolutionizing automotive UX using Flutter for their next-generation infotainment systems, while Talabat demonstrated how they innovate faster and scale across the Middle East using the framework.

• Generative UI Deep Dive: Yegor Jbanov and Andrew Brogdon led a session on how to move beyond text-based chatbots by giving your agents the power to create their own UI.
  Stay tuned for Google I/O where this session will be available world wide on the Flutter YouTube channel.

• Building full-stack Dart: Rody Davis and Kevin Moore shared why you should be excited about today’s biggest announcement for Dart.
  Stay tuned for Google I/O where this session will be available world wide on the Flutter YouTube channel.

Our community is thriving

• GDE Summit: Held just before the main event, this summit brought together over 350 global Google Developer Experts (GDEs) to share feedback on Flutter with the core team, including a main stage session on Flutter GenUI.
• Developer meetups: Throughout the week, the Expo Meetup Hub hosted informal gatherings. Flutter helped host the Mobile Developers meetup, and we had a blast meeting community members from around the world and sharing why we think Flutter is the best way to build.

And that’s a wrap! But not for long… Register today for Google I/O 2026 where our team has even more planned. We can’t wait to surprise you. 😉

That’s a wrap: Everything Flutter at Google Cloud Next was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Despite Dart starting out as a web language and being used every day to build apps across platforms, including the web, our own websites (dart.dev, flutter.dev, docs.flutter.dev) relied on a fragmented mix of non-Dart tools. That’s finally changed. We’ve migrated all three websites to use Jaspr, an open-source framework for building websites with Dart.

The result is a unified stack with a consistent developer experience where contributing only requires Dart. If you’re curious about building web experiences with Dart beyond standard Flutter web apps, this post explores what motivated our migration and how Dart and Jaspr made it all possible.

A fragmented and unfamiliar technical stack

While the previous setup of our sites worked, their implementations were fragmented, and required increasingly more effort to update the sites to meet our evolving needs. The documentation sites were built with Eleventy, a Node.js static-site generator. Meanwhile, flutter.dev had a completely separate setup, powered by Wagtail, a CMS built on Python and Django.

This fragmentation meant that anyone wanting to contribute to or maintain our sites needed additional experience and tooling outside the Dart ecosystem: Node.js tooling for one set of sites, Python for another. While some surrounding infrastructure and interactive components were already built with Dart, the separate ecosystems limited code sharing, significantly increased set-up and contribution friction, and grew increasingly complicated.

We wanted to change that. We wanted a single, unified stack built on the language and tools our team and community already know. We also had growing ambitions and needs for interactivity on our sites, from richer code samples to quizzes for tutorials. Our existing setups made each new interactive element an uphill battle, often requiring one-off imperative DOM logic.

Finding a unified solution in Jaspr

Jaspr is a versatile Dart web framework that supports client-side rendering, server-side rendering, and static site generation. Beyond being a traditional DOM-based (with HTML and CSS) web framework and being written in the language we already know, Jaspr stood out for a few reasons:

Flutter skills transfer directly. The Jaspr framework and its component model were designed to feel natural and familiar to any Flutter developer while being compatible with the DOM model of the web. If you’ve written a Flutter widget before, you can read this:

class FeatureCard extends StatelessComponent {
  const FeatureCard({
    required this.title,
    required this.description,
    super.key,
  });

  final String title;
  final String description;

  @override
  Component build(BuildContext context) {
    return div(classes: 'feature-card', [
      h3([.text(title)]),
      p([.text(description)]),
    ]);
  }
}

With Jaspr, contributors can directly apply the Dart and Flutter experience they already have to a new platform, significantly lowering the barrier to entry for team and community members who want to improve our documentation and websites.

Seamless support for partial hydration. One major underlying reason for this exploration and migration was to make it easier to build and integrate interactive experiences on our sites. Jaspr’s built-in support for partial hydration allows each page to be prerendered as static HTML, then the client-side logic is attached only for the components that need it. This is perfect for websites like ours, where the majority of the content is static and only small pockets of interactivity are needed, ensuring quick page loading and good SEO.

Jaspr Content for Markdown-driven sites. Jaspr also provides Jaspr Content, a package that supports quickly building content-driven sites. It provides enough out-of-the-box functionality to create a running Markdown-based website in just a few minutes while also being easy to expand and customize extensively. This built-in functionality saved a significant amount of time while the customizability enabled us to keep our original functionality and content practices intact.

What we gained

The migration brought all the benefits we imagined and more, both for the sites themselves and the contribution experience.

A singular, unified toolchain. With everything written in Dart, not only do you need just one SDK to contribute, we also gained access to Dart’s powerful, unified tooling. We can manage all dependencies with dart pub, format code with dart format, analyze it with dart analyze, and then test it with dart test. Managing the site now requires only one set of tools to know, one set of conventions to follow, and one ecosystem to stay current with, and it’s the one we’re already most familiar with.

A stack our contributors already know. Our websites have a lot of contributors, from engineers, to technical writers, to passionate community members. We want everyone to be able to contribute, but the fragmented setup was complex and unfamiliar to most. Now the sites are implemented as standard Dart projects, and if you know Dart, you have everything you need. We hope this lowers the barrier for team and community members who want to help improve Flutter and Dart’s documentation.

Less had to change than you’d expect. With Jaspr Content supporting most of what we needed out of the box, such as templating support, Markdown, and data loading, our content and writing workflows barely needed to change. Nor did our styles, as we already used Sass, a CSS extension language, which is actually implemented in Dart, and therefore requires an even simpler setup than we had before.

The collaborative migration

Overall, the site migration to Jaspr and Jaspr Content went well, but there were, of course, some challenges along the way. We occasionally ran into issues as well as opportunities for improvement with both Dart’s web tooling and Jaspr itself.

What made the migration possible was Kilian, Jaspr’s creator and maintainer. Beyond creating Jaspr, he supported us throughout the migration. He migrated components as early proofs of concept, responded to issues, shipped fixes, improved the developer experience, and even built out Jaspr Content with our websites as a driving use case. To support this ongoing effort and formalize the collaboration, we partnered with Kilian and his consultancy, Netlight, to help us migrate the rest of our web presence and continue investing directly in Jaspr. It was a genuinely collaborative process. Our sites and Jaspr both grew as a result.

In the Dart and Flutter ecosystem, the community is everything and what Kilian has provided to the community with Jaspr is a great example of that. Jaspr has shown itself to be a powerful and modern web framework that is well maintained, responsive to feedback, and ready for you to try out. Thank you, Kilian!

To hear Kilian’s perspective on building and maintaining the framework, check out his article: Jaspr: Why web development in Dart might just be a good idea.

Dart and Jaspr growing together

One of the most rewarding aspects of building on an all-Dart stack is that improvements to the Dart language and surrounding tooling benefit everything. Not just your Flutter apps, but your websites too. Here are a few recent Dart features that have directly impacted and improved the experience of building with Jaspr.

Dot shorthands make component trees cleaner. Dart 3.10 introduced support for a dot shorthand syntax enabling you to omit the type name from static member accesses when they can be inferred from the context. Kilian took advantage of this by consolidating several component constructors onto the Component class and designing them to work naturally with the new syntax:

Component build(BuildContext context) => const div([
  // After the API changes:
  h1([Component.text('Dash says hi!')]),
  Component.fragment([
    Component.text('First element'),
    Component.text('Second element'),
  ]),
  Component.empty(),

  // With dot shorthands:
  h1([.text('Dash says hi!')]),
  .fragment([
    .text('First element'),
    .text('Second element'),
  ]),
  .empty(),
]);

The result was a more consistent API with better discoverability and a concise syntax that still works in constant contexts. Best of all, Jaspr’s CLI comes with a jaspr migrate command that automatically handled the migration to the new API as well as other changes.

Null-aware collection elements simplify conditional rendering. Dart 3.8 added support for null-aware collection elements, providing a clean syntax to conditionally include non-null values in collections. In Jaspr code, where you’re regularly composing lists of child components, they offer an elegant way to handle conditional UI elements:

Component build(BuildContext context) => div(classes: 'header', [
  h1([.text('Welcome to Flutter!')]),

  // Before null-aware collection elements:
  if (eventBanner != null) eventBanner!,

  // With a null-aware collection element:
  ?eventBanner,
]);

No more verbose if checks and not-null assertions cluttering your component trees.

Modern, lightweight JS interop and compilation to WebAssembly. To enable efficient access to modern web APIs and compilation to WebAssembly, Dart 3.3 introduced new JS interop libraries as well as package:web. Jaspr was quick to migrate to and support the new APIs, ensuring Jaspr developers could benefit from their new capabilities and build modern Dart apps. Building on this, Jaspr additionally supports experimental compilation to WebAssembly when running on the client. In fact, dart.dev already uses and benefits from this support on compatible browsers.

A helpful, integrated analyzer plugin. For a while, Jaspr had a helpful linting package built on top of package:custom_lint, helping developers write idiomatic and correct Jaspr code. With the release of official analyzer plugin support in Dart 3.10, Jaspr migrated to adopt the feature. The plugin provides a great example of what is possible, providing Jaspr-specific diagnostics and code assists. For example, it can convert between component types or quickly wrap a component with another, similar to the assists you might already be used to with Flutter.

None of these features were built specifically for Jaspr. They’re improvements to the Dart language and tooling that benefit the entire ecosystem, not just Flutter. For some of them, Jaspr was able to immediately take advantage, while others required framework changes from Kilian and contributors to unlock their potential. Either way, it’s clear that Dart keeps evolving and that evolution continues to open up improvements and possibilities for everything built with it, including Jaspr and Flutter.

What’s next and how to get started

We’re not done yet. Now that our websites share this new technical stack, we can start to share more code, build new interactive features, and continue to improve Dart’s web development story. We’re also migrating the Dart and Flutter blogs from Medium to being directly hosted on our Jaspr-powered sites. You’ll hopefully be able to read this very post there soon.

If you’re a Dart or Flutter developer curious about building websites with the skills you already have, there’s never been a better time to try. Jaspr is a great option for content-heavy sites, such as landing pages and documentation. It can even naturally integrate with your Flutter web apps. Try it out now on Jaspr’s online playground (which is also built with Jaspr!) or by following the Jaspr quickstart.

Or, if you’re interested in contributing to the Flutter or Dart documentation sites, the barrier to entry just got a lot lower. Now with Jaspr, all you need is Dart.

We rebuilt Flutter’s websites with Dart and Jaspr was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Flutter team has been hard at work preparing for Google Cloud Next and Google I/O this Spring. I strongly believe in the power of community, whether digital and online, or in-person and interactive. For Flutter, that means a truly global community and hundreds of thousands of developers around the world. Some of the most impactful moments of my career have come from those — community thrives in community-led events.

As we kick off our year and the upcoming release of Dart 3.12 and Flutter 3.44, the Flutter team is setting out to meet as many of you as possible, around the globe. Our mission is to build the most productive app framework and language for high-performance, full-stack, multi-platform applications and ephemeral experiences. And doing that means hearing from you.

To be transparent and open, we’ve updated the list of events where our team will be present, or we have sponsored the presence of our Google Developer Experts. Our developer relations team is constantly engaging with developers, founders, enterprises, and builders by organizing: customer and partner advisory boards, our meetup organizer network, Flutteristas, the Flutter consultants program, Google Developer Experts, and Google Developer Group organizers.

If you’ve been looking for an opportunity to connect with the team, see a live demo, or give us feedback in person, you can find us at the following events for the rest of the year:

April

• Google Cloud Next (Las Vegas, NV) — April 22–24

May

• Flutterconf Spain (Malaga, Spain) — May 08
• Google I/O (Sunnyvale, USA) — May 19–20
• Flutter Flow Developers Conference (San Francisco, CA) — May 27–28

June

• mDevCamp (Prague, Czechia) — June 03
• Flutter Tech Summit (Warsaw, Poland) — June 09
• Config (San Francisco, CA) — June 23–25
• I/O Connect Berlin (Berlin, Germany) — June 25

July

• I/O Connect Bengaluru (Bengaluru, India) — July 14
• Fluttercon USA (Orlando, FL) — July 16–17

August

• Ai4 (Las Vegas, NV) — August 4–6
• I/O Connect China (China) — TBD
• RenderATL (Atlanta, GA) — August 12–13

September

• Flutter & Friends (Stockholm, Sweden) — Sept 3–5
• FlutterConf LATAM (Cancún, México) — September 22–23

October

• next.app devcon (Berlin, Germany) — October 7–9
• All Things Open (Raleigh, NC) — October 19–20
• Flutter Kaigi/Ninjas (Tokyo, Japan) — October 29–30
• Google for Developers events (DevFest and Build with AI) — Throughout Fall and Winter 2026.

Stay tuned and bookmark Flutter.dev’s Events page as we continue to add more events throughout the year.

Are you hosting a Flutter event or meetup not listed here? Reach out to our team to see if we can attend if we’re already in your area — we want to meet and share with as many of you as possible!

Come meet the Flutter core team on tour in 2026 was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.