[native assets] Respect Apple deployment targets - #194146

I think we should aim for the version number that comes from the xcode build to flow into flutter assemble which should then flow properly into the build hooks (and the metadata). Only fixing the metadata makes it inconsistent.

(Maybe we should do MacOS and iOS in the same PR? Aren't their constraints rather similar?)

Here is an AI explanation on how to do this following a similar pattern as #181004 takes for wiring the ccompiler info from cmake to the build hooks:

To wire the deployment target into IOSCodeConfig (and optionally MacOSCodeConfig) following the same pattern as Android's targetAndroidNdkApi(environmentDefines), the version resolution should live in ios/native_assets.dart as a function of environmentDefines and be consumed by both IOSAssetTarget (during BuildHooks / LinkHooks) and copyNativeCodeAssetsIOS (during InstallCodeAssets).

Here is the step-by-step wiring across the 4 files:

1. Forward the Xcode build setting in xcode_backend.dart & build_info.dart

(PR #194146 already does this part for iOS)

• In build_info.dart:

  const kIosDeploymentTarget = 'IosDeploymentTarget';

• In xcode_backend.dart:

  final String? deploymentTarget = environment['IPHONEOS_DEPLOYMENT_TARGET'];
  if (deploymentTarget != null) {
    flutterArgs.add('-d$kIosDeploymentTarget=$deploymentTarget');
  }

2. Replace const targetIOSVersion = 15 with a Version-returning helper in ios/native_assets.dart

Mirror targetAndroidNdkApi(Map<String, String> environmentDefines) so both targets.dart and copyNativeCodeAssetsIOS use the same function (and use FlutterDarwinPlatform.ios.deploymentTarget() as the baseline):

Version targetIOSVersion(Map<String, String> environmentDefines) {
  final Version minimumSupported = FlutterDarwinPlatform.ios.deploymentTarget();
  final String? target = environmentDefines[kIosDeploymentTarget]?.trim();
  if (target == null || target.isEmpty) {
    return minimumSupported;
  }
  final Version? version = Version.parse(target);
  if (version == null || Version.versionPattern.firstMatch(target)?.end != target.length) {
    throwToolExit(
      'Invalid iOS deployment target "${environmentDefines[kIosDeploymentTarget]}". '
      'Expected a version such as 16, 16.4, or 17.2.1.',
    );
  }
  if (version < minimumSupported) {
    return minimumSupported;
  }
  // Ensure major-only inputs like "16" format as "16.0" in Info.plist while
  // preserving minor/patch versions like "16.4" or "17.2.1".
  if (!target.contains('.')) {
    return Version(version.major, version.minor, null);
  }
  return version;
}

3. Wire targetIOSVersion(environmentDefines) into IOSAssetTarget in targets.dart

IOSAssetTarget already receives environmentDefines, so _getIOSConfig in targets.dart only needs to call targetIOSVersion(environmentDefines).major:

  IOSCodeConfig _getIOSConfig(Map<String, String> environmentDefines, FileSystem fileSystem) {
    final String? sdkRoot = environmentDefines[kSdkRoot];
    if (sdkRoot == null) {
      throw MissingDefineException(kSdkRoot, 'native_assets');
    }
    final EnvironmentType environmentType = xcode.environmentTypeFromSdkroot(sdkRoot, fileSystem);
    return IOSCodeConfig(
      targetVersion: targetIOSVersion(environmentDefines).major,
      targetSdk: getIOSSdk(environmentType),
    );
  }

Because AssetBuildTarget.targetsFor(...) is called at the start of BuildHooks (and LinkHooks):

• Build and link hooks receive input.config.code.iOS.targetVersion == 16 (instead of 15) when IPHONEOS_DEPLOYMENT_TARGET is 16.4.
• Any malformed kIosDeploymentTarget fails fast during build_hooks before running any hooks or copying frameworks.
• Once package:code_assets supports minor/patch versions in IOSCodeConfig, targetIOSVersion(environmentDefines) already returns a full Version object with .major, .minor, and .patch.

4. Use the same helper in installCodeAssets / copyNativeCodeAssetsIOS

Instead of passing raw String? iosDeploymentTarget and re-parsing it inside copyNativeCodeAssetsIOS, either:

• Pass targetIOSVersion(environmentDefines) (or environmentDefines) to copyNativeCodeAssetsIOS, and pass minimumIOSVersion: deploymentTarget.toString() to createInfoPlist.

(And if doing macOS at the same time: MacOSAssetTarget can take Map<String, String> environmentDefines in _macTargets—and const <String, String>{} in FlutterTesterAssetTarget—and call targetMacOSVersion(environmentDefines).major.)

@dcharkes Agreed that the app deployment target should reach both build/link hooks and the packaged metadata, and that iOS and macOS should be handled together.

The remaining precision prerequisite is in package:code_assets: both Apple targetVersion fields are integers, so passing .major still truncates values such as 16.4 or 17.2.1. I opened dart-lang/native#3741 and draft dart-lang/native#3742 proposing compatible optional minor/patch fields and migrating the C toolchain, Objective-C hook, and ffigen test hook. The draft covers iOS and macOS; it has 692 passing affected tests, but full CI is not green and the baseline failures are disclosed there.

Once the API shape is agreed and available for Flutter to consume, the follow-up here is to use one resolved version per platform for build/link configuration and metadata, forward MACOSX_DEPLOYMENT_TARGET as well as IPHONEOS_DEPLOYMENT_TARGET, and add propagation/cache/default/error tests for both platforms. I will preserve the existing native-assets floors (iOS 15 and macOS 13); the shared Darwin macOS floor is currently 12, so switching to it directly would change behavior.

This Flutter patch currently only fixes iOS framework metadata. It does not yet implement full hook propagation or the macOS configuration change.

@dcharkes this should be ready for another look. I went with your suggestion: the deployment target now goes through flutter assemble into the build and link hooks as well as the framework metadata, and iOS and macOS are both in this PR. Minor and patch versions are kept now that code_assets 2.2.0 is rolled in.

macOS needed one extra step. The assemble script runs in the Flutter Assemble target, which doesn't see Runner's MACOSX_DEPLOYMENT_TARGET, so I have buildMacOS write Runner's value into Flutter-Generated.xcconfig and the script picks it up from there. The downside is that a build started straight from Xcode gets whatever the last flutter build or flutter run wrote. Let me know if you'd rather solve that differently.

Could someone add the CICD label so the full suite runs? Thanks!

Thanks @leehack! 🙏

macOS needed one extra step. The assemble script runs in the Flutter Assemble target, which doesn't see Runner's MACOSX_DEPLOYMENT_TARGET, so I have buildMacOS write Runner's value into Flutter-Generated.xcconfig and the script picks it up from there. The downside is that a build started straight from Xcode gets whatever the last flutter build or flutter run wrote. Let me know if you'd rather solve that differently.

That is somewhat unfortunate. However, it's more important for iOS where we have add2app and there might not be an outer flutter run to populate the value. So I think this is okay.

FYI @bkonyi