On 11 November 2026, the Flutter team released Flutter 3.50, together with Dart 3.14. This is a production release, not a preview. If you ship a mobile or web app with Flutter, it is the version to plan an upgrade around before the year ends.
The headline is easy to miss if you only skim release notes. For years, talking to native iOS or Android code from Dart meant sending a message across a platform channel, waiting for a reply, and writing a lot of plumbing. In 3.50, the official generators for those native calls are stable. You can call many native APIs directly, including in a way that does not have to wait for an asynchronous hop.
There is also faster Flutter web, a shorter delay on iOS taps, tighter Android security in release builds, and a push to new design packages. Some of these are gifts. Some are homework. This guide explains the changes in simple language and gives an upgrade order you can actually follow.
DayDecoder is a custom software company in Ahmedabad, and Flutter is one of the ways we build mobile apps. The advice below is the same order we would use on a production codebase: upgrade the SDK, fix the breaks, then opt into the new features on purpose.
Key takeaways
- Flutter 3.50 and Dart 3.14 were released on 11 November 2026. Run
flutter upgradewhen you are ready, then read the breaking-change notes before you merge to your main branch. - Direct native interop is now stable: FFIgen for C and Objective-C, and JNIgen for Java and Kotlin. You can call native APIs without the old platform-channel round trip.
- Flutter web is faster on Safari 26.2 and later and on Firefox 147 and later, if you opt into WebAssembly. A new content-hash flag helps you avoid stale JavaScript after a deploy.
- iOS taps should feel one frame quicker. Release builds on Android now ignore dangerous configuration extras from other apps. Swift Package Manager is becoming the only path, ahead of the CocoaPods trunk going read-only in December 2026.
- New projects default to the standalone
material_uiandcupertino_uipackages. The old bundled Material and Cupertino libraries are deprecated. Adart fixcan update the imports.
How to read this release
A Flutter release always mixes three kinds of change. First, features you can ignore until you need them. Second, fixes you want as soon as you can test them. Third, deprecations that will become errors later. Flutter 3.50 has all three.
The official post says 188 contributors, including 69 first-time contributors, landed more than 1,200 commits in this cycle. You do not need to read all of those. You do need a plan for native interop, web, iOS, Android, and the design-package migration. Smaller polish can wait until the app is green on your existing tests.
Dart 3.14 is the language and tool update that ships with this Flutter. The Dart team also added automatic SDK migrations with dart migrate, faster WebAssembly, and a rebuilt DartPad. If you maintain Dart packages as well as an app, this is a good moment to run the migrator on a branch.
Stable native interop, without the old message passing
The old way to call iOS or Android code from Flutter was a platform channel. Your Dart code packed a message, the native side unpacked it, did the work, and packed a reply. That path is flexible, but it is also slow to write, easy to get wrong, and almost always asynchronous. Even a tiny native call had to wait.
Flutter 3.50 makes the newer path production-ready. FFIgen, which already worked for C, is now stable for Objective-C as well. JNIgen is stable for Java and Kotlin. Together they generate type-safe bindings, so Dart can call native APIs directly. You can also do this from a background isolate, and you can do it synchronously when that is the right choice. An isolate is a Dart worker that runs separately from the main UI thread, so heavy work does not freeze the screen.
There is also a preview of Pigeon’s native interop mode. Pigeon is the tool many plugin authors already use to describe a shared API. The new mode uses the same generators under the hood and can handle data conversion and native object lifetimes on iOS, macOS and Android.
When should you care? If your app talks to a payment terminal, a Bluetooth device, a bank’s official Android SDK, or any iOS API that never had a good Flutter plugin, this release removes a lot of glue code. If your app is still well served by a mature plugin, you do not have to rewrite it on day one. Make the SDK upgrade first. Adopt direct interop on the next feature that would otherwise need a new platform channel.
Flutter web: faster, and easier to cache correctly
Flutter web has often been “good enough for a demo” and a bit heavy for production. This release puts real weight behind WebAssembly, often shortened to Wasm. WebAssembly is a compact format that browsers can run at close to native speed.
When you run flutter build web --wasm, Flutter compiles your app to both WebAssembly and JavaScript. Older browsers can fall back to JavaScript automatically. Chrome and Edge 137 and later already run the WebAssembly build by default. In Flutter 3.50, Safari 26.2 and later, on both macOS and iOS, and Firefox 147 and later, can deliver more than twice the frame rate of JavaScript on heavy widget benchmarks. You can opt in today in web/flutter_bootstrap.js before this becomes the default in a later stable release.
Deploys get a practical fix too. A common Flutter web bug is that a user comes back after a release and still runs yesterday’s JavaScript, because the browser cached it. Passing --web-content-hash to flutter build web puts a content hash into the compiled JavaScript, WebAssembly and asset file names, and updates the bootstrap file for you. You can then cache the hashed files for a long time, and keep index.html and flutter_bootstrap.js on a no-cache policy so each deploy is picked up cleanly. The flag also writes a precache manifest for custom service workers, and replaces older service-worker tokens that are now deprecated.
Two more web notes are worth a place on your checklist. The old JavaScript interop libraries — dart:html, dart:js, dart:js_util and package:js — are deprecated in favour of dart:js_interop and package:web, which work for both JavaScript and WebAssembly builds. You can pass --no-deprecated-js-interop to flutter build web, flutter run, or Chrome tests to fail the build if anything still imports the old libraries. And there is an experimental browser-native text layout path, called WebParagraph, which can shrink the CanvasKit download (to roughly 3.75 MB, down from 5.46 MB) and improve international text and colour emojis. Treat that last item as a preview, not as a default you must turn on this week.
iOS and macOS: quicker taps, and a deadline for CocoaPods
Flutter 3.50 is the first stable release since Xcode 27 and iOS 27. The most visible user-facing change is input lag. A community-contributed change delivers touch events to the framework immediately, so the next frame can include the tap instead of waiting for a later refresh. The result is one frame less delay: 16 milliseconds faster on 60 Hz iPhones, and 8 milliseconds faster on 120 Hz ProMotion displays. The team says this was checked on hardware going back to the 2015 iPhone 6s.
Day-to-day debugging is less painful too. A newly paired or freshly upgraded iPhone should no longer sit on a white screen until you open Xcode once. The Flutter command line prepares the device, and it tells you what to do if that fails. Intermittent launch crashes with flutter run on iOS 27 are addressed, and flutter screenshot on a physical device works again when you build with Xcode 27.
The strategic change is package management. The CocoaPods trunk is due to become read-only in December 2026. Flutter has been moving to Swift Package Manager. In 3.50, turning Swift Package Manager off prints a warning on every Flutter command. A later release will remove the opt-out, and eventually the CocoaPods fallback itself. If you disabled Swift Package Manager earlier to dodge a build issue, turn it back on now and fix whatever breaks, while you still have time.
Flutter also no longer tests on Intel Macs, and the command line warns once when you build on one. A future release will require an Apple Silicon Mac to build for iOS, macOS or Android. You can already build Apple Silicon-only macOS apps with flutter config --enable-macos-arm64-only before that becomes the default.
Android: safer release builds, and a newer Gradle default
The Android security change is easy to summarise. Older Flutter Android apps would accept some runtime configuration from an incoming Intent — a message one Android app can send to another. In release builds, Flutter 3.50 now ignores values such as route, dart_entrypoint and cached_engine_id when they come from an external Intent, and it rejects some runtime engine flags in that same path. Normal deep links still work. Debug builds log warnings instead. If you used those extras as a hidden back door in production, you will need a proper, authenticated route instead.
Hybrid Composition++, Flutter’s newer way to embed native Android views such as maps and web views, gets more polish. It still needs Android 14 or higher and Impeller on Vulkan, and it is not the stable default yet. On a supported device you can opt in and confirm it in the logs. On other devices, Flutter falls back automatically.
New apps generated with 3.50 use Android Gradle Plugin 9.3.1 and Gradle 9.5.0, with a minimum of Java 17. Default SDK values in this release are compile and target API 36, and a minimum of API 24. Plugin authors who still apply the Kotlin Gradle Plugin by hand need to move to Built-in Kotlin, or future Android Gradle Plugin versions will fail the build and pub.dev scores may fall. If you maintain a plugin, treat that as a priority, not as optional cleanup.
Design packages, AI tooling, and other notable extras
New projects created with flutter create now import package:material_ui by default, instead of the Material library that was bundled inside the Flutter SDK. The old package:flutter/material.dart and package:flutter/cupertino.dart libraries, and their localisation delegates, are formally deprecated. You can migrate existing imports with:
dart fix --apply --code=migrate_design_widgets
Run that on a branch and review the diff. The change is mostly mechanical, but it is the direction of the framework, so it is better to do it while the automated fix exists.
For teams that use AI coding assistants, Flutter 3.50 ships official agent plugins, including a rule that can trigger a hot reload after edits under lib/. Package authors can also ship agent skills inside a skills/ folder in a pub.dev package. Treat those as optional developer-experience tools, not as something your production app depends on.
Elsewhere in the ecosystem, Genkit Dart reached a stable 1.0 for building typed, streaming, multi-model agent flows in Dart and Flutter. A new MediaPipe package on pub.dev offers 20 on-device vision, audio and text tasks, so some AI features can run on the device instead of in the cloud. The official Flutter post also notes that more than one million Flutter apps have been published on Google Play.
There are smaller fixes too, including better scroll clipping, a secure PIN keypad option on Android, email one-time-code autofill, and calmer text selection. Re-test forms, lists and text fields once you are on 3.50.
A practical upgrade order
Do not try to adopt every new feature in the same pull request as the SDK bump. This order keeps risk low:
- Read the official 3.50 breaking-change list and make a branch. Take a backup of the project first.
- Run
flutter upgradeand confirmflutter --versionshows 3.50 and Dart 3.14. - Fix compile errors first. If you used
ignoringSemanticson pointer widgets, that deprecated property is now gone. Watch for text with soft hyphens, right-to-leftWidgetSpanlayout, andSafeAreaon mobile browsers whenviewport-fit=coveris set. These are behaviour changes, not just warnings. - Re-enable Swift Package Manager if you had turned it off. Resolve plugin issues now, not in December 2026.
- Run your full test suite on iOS, Android, and web if you ship web. Re-test login, payments, camera or maps, and any screen that embeds a native view.
- On web, try a Wasm build in staging and add
--web-content-hashso deploys do not leave users on an old bundle. Add--no-deprecated-js-interopso leftover old imports fail the build. - On Android release builds, confirm deep links still work, and that you were not relying on Intent extras that are now ignored.
- Migrate design imports with
dart fixin a follow-up pull request, not in the same one as a risky native change. - Only then adopt direct native interop or Hybrid Composition++ for a new feature, with a rollback plan.
How we can help at DayDecoder
DayDecoder is a custom software company in Ahmedabad. We build and upgrade Flutter and React Native apps for clients in India and abroad. If you want a careful Flutter 3.50 upgrade, help moving off CocoaPods, or a review of a native SDK integration, use the contact form. We reply within one business day.
FAQ
When was Flutter 3.50 released?
On 11 November 2026, together with Dart 3.14. It is a stable release. You can install it with flutter upgrade.
Do I have to rewrite all my platform channels right now?
No. Direct native interop is stable and ready for new work, but existing plugins and channels can stay as they are while you complete the SDK upgrade.
Will my Flutter web app become faster automatically?
Not completely. Chrome and Edge already default to WebAssembly in supported versions. Safari 26.2+ and Firefox 147+ need an opt-in for now. You should also use content hashing so users do not stay on a cached old build.
What is the CocoaPods deadline?
The CocoaPods trunk is due to become read-only in December 2026. Flutter 3.50 warns if you disable Swift Package Manager, and a later Flutter release will remove that opt-out. Re-enable it now and fix build issues while the fallback still exists.
Is this the last Flutter version I can build on an Intel Mac?
Not yet, but the direction is clear. Flutter 3.50 no longer tests on Intel Macs and warns when you build on one. A future release will require Apple Silicon for iOS, macOS and Android builds.
Should a new project in late 2026 start on 3.50?
Yes. New projects already get the standalone design packages, the current Android toolchain defaults, and the stable interop tools. Starting on 3.50 is easier than jumping from an older version later.
Written by
Prakash Tank
Founder & Full-Stack Architect, DayDecoder
Prakash started as a certified Laravel developer and grew into a full-stack architect who owns a project end to end: requirements, architecture, development, deployment, and support. He designs event-driven systems with...
More about Prakash