Fix flutter run on Mac x64 hosts if Swift Package Manager is enabled

[loic-sharma]

Problem

Enabling the Swift Package Manager feature caused post-submit tests to fail on Mac x64 hosts:

Example error...

https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20rrect_blur_perf_ios__timeline_summary/575/overview

♦ ... flutter --verbose assemble ... -dIosArchs=x86_64 ... profile_unpack_ios

Target profile_unpack_ios failed:
Exception: Binary ... build/ios/Profile-iphoneos/Flutter.framework/Flutter does not contain x86_64.

Running lipo -info:
Non-fat file: ... build/ios/Profile-iphoneos/Flutter.framework/Flutter is architecture: arm64

#0      UnpackIOS._thinFramework (package:flutter_tools/src/build_system/targets/ios.dart:351:7)
<asynchronous suspension>
#1      UnpackIOS.build (package:flutter_tools/src/build_system/targets/ios.dart:298:5)
<asynchronous suspension>
...

Reproduction

On a mac x64 host:

1. Switch to the latest master channel: flutter channel master ; flutter upgrade
2. Disable the Swift Package Manager feature: flutter config --no-enable-swift-package-manager
3. Create a Flutter project
4. Edit the Xcode project manually to add the prepare pre-action
5. Run flutter run (flutter build ios does not reproduce this issue).

Background

Previously, the Flutter framework was unpacked in the Xcode target's build. Unfortunately, this happens after Swift packages are built; this prevented Swift packages from using the Flutter framework.

To fix this, we added an Xcode pre-action that unpacks the Flutter framework before Swift Package Manager builds packages. The Xcode target still runs the Flutter framework unpack step, but this step no-ops if both unpack steps have the exact same inputs.

flowchart LR
  A[flutter run -d iphone] --> B(Build Xcode project)
  B --> C(Xcode 'prepare framework' pre-action)
  B --> G[Build Swift packages]
  B --> D(Build 'Runner' target)
  C --> E[Unpack Flutter framework #1]
  D --> F["
  Unpack Flutter framework #2
  (No-ops if inputs are same as #1)
  "]

Loading

#150052 added an optimization that made it more likely the second unpack step no-ops by fixing a case where the target architecture input could be different:

When using SwiftPM, we use flutter assemble in an Xcode Pre-action to run the debug_unpack_macos (or profile/release) target. This target is also later used in a Run Script build phase. Depending on ARCHS build setting, the Flutter/FlutterMacOS binary is thinned. In the Run Script build phase, ARCHS is filtered to the active arch. However, in the Pre-action it doesn't always filter to the active arch. As a workaround, assume arm64 if the NATIVE_ARCH is arm, otherwise assume x86_64.

This optimization is only applied if ONLY_ACTIVE_ARCH is YES.

Important

ONLY_ACTIVE_ARCH's name is misleading. It specifies whether the product includes only object code for the native architecture.

A value of YES means the product includes only code for the native architecture (NATIVE_ARCH).

A value of NO means the product includes code for the architectures specified in ARCHS (Architectures).

Problem

buildXcodeProject incorrectly always sets ONLY_ACTIVE_ARCH to YES if the Xcode built is for a single architecture:

flutter/packages/flutter_tools/lib/src/ios/mac.dart

Lines 353 to 361 in 6abef22

	if (activeArch != null) {
	final String activeArchName = activeArch.name;
	buildCommands.add('ONLY_ACTIVE_ARCH=YES');
	// Setting ARCHS to $activeArchName will break the build if a watchOS companion app exists,
	// as it cannot be build for the architecture of the Flutter app.
	if (!hasWatchCompanion) {
	buildCommands.add('ARCHS=$activeArchName');
	}
	}

This is incorrect! If the host architecture is x64 but the target architecture is arm64, ONLY_ACTIVE_ARCH should be NO.

This caused the prepare pre-action to incorrectly use x64 as the target architecture for arm64 devices on an x64 host, which in turn caused builds to fail if Swift Package Manager was enabled.

Solution

This change updates buildXcodeProject to set ONLY_ACTIVE_ARCH correctly.

This change also updates the prepare pre-action's to be more conservative in applying the optimization that filters the target architecture. This ensures that the build still works (but without the optimization) if ONLY_ACTIVE_ARCH is incorrectly set.

Follow-up PR: #154649

This unblocks: #151567

DeviceLab test

This problem reproduces if you flutter run to an iPhone Arm64 device from an x64 mac host with the Swift Package Manager feature enabled.

I ran an affected DeviceLab test to verify the fix works as expected:

Description	CI test	Result
SwiftPM enabled without this fix: #154750	Link	❌
SwiftPM enabled with this fix: #154749	Link	✅

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[jmagman]

A value of YES means the product includes only code for the native architecture (NATIVE_ARCH).

A value of NO means the product includes code for the architectures specified in ARCHS (Architectures).

It means the native arch of the target phone or simulator, not the host Mac arch. If this is on a Mac x64 machine but targeting a physical arm64 device, I don't think this would work?

[loic-sharma]

If this is on a Mac x64 machine but targeting a physical arm64 device, I don't think this would work?

Here's a devicelab test that verifies this works on a Mac x64 machine targeting a physical arm64 device:

Description	Host machine	Target machine	CI test	Result
SwiftPM enabled without fix #154750	Mac x64	Physical arm64 device	Link	❌
SwiftPM enabled with fix #154749	Mac x64	Physical arm64 device	Link	✅

It means the native arch of the target phone or simulator, not the host Mac arch.

As in, NATIVE_ARCH is the native arch of the target phone or simulator? If so, I don't think that's true.

NATIVE_ARCH's docs:

Identifies the architecture on which the build is being performed (same as CURRENT_ARCH).

Also see this devicelab test of a x64 host for arm64 target: https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8737518504062464913/+/u/run_rrect_blur_perf_ios__timeline_summary/stdout

[2024-09-06 12:18:31.283585] [STDOUT] stdout:                 export ARCHS\=arm64
...
[2024-09-06 12:18:31.286058] [STDOUT] stdout:                 export NATIVE_ARCH\=x86_64
...
[2024-09-06 12:18:31.288132] [STDOUT] stdout:             ♦ /opt/s/w/ir/x/w/rc/tmpbd9z5dzh/flutter sdk/bin/flutter --verbose assemble --no-version-check --output=/opt/s/w/ir/x/w/rc/tmpbd9z5dzh/flutter sdk/dev/benchmarks/macrobenchmarks/build/ios/Profile-iphoneos/ -dTargetPlatform=ios -dTargetFile=test_driver/run_app.dart -dBuildMode=profile -dIosArchs=arm64 -dSdkRoot=/opt/flutter/xcode/15a240d/XCode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS17.0.sdk -dSplitDebugInfo= -dTreeShakeIcons=false -dTrackWidgetCreation=true -dDartObfuscation=false -dAction=build -dFrontendServerStarterPath= --ExtraGenSnapshotOptions= --DartDefines= --ExtraFrontEndOptions= -dCodesignIdentity=6475AE66068783D9C7566E71522EA3915C7D6C9A profile_ios_bundle_flutter_assets

[jmagman]

Thanks for investigating! I didn't have the details paged in.