What a week! Google I/O 2026 is officially in the books. It’s time to recap the whirlwind of updates for the Flutter and Dart communities.

The onsite star was a full-sized specialty coffee shop in the absolute center of Google I/O, built entirely with Flutter GenUI, where nanobanana-generated artwork was printed right on the coffee foam.

But don’t worry if you weren’t able to make it to Shoreline. We recorded every moment and more, now available for on-demand viewing on the Flutter YouTube channel.

📺 Watch every session

From keynote to tech session, we can’t wait for you to see every moment of Flutter from I/O 2026.

🌟 What’s new in Flutter

A few of the highlights:

• Flutter 3.44 & Dart 3.12: These releases brought major advancements with Agentic Hot Reload, GenUI with a showcase from Li-Te Cheng on the DeepMind team, Toyota has embedded Flutter in the 2026 RAV4, improved rendering performance with Impeller, decoupling of Material and Cupertino UI from the framework, Swift Package Manager is on by default for iOS and macOS, Canonical now leads the Flutter desktop roadmap, and significant updates to platform-specific fidelity with HCPP.

🌟 Vibe once, run anywhere with Antigravity and Flutter

• What you’ll learn: A technical introduction to Antigravity, a new IDE focused on building with agents. You will learn how to leverage “vibe-based” development to create experiences that adapt and run across all platforms seamlessly.
• Why it matters: It provides the architectural roadmap for shifting from “hard-coded” layouts to “vibe-based” generative experiences, allowing your app to adapt to user needs on the fly.

How to write really good Flutter code

• What you’ll learn: Principles for writing high-quality, maintainable Flutter code, and how modern tooling — including Widget Previews, DevTools, MCP servers, and Skills make it easier than ever to build great apps.
• Why it matters: AI can write code faster than ever, but best practices and robust tooling provide the quality control needed to keep Flutter applications maintainable over time.

Introducing the Full-stack developer series

• What you’ll learn: Not a lot, but this less-than-two-minute video is fun and introduces the four episode series.

Full-stack dev series #1 — Flutter + A2UI = GenUI

• What you’ll learn: A technical deep dive into the building blocks of Generative UI, with a top-to-bottom conversion of a text-based chatbot into an agent that creates its own UI and understands how you interact with it.
• Why it matters: Not only can GenUI turn a slow, text-based experience into a delightful one, but it opens up new user experience patterns in which static designs and route hierarchies become flexible, on-demand UI tailored to individual users and their goals.

Full-stack dev series #2 — Full-stack Dart

• What you’ll learn: How to unify your app’s tech stack and eliminate context switching by using Dart for both frontend and backend logic. This video builds a complete serverless application live, using Dart for Firebase Cloud Functions.
• Why it matters: This approach improves development velocity and reduces costs by allowing teams to share logic, tooling, and expertise across the entire application stack.

Full-stack dev series #3 — Introducing Genkit Dart

• What you’ll learn: How to create Genkit flows that power your app’s backend and frontend, and discover the essential security steps needed to protect your AI endpoints. This video covers everything from initial setup to implementing rate limits and caching to keep your project secure and cost-effective.
• Why it matters: Genkit bridges the gap between prototyping and shipping reliable AI applications. It simplifies building AI into existing code by providing a unified SDK across multiple languages and models, alongside robust debugging and monitoring tools. Genkit works as a backend, but also in your Flutter app!

Full-stack dev series #4 — Everything you don’t know about building great native apps with Flutter

• What you’ll learn: All the small additions we’ve made to Flutter to make a compelling native experience, from embracing native workflows, supporting new languages for Dart binding generation, or new rendering methods that balance the needs of host UIs and Flutter
• Why it matters: Flutter is not about finding a “lowest common denominator.” It is about providing a high-fidelity, high-performance framework that respects and enhances the native platforms it runs on.

…and that’s it!

Thank you all for joining along as we brewed up one of our favorite I/Os yet. Stay tuned for more blog posts, videos and docs about everything we announced, and all of the community events we’re attending starting next month.

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

Empowering developers at Google I/O 2026

Flutter 3.44 is here, and it’s a big one! This release celebrates a milestone in the Flutter timeline: Hybrid Composition++ for Android, Swift Package Manager as the new iOS/macOS default, and improved Vulkan support for Impeller. We’re previewing multi-window desktop support with Canonical as our new lead maintainer, and embarking on a major architectural evolution by decoupling Material and Cupertino from the core framework. We’re redefining UX for agentic user experiences with GenUl and reimagining developer experience with Agentic Hot Reload and Dart & Flutter Agent Skills. Flutter is empowering the next generation of apps-everywhere from the 2026 Toyota RAV4 multimedia system to the upcoming LG webOS SDK. We’re so excited to share all of the news and updates with you; welcome to Flutter 3.44!

This year’s Flutter theme at Google I/O is: Flutter is everywhere, everyday, built by everyone, for everyone.

“Everywhere, everyday” stems from a Tuesday realization I had using an app on my phone: Flutter apps were part of my life everywhere, from tracking my meals in the Bay Area to shopping while I was in Japan. The numbers back this up: The pub.dev ecosystem is more popular than ever, with over 1.3 billion package downloads, in the last 30 days alone. Flutter is now the second most popular development SDK for mobile on both major app stores with over 1.5 million monthly developers, a 50% increase in just one year.

“Built by everyone, for everyone” reflects a chat with my Google I/O co-host, Kate Lovett, about the joy of our global community. Our 1,700+ committed and passionate contributors are the engine behind this progress, landing 5,800 changes in the core repository this past year. In this release cycle alone, we’ve landed 972 commits from 178 unique contributors, including 61 new contributors landing their first commits. Our community remains the lifeblood of Flutter, ensuring it truly is built by everyone, for everyone. THANK YOU!

There are lots of changes to tell you about. You might also want to check out the changes in the Dart 3.12 release.

Developer experience

We want to make the experience of building apps with Flutter as productive as possible, whether you’re writing code by hand or iterating with your favorite coding agent. In this release, we are improving upon our existing suite of developer tools and introducing new ones to augment your development workflows.

DevTools performance improvements

We’re introducing fine-grained analysis to boost efficiency and we’ve made performance improvements for analysis of projects with many files or directories.

We’ve also added more stability and performance improvements to Flutter DevTools, including a change to use WASM by default, which makes DevTools snappier and more responsive.

Learn more: Release notes for DevTools 2.55.0 and 2.57.0.

Widget Previews (experimental)

This release brings further performance improvements and features to the Widget Preview environment:

• Preview detection rewrite: The detection logic now utilizes the Dart Analysis Server, significantly reducing memory usage by the flutter tool. For IDE users, overall memory usage should be reduced by up to 50%.
• Preview filtering: It’s now possible to filter previews by group, name, and script and package URIs, making it easier to work in projects with many previews. Special thanks to community member NamanGoyalK for this contribution!

Learn more: Flutter Widget Previewer

Rosetta-free native Apple Silicon support

Mac developers running Apple Silicon chips no longer need to install the Rosetta translation layer to run Flutter. All macOS command-line tools, including our iOS device communication binaries, have been updated to run natively on ARM. This update arrives ahead of Apple’s planned deprecation of Rosetta translation support, ensuring your development environment is future-proofed on Apple hardware. Looking ahead, a future release of Flutter will end support for Intel x86 Macs entirely. If your team still relies on Intel-based Mac hosts for development, you should begin planning your hardware migration.

Learn more: Using Intel-based apps on a Mac with Apple silicon (support.apple.com)

Reimagining developer experience in an AI-driven world

Over the last year, the Dart and Flutter ecosystem has witnessed an explosion of agent-based tools like Antigravity, Gemini CLI, Claude Code, and Cursor which are fundamentally evolving the developer’s role into one of architecting and coordinating with agents. To support this transition, we’ve focused on enhancing our developer experience foundation and introducing new tools to augment your development workflows.

Seamless coding agent integration with Agentic Hot Reload

In a big leap forward for AI-assisted development, we are launching Agentic Hot Reload: The MCP server and your favorite coding agent will now automatically find and connect to running Dart and Flutter applications. This means coding agents like Antigravity can now hot-reload your running app out of the box! When you prompt your AI assistant to edit a UI, the agent writes the code and triggers a hot reload automatically to show you the result instantly, no manual setup needed. Go ahead and try it! We’ve also…

• Hardened dependency search: Agents can now read and search files inside package dependencies safely, without requiring full access to your local pub cache.
• Consolidated tools: We consolidated our MCP tool definitions, significantly reducing token costs for your agent workflows.

Check out Agentic Hot Reload in action:

We also recently launched Agent Skills for Dart and Flutter, equipping your coding agents with task-oriented, production-grade domain expertise. These skills level up your coding agent and help you save tokens when completing tasks such as adding integration tests or setting up localization, while adhering to recommended best practices.

Learn more: Introducing skills for Dart and Flutter, Dart and Flutter MCP server

AI on every screen with Flutter: Building the next generation of AI-native apps

As AI-driven features evolve from simple content summaries to fully agentic assistants, we are focused on expanding the Dart and Flutter ecosystem to provide the infrastructure needed for these experiences on every platform.

Firebase AI Logic

Firebase AI Logic enables you to call the Gemini API client-side from your Flutter apps.

MacroFactor is a Flutter app that uses Firebase AI Logic to connect directly to a Gemini model and leverage its multimodal capabilities. I’ve been using it to track my meals, simply by taking a picture. It’s a great example of an app that’s used AI to turn a tedious chore into a delightful, seemingly magical user experience.

Firebase AI Logic now features Server Prompt Templates, removing the need to embed prompts directly into your application code.

Firebase Agent Skills for Flutter are now available, providing step-by-step guidance to help you build full-stack Flutter and Firebase applications more effectively.

Learn more: MacroFactor revolutionizes nutrition with AI for 400k+ users with Firebase, Flutter, and Gemini

Genkit Dart in preview

We’re also excited to share the preview launch of Genkit Dart, an open-source framework for building full-stack, AI-powered and agentic apps. It has a model-agnostic API that supports providers like Google, Anthropic, and OpenAI. It comes with everything you need to go from prototype to production, including type-safe structured output, tool calling, multi-turn conversations, and built-in observability.

You can run Genkit Dart server-side or client-side in Flutter apps, too!

import 'package:genkit/genkit.dart';
import 'package:genkit_google_genai/genkit_google_genai.dart';

void main() async {
 final ai = Genkit(plugins: [googleAI()]);

 final response = await ai.generate(
   model: googleAI.gemini('gemini-flash-latest'),
   prompt: 'Why is Dart a great language for AI
            applications?',
 );

 print(response.text);
}

Learn more: Genkit Dart: Build full-stack AI apps with Dart and Flutter

Gemma 3n Impact Challenge

We’re incredibly proud to see Flutter developers pushing the boundaries of what’s possible with AI. A huge congratulations to Tommaso Giovannini, creator of Gemma Vision, and Guido Marangoni, creator of Vite Vere, for their first and second place wins in the Gemma 3n Impact Challenge last year. Both chose Flutter to build life-changing tools:

• Gemma Vision helps those with visual impairments perceive the world
• Vite Vere assists those with cognitive disabilities in completing tasks in their daily lives.

Learn more: Gemma 3n Impact Challenge winners

Gemma 4

Gemma 4 recently launched, it’s a lightweight, on-device model purpose-built for advanced reasoning and agentic workflows, cost, on-device data constraints, or network constraints. Its multimodal capabilities are fantastic, and I’ve been especially impressed by its ability to do multi-step planning and chaining tool calls.

Historically, managing these on-device models across diverse hardware was complex. This is why I’m so excited about LiteRT-LM.

Learn more: Gemma 4

LiteRT-LM for Flutter

As I was digging into the code for both Gemma Vision and Vite Vere, it was inspiring to see both leveraging the flutter_gemma, a plugin available from pub.dev, to integrate with Gemma.

It’s only going to get better: we’re excited to share that full LiteRT-LM support for Flutter is coming soon to the flutter_gemma package.

LiteRT-LM is Google’s production-ready, high-performance, open-source inference framework. This will abstract hardware differences away and enable you to run powerful on-device AI models like Gemma 4 across devices, all while ensuring peak performance with GPU and NPU acceleration across all 6 of Flutter’s stable platforms: Android, iOS, Web, Windows, Linux, and macOS.

Learn more: flutter_gemma package and LiteRT-LM.

Flutter + A2UI = GenUI

When it comes to AI-driven user experiences, we can all agree that we’re exhausted by walls of markdown — or worse, plaintext.

Generative UI, or GenUI, is a UX paradigm where AI constructs and responds with real-time UI, rather than just text, as seen here in the Hatcha Demo app.

Over the last year, our GenUI team has been pushing this forward as a project partner defining the emerging A2UI protocol. A2UI is an open-source protocol from Google that defines how an agent and a client collaborate on the composition and state of a user interface.

Since launching the Flutter GenUI SDK late last year, we’ve seen incredible momentum, with package downloads up 500% since the beginning of the year.

A standout example is Catagay Ulusoy’s Finnish it (Google Play store, Apple store). This app doesn’t just create custom lesson plans to help users learn Finnish; it dynamically composes the perfect UI on the fly for each lesson. If you caught the Cloud Next Developer Keynote last month, you might’ve seen Flutter DevRel lead Emma Twersky give the app and Catagay a well-deserved shoutout!

Learn more: genui package

The Visual Layout experiment

Li-Te Cheng and his team from Google DeepMind were pioneers in the GenUI space. Remember this demo that made its rounds within Flutter circles way back in 2023 because of the red debug banner in the demo? Yep, that was Li-Te’s team!

He joined us for the What’s New in Flutter talk to share his experience building the Gemini App’s “Visual Layout” experiment with Flutter. Here’s the web version:

He touched on why his team tends to reach for Flutter as their UI toolkit of choice… Hint: It’s the same reason that we all love Flutter:

• Beautiful UI
• Productive developer experience
• Multiplatform support
• An architecture that is perfectly suited for GenUI (Li-Te’s words, not mine! 😉)

Here were his 3 key takeaways that you can use for your own GenUI projects:

1. Lean on opinionated frameworks for AI consistency
2. Use an “AI critic” loop to ensure reliable outputs
3. Balance speed and control with templates.

In closing, Li-Te challenged us to go beyond walls of text and chatbots, and instead, build rich, interactive, delightful experiences.

Learn more: GenUI SDK for Flutter and, if you want a guided tutorial, try out the Codelab.

Android support

Googlebook and peripheral support

Flutter is already equipped to handle the new Googlebook laptop, powered by Gemini. Because Flutter targets Android’s large-screen guidelines, apps handle external hardware inputs naturally. Trackpad scrolling, mouse hover states, right-click menus, and keyboard shortcuts work by default. Because Flutter has mature desktop support across macOS, Windows, and Linux, Flutter apps will feel native and responsive on a Googlebook rather than looking like stretched mobile ports. Existing mobile apps will feel at home on a Googlebook without requiring an extensive rewrite.

Learn more: Introducing Googlebook, designed for Gemini intelligence

Android 17

Android 17 is on the horizon, and the team is actively testing Flutter against the latest Android 17 betas to ensure your apps continue to work as expected. We’re also proactively integrating the newest security and usability features like Local Network Protections and safe Dynamic Code Loading.

You can monitor our ongoing progress on GitHub. We encourage you to download the Android 17 beta and start testing your apps today. If you run into bugs or notice any missing features, please file an issue!

Learn more: Android 17 GitHub project

Hybrid Composition++ for Android

Embedding native Android components like web views or maps into a Flutter app has historically forced developers to choose between frame rate and fidelity. Older rendering strategies struggled with screen tearing during scrolls, broken text input, or high CPU overhead.

Flutter 3.44 introduces Hybrid Composition++ (HCPP) as an opt-in feature to solve these problems. Instead of relying on offscreen buffers or forcing the Flutter engine to process native views, HCPP delegates layer compositing directly to the Android OS. The process takes advantage of the Vulkan graphics library’s low level access using hardware buffer swapchains and SurfaceControl transactions to synchronize the Flutter UI with the native Android views.

The result is high-performance scrolling and accurate touch input. It also brings reliable support for SurfaceView components, which presented challenges for older modes.

HCPP has Android API and hardware requirements, so not all devices can use HCPP even when opted in. There are no new APIs to adopt, and you simply need to enable the flag to upgrade your existing platform views. You can test the new mode before it becomes the default rendering mode in the future by passing the --enable-hcpp flag to your run command, or by adding the configuration flag to your AndroidManifest.xml file:

<meta-data
  android:name="io.flutter.embedding.android.EnableHcpp"
    android:value="true" />

Learn more: Hosting native Android views in your Flutter app with Platform Views

Android display corner radii support

To help you build pixel-perfect layouts on modern mobile devices, Flutter now integrates directly with Android hardware to support display corner radii (#179219). Flutter can now query the physical and logical corner radii of the device’s display and expose this information through MediaQuery. This allows your UI to accurately respect the hardware’s geometry, ensuring content is never clipped on aggressively rounded screens.

Learn more: MediaQueryData.displayCornerRadii

Android Gradle Plugin 9.0 and built-in Kotlin

Prior to Android Gradle plugin (AGP) 9, Android app and plugin developers had to manually add the Kotlin Gradle plugin (KGP) to their build files so the system could understand and compile Kotlin code. As of AGP 9.0, the Android build system handles Kotlin natively. Because the build system already knows how to process Kotlin, manually adding the separate KGP now creates a conflict and causes a build failure. This breaking change affects apps and Flutter plugins that apply KGP.

The Flutter team added temporary backwards compatibility to keep existing projects building safely. Support for manually applying KGP will be removed in a future release.

Instructions for app developers

If you develop Flutter apps, you need to update your Android build files to remove the separate Kotlin Gradle plugin (KGP).

Note: If your migrated app uses a Flutter plugin that still applies KGP, your build will fail. Since only the plugin author can fix this, please report the issue to the plugin author.

Learn more: For full step-by-step instructions, see the app developer migration guide.

Instructions for plugin authors

The migration process for plugins requires similar Gradle file changes, plus an important version constraint update. To ensure compatibility, you must update your pubspec.yaml file to set a minimum Flutter version constraint of 3.44.

Learn more: For the full checklist, refer to the plugin author migration guide.

ABI filtering changes

ABIs determine which device hardware architectures (like ARM or x86) your compiled app supports. Flutter used to apply ABI filters programmatically to every specific build type, but now configures them once in the base defaultConfig block. Because the AGP 9 combines the default configuration with specific build types and flavors instead of overriding it, using custom ABI settings requires an extra step.

If your app uses custom abiFilters inside specific build types or product flavors, you now need to pass the -Pdisable-abi-filtering=true flag when building or running your app.

Learn more: For more details, see the flavors guide.

iOS support

Swift Package Manager is now the default for iOS and macOS

Starting with Flutter 3.44, Swift Package Manager (SwiftPM) replaces CocoaPods as the default dependency manager for iOS and macOS apps. The Flutter CLI handles this migration automatically. When you build or run your app, the CLI updates your Xcode project to use SwiftPM, removing the need to manage Ruby or CocoaPods installations!

Learn more: Say goodbye to CocoaPods: Swift Package Manager is soon the default in Flutter!

Add-to-App integration is also more flexible. If you embed Flutter into an existing iOS application, the new flutter build swift-package command packages your Flutter app or add-to-app module as a Swift Package for easy consumption in your native project.

Learn more: View the updated documentation to learn how to integrate with SwiftPM.

If your app relies on plugins that still require CocoaPods, the Flutter CLI will print a warning and temporarily fall back to CocoaPods for those dependencies. We recommend asking those package maintainers to update, as CocoaPods support will eventually be removed entirely. To encourage ecosystem adoption, packages with SwiftPM support are now awarded additional points in pub.dev scoring.

If you maintain an iOS or macOS plugin, you need to add SwiftPM support to your package. If you migrated during the 2024 pilot, make sure you also add FlutterFramework as a dependency in your Package.swift file.

If SwiftPM causes a breaking issue for your project, you can temporarily disable it by setting --enable-swift-package-manager: false in your pubspec.yaml. If you use this opt-out, please file a bug report on GitHub with your Xcode project files so we can investigate. Please note that this opt-out feature will eventually be removed.

Learn more: Swift Package Manager for plugin authors

Flutter supports UIScene

Starting with iOS 13, Apple introduced the “Scene”-based lifecycle to support multi-window experiences. During WWDC 2025, Apple announced that apps built with the latest SDK will soon be required to use the UIScene lifecycle to launch. This update is critical in meeting Apple’s requirements for upcoming iOS versions.

There are no new changes in Flutter 3.44, but we would like to remind you to migrate before Apple starts enforcing this new API by default. The Flutter CLI automatically migrates your app if your AppDelegate hasn’t been customized. However, if your code tinkers with UI lifecycle events, you should follow the full migration guide.

Learn more: UISceneDelegate migration guide

iOS predictive text (experimental)

We are introducing experimental support for native iOS inline predictive text for text input fields (#183650). This feature is off by default, but you can opt-in and test it by enabling TextField.enableInlinePrediction. When enabled, users typing in your app can accept iOS-predicted text (for example, typing “My n” and accepting “ame”) by pressing the Space key. Please note that the visual styling for this predictive text is still under active polish, and we appreciate your feedback as we finalize this feature.

Learn more: TextField.enableInlinePrediction

Web

Accessibility

Accessibility and user preference parity have also been greatly enhanced, featuring out-of-the-box support for the browser’s prefers-reduced-motion setting to automatically disable animations, alongside immediate screen reader feedback for form validation errors using aria-description.

Learn more: prefers-reduced-motion CSS media feature (mozilla.org)

Platform and tooling

Development workflows and browser integration have never been smoother. The engine now handles autofill in iOS 26 Safari by reusing DOM forms across focus shifts, while refining web scrolling and keyboard event synthesis for robust reliability. Furthermore, the CLI streamlines web app orchestration by bringing --base-href support directly to flutter run, matching production build configurations.

Learn more: PR #182024, PR #179703, PR #180692

Desktop support

We are excited to announce an expanded partnership with Canonical, who will now serve as the lead maintainer and Strategic Steward for Flutter Desktop. With their deep technical expertise, Canonical will lead the Flutter Desktop roadmap and oversee the maintenance of our Linux, Windows, and macOS embedders.

This collaboration represents just the first step in a broader ecosystem expansion. Moving forward, we are actively expanding our governance with more partners to bring Flutter’s high-performance, multi-platform experience to even more environments and industries.

Stay tuned to hear more about this partnership!

To inquire about partnering with the Flutter team, contact partners@flutter.dev.

Windowing APIs (experimental)

⚠️ Note: Windowing features are currently only available on the main channel. They are not yet intended for production use.

Canonical continues to make excellent progress on desktop’s experimental windowing APIs! New features include:

• Tooltips: Flutter now supports tooltip windows across Linux, macOS, and Windows (#182348, #180895, #179147).
• Popups: Flutter now supports popup windows on macOS (#182371), with support for Linux and Windows expected in a future release.
• Dialogs: Material’s showDialog function now creates a separate child dialog window on platforms that support windowing (#181861).

Finally, content-sized views are now supported on Linux (#182924). This lets you size a window dynamically based on its content, which is useful for popup or tooltip windows.

Learn more: For an early sneak peek of desktop’s experimental windowing APIs, check out the multiple_windows example.

Windows stylus support

Windows apps built with Flutter got a major upgrade for digital artists and note-takers! Thanks to a brilliant contribution from community member CodeDoctorDE, Flutter Windows now supports stylus input, including precise tracking for both stylus rotation and pressure sensitivity.

Learn more: PR 165323: Allow stylus support on Windows

Embedded

Toyota

The Toyota RAV4 was the world’s best selling car in 2025. Now, the 2026 RAV4 is using Flutter to power its multimedia system.

Last month, I experienced one of the highlights of my career: The opportunity to travel to Plano, TX and visit the Toyota Motor North America & Toyota Connected offices to talk to the engineering team about how Flutter has changed the game for them when it comes to designing, building, and delivering multimedia systems: from the test units in their offices to cars in driveways. As both a Flutter engineer and a car nerd who grew up in a family that only purchased Toyotas, I’m ecstatic to see Flutter running on the 2026 RAV4. I’ve seen them so many times as I’m out and about. (ahem-everywhere??)

Thank you to the Toyota Motor North America and Toyota Connected teams for hosting us!

Check out the showcase video:

Learn more: Toyota’s press release, The Latest Evolution of Toyota’s Multimedia Coming to a Screen Near You

LG

LG is on the verge of launching the webOS SDK to help developers easily build Flutter apps that target WebOS devices, empowering Flutter for the big screen and beyond.

The webOS SDK will include plugin support for Firebase, video players, gamepads, and more. It’ll even come with support for all of the Flutter features that you know and love, like stateful hot reload and state management with Riverpod.

Keep an eye out for this exciting launch in the coming weeks!

Graphics and engine enhancements

This release brings targeted rendering and performance enhancements to the Impeller backend.

Impeller improvements

Vulkan

This release includes several Vulkan improvements including better memory management of caches and more efficient GPU/CPU synchronization in cases where frames are being dropped.

Cleaner circles with SDFs

The math for rendering circles has been updated to support cleaner circles using signed-distance functions. There were cases where they would previously be aliased, but that has been resolved. (#183536, #183184)

Shadow and perspective fixes

Improvement on how Impeller handles perspective matrices, correcting rendering behaviors for shadows and perspective projection transforms. (#181434, #183187)

FragmentShader improvements

Writing fragment shaders is now more intuitive and less error-prone, thanks to the following enhancements.

Get Uniform by Name API

You can now bind uniform variables in your shaders by name instead of manual offsets, dramatically simplifying shader code setup:

    void setUp(ui.FragmentShader shader) {
      shader.getUniformFloat('foobar').set(1.234);
    }

Learn more: Writing and using FragmentShaders, FragmentShader.getUniformFloat

Clearer shader compiler diagnostics

The shader compiler now generates warnings when compiling shaders that aren’t compatible with Skia, helping you identify cross-platform rendering issues before deploying (#182786, #183146).

Framework

This release balances significant architectural shifts with a rigorous focus on quality and community-driven refinements. As we begin the strategic decoupling of the Material and Cupertino libraries to standalone packages, the core framework continues to mature with major updates to web rendering, foundational stability improvements, and enhanced platform integration.

Material and Cupertino updates

This release marks a massive milestone for the Material and Cupertino libraries. These libraries have been frozen as of this release, representing the final set of updates to these libraries within the core framework before they transition to standalone packages: material_ui and cupertino_ui. By the next stable release, the versions of these libraries currently in the framework will be deprecated, and you will be able to migrate to the new, independently-versioned packages.

Learn more: For more information on this transition, read the blog post about the freeze and follow the main tracking issue for decoupling these libraries from the core framework.

Despite the freeze, this release is packed with refinements. A major highlight is the modernization of menus in the Cupertino library. The new CupertinoMenuAnchor widget, built on the flexible RawMenuAnchor foundation, provides a more robust and native-feeling menu experience for iOS applications (#182036). This work was made possible by the extensive contributions of community member davidhicks980, who also created the RawMenuAnchor widget.

Learn more: CupertinoMenuAnchor

On the Material side, menus also receive a polish with the addition of Material 3 animations to the MenuAnchor class. These animations provide a smoother, more responsive feel, and a new hoverOpenDelay parameter on SubmenuButton gives you finer control over submenu interactions. The animation is disabled by default, and is enabled by setting animated to true. (#176494).

Learn more: MenuAnchor, SubmenuButton.hoverOpenDelay

This release also enables scrollable content within a CupertinoSheetRoute to work seamlessly with the dragging animation, allowing for a more fluid transition between scrolling and dismissing the sheet (#177337). For developers needing custom drag regions, the new scrollableBuilder allows you to pass the managed ScrollController to the body’s scrollable areas to coordinate sheet dragging for you.

Learn more: CupertinoSheetRoute, CupertinoSheetRoute.scrollableBuilder

The CarouselView component sees major functional improvements in this release. It now supports infinite scrolling (#175710), allowing you to create seamlessly looping carousels. It also features a new onIndexChanged callback and a leadingItem property on its controller, providing better visibility into the carousel’s state as the user interacts with it (#180667).

Learn more: CarouselView

New design primitives make it easier to achieve sophisticated UI effects, such as the new ShapedInputBorder. This allows Material widgets to create an input border using a shape by specifying any ShapeBorder. This can be useful, for example, for making the Material input border appear in an iOS style using RoundedSuperellipseBorder. (#177220). Similarly, CupertinoFocusHalo now supports the superellipse shape, ensuring consistent focus indicators across different widget geometries (#180724).

Learn more: ShapedInputBorder

Several existing widgets have also been refined. The Expansible widget, which powers Material’s ExpansionTile under the hood, is now more capable. A new toggle method is now available on both ExpansibleController and ExpansionTileController, accompanied by improved documentation and examples (#181320, #180273). Additionally, Material’s list tiles, RadioListTile, CheckboxListTile, and SwitchListTile, now correctly accept a WidgetStatesController, allowing for more programmatic control over their visual states (#180367).

Accessibility: a more inclusive experience for all users

Making applications accessible to everyone remains a core priority of the Flutter framework. This release introduces deeper integration with platform-specific accessibility settings, improves the precision of semantic announcements, and refines the accessibility of common UI components.

For iOS developers, this release adds support for several new accessibility motion features (#178102). Your applications can now respond to user preferences for:

• Auto-play animated images: Detects when a user prefers to pause automatically playing GIFs or other animated content.
• Auto-play video previews: Informs the app if the user has disabled the automatic playback of video previews.
• Prefer non-blinking cursor: Allows the app to provide a stable, non-blinking text indicator for users who find blinking cursors distracting or difficult to track.
• These settings are exposed with the AccessibilityFeatures object, enabling you to build more responsive and respectful UIs on iOS.

Progress indicators also receive a quality-of-life improvement. You can now use percentage strings (such as “50%”) as a SemanticsValue for ProgressIndicator (#183670). This allows screen readers to announce progress in a more natural and human-readable format, rather than just raw decimal values.

This release also polishes the semantics of core widgets. The Slider widget’s semantics node has been refactored to more accurately reflect its size and position, improving the experience for users who navigate by touch exploration or assistive devices (#184168). Additionally, a fix for scroll views ensures that invisible accessibility elements are no longer incorrectly presented before the scrollable content, leading to a cleaner and more predictable navigation flow (#184155).

Together, these changes ensure that Flutter applications continue to provide a high-quality, inclusive experience across all platforms.

Resiliency for zero-width/height widgets

A major effort in this release has been dedicated to improving the framework’s stability when widgets are rendered in “0x0 environments” — scenarios where widgets are given zero width or height, which could previously trigger layout errors or unexpected crashes. Thanks to the gradual, steady contributions of community member ahmedsameha1, we have added zero-size coverage across many core widgets, including Hero (#180954), Icon (#181021), AnimatedPadding (#181235), and GridPaper (#180906). These updates ensure that your applications remain resilient during complex layout transitions or inside highly constrained viewports.

SelectableRegion improvements

We have resolved two key issues inside SelectableRegion to improve layout fidelity and text selection behavior across native and web platforms:

Web layout constraint preservation

Previously, SelectableRegion could cause its children to shrink unexpectedly when rendering on the web. It now correctly passes all layout constraints unmodified to its children, ensuring consistent sizing behavior (#184083).

Multiline copy precision

Text selection within SelectableRegion is now more precise — when users select and copy text that spans multiple lines, line breaks are now properly preserved in the copied output instead of being lost (#184421).

Breaking changes and deprecations

This release includes several important deprecations and breaking changes as part of the ongoing effort to modernize and improve the Flutter framework.

RawMenuAnchor callback adjustments

The calling order of some callbacks of RawMenuAnchor has been adjusted to allow more flexible and predictable customization.

Learn more: Changing RawMenuAnchor close order

Key deprecations in this release include:

• CupertinoSheetRoute: The builder and pageBuilder parameters in showCupertinoSheet and CupertinoSheetRoute are now deprecated in favor of scrollableBuilder (#177337). This change allows for better integration of scrollable content with the sheet’s dragging animations.
• ReorderableListView: The onReorder callback is deprecated in favor of the more precise onReorderItem (#178242). The new callback provides a more predictable newIndex that accounts for the item being removed before being re-inserted.
• Tooling: The--web-hot-reload flag in the Flutter tool is now deprecated, as hot reload for web is now handled through more modern mechanisms (#181884). Additionally, the plugin_ffi template is deprecated in favor of the more robust plugin template with FFI support (#181588).

Learn more: For more details and migration guidance on these and other changes, see the breaking changes page on flutter.dev.

Flutter is everywhere, everyday.

Flutter’s reach extends across mobile, desktop, web, and embedded systems, and while individual features are impressive, they collectively deliver a robust platform for developers — empowering over 1.5 million developers to build incredible, user experiences that are used everywhere, everyday. You can find Flutter in everything from business tools and daily apps like NotebookLM, Talabat, Zoho, and Karaca, to high-profile embedded implementations like the infotainment system in the 2026 Toyota RAV4 and LG’s webOS devices.

Flutter is built by everyone, for everyone.

Flutter’s success is built on your feedback! We’re committed to keeping that conversation going — whether through comments, issues, or our upcoming developer survey. Your input is what drives the features you love, so please keep sharing it with us.

This ecosystem is depended upon by and made up of industry leaders like LG, Toyota, and Canonical — and most importantly, by the over 1.5 million developers building with Flutter everyday. We are so excited to continue building and growing this wonderful Dart & Flutter ecosystem together.

To try out all the new features, optimizations, and graphics enhancements, all it takes is a simple:

flutter upgrade

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

This is crucial in an AI-driven world where enhanced consistency, reduced token usage, and fast market reach become vital. By maintaining a single codebase, builders can focus their AI assistants on one unified context, drastically reduce token overhead, and minimize AI hallucinations. Instead of asking AI to translate features across fragmented, platform-specific languages, builders can leverage AI to write it once in Dart and instantly deploy it everywhere.

The existing value proposition

Multiplatform development relies on enabling a single, shared source codebase. In our first-party Flutter apps, between 95% and 99% of the source code is shared. This massive code reuse unlocks several benefits:

• Faster time to market across multiple platforms because a team only needs to maintain one codebase.
• Guaranteed consistency across platforms, giving companies a single, consistent feature set to support across all their customers, regardless of their platform of choice.
• Native performance and stability because Flutter code is compiled to each platform’s native machine code.
• Semantic guardrails increase security because the Dart language is strongly typed.

The agentic value proposition

While LLMs are good at translating requirements into code, using them to build separate native apps for each platform scales poorly. Replicating features across different languages using LLMs multiplies generation time and token usage, and can quickly lead to implementations drifting apart.

Flutter’s single-source solution eliminates these problems. But beyond just code sharing, Flutter’s specific architecture makes it the ideal framework for agent-driven development. This emerging value proposition is driven by several key advantages:

• Token reduction: By generating your app once in Dart, you drastically reduce token overhead compared to using AI to translate features across platform-specific languages. This eliminates the need to replicate logic across different codebases, which scales poorly and multiplies token usage.
• Consistency: Flutter provides a unified experience because a single source codebase ensures the feature set remains identical across all platforms. This prevents platform drift that occurs when LLMs hallucinate and implementations drift apart.
• Self-correcting agents: Flutter has strong semantic guardrails due to Dart’s strongly typed language, and rich developer tooling. When an AI agent generates code, the strict type system, exposed through flexible tools and MCP servers, acts as an immediate feedback loop to catch errors instantly.
• Predictable code generation: LLMs excel at generating hierarchical, structured data. Flutter’s compositional, declarative UI aligns with this strength. It is much easier for an agent to reason about and reliably generate a single Dart widget tree than to manage the fragmented logic of other platform-specific frameworks.
• High-speed validation with Hot Reload: In an agentic workflow, the bottleneck is often verifying the AI’s output. Flutter’s hot reload feature provides a workflow where any change made by the agent is viewable instantly in the running app during development.

The Flutter advantage

Flutter’s support for a single shared codebase targeting multiple platforms, paired with a strongly typed language and powerful tooling, makes it a great companion to agent-driven development. In summary, the future looks bright! With Flutter, expect your agentically developed apps to result in low token usage, faster multi-platform development cycles, strong semantic guardrails, app consistency across platforms, and native performance. Happy building!

Flutter’s multiplatform value for agentic development was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Generative UI, or GenUI for short, is a user experience pattern in which an agent not only generates content, but also makes decisions about how that content should be displayed and made interactive for the user. For Flutter developers, implementing GenUI means using A2UI, an open protocol that defines a way for agents and clients (or “renderers”) to collaborate on the composition and state of a user interface. To capitalize on this, the Flutter team built genui, a package that uses A2UI to connect with an agent and provide it with a catalog of widgets to use, and then presents those widgets to the user.

Both the genui package and the A2UI protocol recently got an update!

The latest release of genui introduces several architectural changes to the framework. Driven by adoption of v0.9 of the A2UI protocol, this update shifts genui from a “Structured Output First” philosophy in which A2UI messages were streamed through structured output APIs to a “Prompt First” approach in which agents include blocks of JSON as text in their responses. It also decouples the architecture, providing more direct control over how your application interacts with Large Language Models (LLMs).

If you are migrating an app from v0.7.0 to v0.9.0 of the genui package, this guide covers the necessary steps, from dependency cleanup to wiring up your new chat loops.

Architecture decoupling

In previous versions, GenUI relied on a series of classes based on ContentGenerator. These classes hid the details of prompt construction, LLM network calls, and response parsing.

The latest version of package:genui removes ContentGenerator. Instead, the framework is now split into distinct layers:

• Engine (SurfaceController): Manages the state and rendering of your UI.
• Transport (A2uiTransportAdapter): Streams messages between the agent and renderer.
• Facade (Conversation): Provides a high-level API for managing chat states.

This decoupling means you have control over chat history, retry logic, and error handling. It also means you can set up your connection to your LLM however you’d like. The framework no longer “wraps” your agent with a ContentGenerator, so you’re free to use the model and provider you’d prefer, tweak generation settings, add your own functions, and so on, without needing to go through the framework’s API to do so.

Because the ContentGenerator is gone, the provider-specific wrapper packages are no longer needed. If you pull the latest version of the package, you’ll see that names like genui_dartantic, genui_google_generative_ai, and genui_firebase_ai no longer appear in the tree.

This is the most significant code change in the migration. Instead of passing a ContentGenerator to your SurfaceController, your app is responsible for setting up a connection to an agent and passing messages back and forth through a TransportAdapter.

The old way:

// Create a ContentGenerator that encapsulates interaction with
// the agent.
final generator = FirebaseAiContentGenerator(
  catalog: CoreCatalogItems.asCatalog(),
  systemInstruction: 'You are a helpful assistant.',
);

// Create a conversation that links the generator with a GenUiManager
// that manages surfaces, updates, and so on.
final conversation = GenUiConversation(
  genUiManager: GenUiManager(catalog: catalog),
  contentGenerator: generator,
);

The new way:

final catalog = BasicCatalogItems.asCatalog();

// Create a SurfaceController to manage the state of generated surfaces.
final surfaceController = SurfaceController(catalogs: [catalog]);

// Created a transport adapter that routes messages from the `genui` library
// to the agent, then feeds responses back into the adapter via `addChunk`.
late final adapter = A2uiTransportAdapter(
  onSend: (ChatMessage msg) async {
    // Use a string buffer to prepare tokens to send to the agent.
    final buffer = StringBuffer();

    // Iterate over the messages created by the `genui` package, and
    // add them as tokens to the buffer.
    for (final part in msg.parts) {
      if (part.isUiInteractionPart) {
        buffer.write(part.asUiInteractionPart!.interaction);
      } else if (part is genui.TextPart) {
        buffer.write(part.text);
      }
    }

    // Send a content generation request to the agent, including the
    // string-ified messages from `genui`
    final response = await myAgentClient.sendRequest(buffer.toString());

    // After receiving the agent's response, add it to the `genui` package's
    // input stream using `addChunk`, where it will be parsed for A2UI
    // messages.
    adapter.addChunk(response);
  },
);

You might look at those two examples and think, “Wait, shouldn’t API improvements mean I have to write less code rather than more?” It’s true that previously this bit of “wiring” code for connecting with the agent was included in the genui package, tucked away in a ContentGenerator class, but the new approach has some concrete advantages:

• Without the requirement of a ContentGenerator, you can set your agent up the way you like, hold it in memory where you prefer, and manage its lifecycle. You can also use nearly any AI source you’d like without waiting for a package update with a new ContentGenerator.
• You no longer have to “inject” your connection to the agent into the genui API. They’re loosely coupled, with just tokens moving back and forth.
• Testing is simpler. genui accepts tokens directly, and they can come from an agent, or a mock agent, or a hard-coded test.
• If you’d like to encapsulate your connection into a class, you can still do so. In fact, several of the examples for genui take this approach.

Going prompt first

In previous versions, the genui package relied heavily on the LLM provider’s strict API-level constraints (like “JSON Mode” or complex function-calling definitions) to force the model to output valid UI structures. The schema was passed to the LLM out-of-band through specific API parameters, and the LLM was effectively locked into a rigid structure.

While this directed models to create predictable, well-formatted JSON, deeply nested schemas could sometimes confuse models or fight against their natural text-generation tendencies. Plus, reliance on structured outputs imposed limits on the overall size and complexity of the catalog. It also made debugging harder because the constraints lived entirely in the network layer rather than in plain text that you could easily read and tweak.

The “prompt first” approach shifts the source of truth back to where LLMs excel: system instructions. Instead of relying entirely on strict API toggles, the UI schema and instructions relating to A2UI are injected directly into the LLM’s system prompt as plain text. The LLM reads the instructions, detailing exactly how to construct messages for the client.

This approach has a few advantages. First, modern LLMs are highly optimized to follow detailed system instructions and examples. Providing the schema in the prompt aligns with how they “think.” In addition, because the UI schema is now just plain text in your prompt, you have the ability to change it to suit your application.

This change means responsibility for getting the right prompt into the agent’s context window now rests with your app. Fortunately, the genui package provides a new tool to help you craft the right system prompt for your application, PromptBuilder. Given a catalog and any additional instructions you’d like to provide, PromptBuilder will create a system prompt that includes the schema definitions and rules that your LLM needs to format A2UI messages correctly.

final promptBuilder = PromptBuilder.chat(
  catalog: catalog,
  systemPromptFragments: ['You are a helpful assistant.'],
);

Once set up, your app can retrieve a String version of the prompt using promptBuilder.systemPrompt, and then pass that value to the LLM.

Protocol & schema adjustments

If your code manually constructs A2UI JSON or relies on specific payload structures, note these breaking changes from the A2UI v0.9 update:

• Surface creation: beginRendering is now createSurface.
• Flat component definitions: Instead of nested keys (such as {“Text”: {“text”: “Hello”}}), components now use a flat discriminator: {“component”: “Text”, “text”: “Hello”}.
• Data binding: Bindings are simplified. Use { “path”: “/path/to/var” } for path resolution.

Property renames:

• distribution => justify
• alignment => align
• usageHint => variant
• text (in TextField) => value
• userAction => action

Other stuff got renamed!

Along with some other small tweaks, the GenUi prefix has been dropped from almost all core classes:

• GenUiConversation => Conversation
• GenUiController => SurfaceController
• GenUiSurface => Surface
• GenUiHost => SurfaceHost
• GenUiContext => SurfaceContext
• GenUiTransport => Transport
• GenUiFallback => FallbackWidget

In addition, CoreCatalogItems was renamed to BasicCatalogItems to clarify that it serves as a baseline implementation rather than a strict requirement.

Finally, to align with standard LLM function-calling terminology, GenUiFunctionDeclaration and references to “tools” have been renamed to ClientFunction.

The new genai_primitives package

The genui package no longer ships with its own messaging types. Instead, the GenUI team created the new genai_primitives package with primitive types for common functionality needed by GenAI applications. This package includes types like ChatMessage, MessagePart, and ToolDefinition.

These new types are used across the genui package API, and they’re flexible enough to fit into other GenAI applications or packages you might be working on.

And there’s more!

In addition to the above, the latest version of A2UI and the genui package bring several new features like:

• Custom functions, useful for validating data on the client
• A new, modular schema
• Improved error handling

For more information on these, check out the v0.9 announcement blog post and head to a2ui.org.

Summary

The latest update to genui introduces an architecture that is much more idiomatic, flexible, and robust. If you haven’t yet started using GenUI, there’s no better time than now! Head to our introductory codelab to gain a hands-on understanding of the tech and create a working app in about 90 minutes.

New updates to A2UI and Flutter’s GenUI package was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.