SUMMARY

Strategy to scale back and ultimately terminate support for Flutter development on and for Intel-based Macs.

Author: Victoria Ashworth (vashworth)

Go Link: flutter.dev/go/macos-intel-deprecation

Created: 05/2026   /  Last updated: 05/2026

WHAT PROBLEM IS THIS SOLVING?

Apple has been actively moving towards dropping support for Intel-based Macs since 2020.

As Intel becomes more obsolete, it becomes more difficult to support it, particularly in CI. For example, all our current Intel bots in CI cannot be upgraded to macOS 26.

This design proposes a plan for Flutter to likewise reduce support for and eventually stop supporting Intel-based Macs. This includes support for two main use cases:

• Developing Flutter iOS, macOS, Android, and web apps on Intel-based Macs
• Building macOS apps that run on Intel-based Macs

BACKGROUND

In 2020, Apple announced their plan to transition from Intel-based Macs to Apple silicon.

In 2023, the last Intel machine, Intel Mac Pro, was discontinued.

In 2025, it was announced that macOS Tahoe would be the last release for Intel-based Mac computers. Those systems will continue to receive security updates for 3 years.

In 2026, macOS 26.4 started displaying warnings for apps that use Rosetta. WWDC 26 announced that Xcode 27 will not support Intel machines and Intel support is no longer required for macOS apps.

By April 2027, it is likely that you will no longer be able to develop iOS/iPad apps on Intel machines due to the App Store’s minimum Xcode requirement. It’s also expected that Apple will remove Rosetta 2 support in macOS 28.

By 2028, Apple will have stopped supporting Intel-based Macs and Intel-only applications. Intel-based Macs will no longer receive updates and Intel-only applications will no longer run on Apple silicon.

Audience

Internal Approvals: go/macos-intel-deprecation-approvals

Flutter iOS, macOS, Infra, Engine, Web, Dart Infra, Dart FFI contributors.

Glossary

• Intel-based machines - Macs with an Intel chip (x86_64)
• ARM-based machines - Macs with an Apple Silicon chip (arm64)
• Intel-based apps/binaries - Apps/binaries built for only Intel-based machines. Does not support ARM-based machines (unless using Rosetta, see below)
• ARM-based apps/binaries - Apps/binaries built for ARM-based machines. Does not support Intel-based machines.
• Fat binary - binaries built with both Intel and ARM support
• Thin binary - binaries built for only one specific architecture.
• Universal apps - Apps that are built with both Intel and ARM support
• XCFramework - iOS/macOS frameworks that can be built with both Intel and ARM support
• Rosetta 2 (Rosetta) - Rosetta enables an ARM-based machine to run Intel-based apps

Metrics

~3.5% of all Flutter developers use Mac Intel machines.

~13% of Flutter developers with Macs use Intel machines.

From last 30 days of doctor_validator_result analytics:

~9% of Flutter commands targeting macOS devices were targeting an Intel machine

Commands like (e.g. flutter build -d macos). From last 30 days of command_usage_values analytics:

~27% of the Flutter SDK bundle downloads for macOS are for the Intel variant.

From website click event analytics (cumulative clicks from https://docs.flutter.dev/install/manual and https://docs.flutter.dev/install/archive):

~50% of open Github issues filed on Macs are filed for Intel machines.

There are currently ~350 open issues reported from Intel machines. In comparison, there are ~330 open issues reported from ARM machines.

~34% of our luci.flutter CI bots are Intel machines.

127 bots are Intel. 244 bots are ARM.

~53% of our luci.dart-internal.flutter CI bots are Intel machines.

20 are Intel. 18 are ARM.

OVERVIEW

The goal of this document is to propose a strategy to reduce and then remove Intel support.

Non-goals

This document is specific to Flutter and does not address Dart-specific infrastructure or artifacts.

USAGE EXAMPLES

How does Flutter currently support Intel-based Macs?

1. Flutter supports developing iOS, macOS, web, and Android apps on an Intel machine

iOS

In order to develop for iOS on Intel, Flutter builds and distributes the following:

• ios-usb-dependencies fat binary tools such as iproxy, libimobiledevice, etc
• Flutter.xcframework that supports both ARM and Intel simulators (e.g. ios-arm64_x86_64-simulator)
• Fat binary gen_snapshot_arm64 

In addition, the following tools are required and provided by Apple:

• Universal Xcode
• Universal Simulator

macOS

In order to develop for macOS on Intel machines, Flutter builds and distributes the following:

• FlutterMacOS.xcframework that supports both ARM and Intel (e.g. macos-arm64_x86_64)
• Thin binary flutter_tester (built and distributed per architecture)
• Thin binary font-subset (built and distributed per architecture)
• Thin binary gen_snapshot (built and distributed per architecture)
• Fat binary gen_snapshot_arm64
• Fat binary gen_snapshot_x64
• Thin binary impellerc  (built and distributed per architecture)
• Thin binary libpath_ops.dylib  (built and distributed per architecture)
• Thin binary libtessellator.dylib  (built and distributed per architecture)

Web

There does not appear to be any specific builds or tools related to developing web apps on Intel machines.

Android

In order to develop for Android on Intel machines, Flutter builds and distributes the following:

• Fat binary gen_snapshot

2. Flutter macOS desktop apps run on Intel machines

In order to develop an Intel-based or universal macOS app, Flutter builds and distributes the FlutterMacOS.xcframework that supports both ARM and Intel (e.g. macos-arm64_x86_64).

3. Flutter CI

In order to build the fat binaries, thin binaries, and XCFrameworks mentioned above, Intel machines are technically NOT required. Some builds (specifically Android) are still set to use Intel, but it should not be required.

Currently, Intel machines are primarily used to run tests across both architectures.

4. FFI Build Hooks

Flutter FFI packages use Dart build hooks to configure the native build. Under the covers, Flutter then does the build using Xcode’s clang to compile the package. The package author has the onus of what architecture it supports.

It’s unclear if clang will continue to be able to compile Intel supporting libraries/binaries in future releases of Xcode.

DETAILED DESIGN/DISCUSSION

As of Xcode 26, you can still develop iOS/macOS applications on Intel machines and you can still develop Intel-supporting macOS applications.

Stage 0: Announce planned reduction of support

Flutter will announce that we’re reducing support for Intel with the plan to eventually completely stop supporting it.

What’s New in Flutter 3.44 announced that future release of Flutter will not support Intel machines

Timeline: ASAP

Steps:

• Announce reduced support for Intel machines (see Rust example)
• [Flutter 3.47] Flutter CLI will print a warning when building on a Intel machine that support will be unavailable in a future release
• [Flutter 3.47] Flutter CLI will print a warning when building a macOS app that supports both Intel and ARM. Provide a config setting to target ARM-only.

Stage 1: Remove Rosetta requirement

Flutter’s engine builds are currently set up to use Rosetta. We should change this so this is no longer needed.

Timeline: ASAP

Github Tracking Issue: https://github.com/flutter/flutter/issues/103386

Steps:

• Change buildtools to use non-hardcoded value
• Verify all builds pass using a VM without Rosetta installed
• Ask Chromium to remove Rosetta from Mac bots, reverting https://chrome-internal.googlesource.com/infra/puppet/+/6ed442c2c821fb2aeb0bf7f5f367d096b5da391a

This will ensure that our builds are prepped for macOS 28.

This can be done concurrently with Stage 0 and 2.

See Stage 1 Breakdown below for more step details.

Stage 2: Reduce support by removing Intel bots from CI

Flutter will continue to ship all existing artifacts: fat binary tools, Intel variant thin binaries, and Intel-supporting XCFrameworks. However, we will stop running tests on Intel machines.

For users, nothing will change immediately. Over time, this target will likely accumulate bugs faster due to reduced testing. Intel-specific bugs will be treated as P3.

Timeline: September 2026

Steps:

• Update https://docs.flutter.dev/reference/supported-platforms 
• Remove cross architecture tests (tests that run both on Intel and ARM)
• Migrate Intel-only tests to ARM
• [Flutter 3.50] When building a macOS app with Xcode 27+, it will default to build ARM-only. You can opt to build both via a flag/setting. Using the flag will print a warning.
• Replace Intel bots in CI with ARM bots

Once this is complete, our CI will not require Intel bots.

This can be done concurrently with Stage 1.

See Stage 2 Breakdown below for more step details.

Stage 3: Stop support for development on Intel-machines

For users, they will not be able to develop for iOS, macOS, or Android on Intel-machines using the latest Flutter version.

Timeline: April/May 2027

Steps:

• Announce removed support
• Update https://docs.flutter.dev/reference/supported-platforms 
• Remove Intel builds for ios-usb-dependencies
• Provide tool warnings/errors if attempting to build Intel machine

See Stage 3 Breakdown below for more step details.

Stage 4: Stop support for building universal macOS apps

Flutter will ship ARM-only artifacts. For users, they will not be able to build macOS apps that support Intel.

Timeline: TBD (align with Xcode)

Steps:

• Announce removed support
• Update https://docs.flutter.dev/reference/supported-platforms 
• Remove Intel builds from engine
• Remove Intel builds for ios-usb-dependencies
• Provide tool warnings/errors if attempting to build on or target Intel machine
• Optional: Change artifact cache path from darwin-x64 to darwin-arm64 for Android and macOS
• If Intel-supporting macOS apps can still be built from ARM machines using the latest Xcode, we should still build the Intel variant for the FlutterMacOS.xcframework.

See Stage 4 Breakdown below for more step details.

OPEN QUESTIONS

• Should we consider dropping support before Xcode does?
• Should the Flutter tool warn or error when building on Intel after Stage 3?
• What will happen if a Flutter FFI package still supports Intel but Flutter does not?

• The Flutter tool should stop/warn before it even attempts to do the native builds.

STAGE 2 BREAKDOWN

flutter/flutter

• Migrate x86 tests to ARM:

• Mac framework_tests_libraries
• Mac framework_tests_impeller
• Mac framework_tests_widgets
• Mac_x64 hot_mode_dev_cycle_ios_simulator
• Mac_build_test flutter_gallery__transition_perf_e2e_ios

• May also be required to change here: https://flutter.googlesource.com/infra/+/refs/heads/main/config/flutter_config.star#72

• Mac flutter_packaging
• Mac_mokey hot_mode_dev_cycle__benchmark
• Mac_mokey microbenchmarks

• Remove cross architecture tests:

• Mac_x64 build_tests
• Mac_x64 framework_tests_misc
• Mac_x64 plugin_lint_mac
• Mac_x64 tool_host_cross_arch_tests

• These test could be moved into a different shard since they’re no longer cross testing

• Mac_x64 tool_tests_commands
• Mac_x64 verify_binaries_codesigned
• Mac_x64 verify_binaries_pre_codesigned
• Mac_x64 hot_mode_dev_cycle_macos_target__benchmark
• Mac_x64_ios integration_test_test_ios
• Mac_x64 ios_app_with_extensions_test
• Mac_x64 macos_chrome_dev_mode
• Mac_x64_ios hot_mode_dev_cycle_ios__benchmark
• Mac_x64 native_ui_tests_macos
• Mac_mokey hello_world_android__compile
• Mac_mokey integration_test_test
• Mac_mokey run_debug_test_android
• Mac_mokey run_release_test

flutter/flutter/engine

• Migrate x86 tests to ARM:

• Mac mac_unopt > ci/ios_debug_unopt_sim
• Linux mac_android_aot_engine > ci/android_profile
• Linux mac_android_aot_engine > ci/android_profile_arm64
• Linux mac_android_aot_engine > ci/android_profile_x64
• Linux mac_android_aot_engine > ci/android_release
• Linux mac_android_aot_engine > ci/android_release_arm64
• Linux mac_android_aot_engine > ci/android_release_x64
• Mac mac_ios_engine (it appears that the drone_dimensions are used when it’s a subbuild of Linux flutter_release_builder)
• Mac mac_ios_engine_ddm (drone_dimensions were likely just copied and not required since this is not part of a release build)

• Change default host build to arm64 for macOS
• Change Android host directory to arm64 [PR]

flutter/packages

• Migrate x86 tests to ARM:

• Mac_x64 build_all_packages master
• Mac_x64 build_all_packages stable
• Mac_x64 ios_build_all_packages master
• Mac_x64 ios_build_all_packages stable

flutter/cocoon

• Remove cross architecture tests:

• Mac device_doctor
• Mac codesign
• Mac ruby

Flutter CI

• Replace luci.flutter Intel machines in CI with ARM

• go/i-need-hw

• Replace luci.dart-internal.flutter Intel machines in CI with ARM

STAGE 1 BREAKDOWN

flutter/flutter/engine

• Change builtools to use mac_arm64 (already exists, just change hardcoded value):

• Clang executable path [PR]
• asan runtime dylib [PR]
• sanitizer_suppressions.sh [PR]
• verify_exported.dart [PR]
• llvm path [PR]

STAGE 3 BREAKDOWN

iOS

• ios-usb-dependencies fat binary tools should be converted to an ARM-only thin binary
• Flutter.xcframework simulator variant should be converted to ARM-only (e.g. ios-arm64_x86_64-simulator -> ios-arm64-simulator)
• Fat binary gen_snapshot_arm64 should be converted to an ARM-only thin binary

Android

• Fat binary gen_snapshot should be converted to an ARM-only thin binary

STAGE 4 BREAKDOWN

macOS

• FlutterMacOS.xcframework should be converted to ARM-only (e.g. macos-arm64_x86_64 -> macos-arm64)

• Unless if Intel-supporting macOS apps can still be built from ARM machines using the latest Xcode, we should still build the Intel variant for the FlutterMacOS.xcframework

• Thin binary flutter_tester should only be built for ARM
• Thin binary font-subset should only be built for ARM
• Thin binary gen_snapshot should only be built for ARM
• Fat binary gen_snapshot_arm64 (remove?)
• Fat binary gen_snapshot_x64 (remove?)
• Thin binary impellerc should only be built for ARM
• Thin binary libpath_ops.dylib should only be built for ARM
• Thin binary libtessellator.dylib should only be built for ARM

Other

• Intel specific DEPS can be removed (1, 2, 3, 4)
• Intel specific toolchains can be removed (1, 2)
• Remove Intel specific skia things (1, 2, 3)