Migrate flavors_test_ios to Simulators and add UIScene support

[okorohelijah]

Part of #186414. This PR introduces the testWithNewIOSSimulator helper pattern to execute the flavors_test_ios on macOS VMs rather than physical lab devices. This also migrates the old flavors test app to adopt the UIScene lifecycle using FlutterSceneDelegate.

[gemini-code-assist]

Code Review

This pull request updates several iOS device lab targets in .ci.yaml to run on arm64 hosts, and refactors flavors_test_ios.dart and related integration test utilities to run on a newly created iOS simulator using a provided device ID. It also adds scene manifest configurations to the iOS plist files. A review comment points out that the manual simulator cleanup in flavors_test_ios.dart is redundant and will cause failures because testWithNewIOSSimulator already manages the simulator lifecycle.

[gemini-code-assist]

Code Review

This pull request updates several iOS devicelab tasks to run on a simulator instead of a physical device, introducing a deviceIdOverride parameter to target specific simulator instances, and configures UIApplicationSceneManifest in the plist files. Feedback highlights two issues: first, wrapping testWithNewIOSSimulator in an outer try-finally block to delete the simulator is redundant and will cause errors; second, when deviceIdOverride is provided, selectedDevice remains null, which will break the withTalkBack check.

[okorohelijah]

This is a prototype PR to propose and discuss the architectural strategy for moving iOS UI/Functional tests off physical lab devices and onto Mac VM simulators (resolving #186414) before applying the pattern broadly.

The Approach:
Instead of ripping these UI tests out of the dev/devicelab harness and rewriting them into the test.dart integration shards, we are keeping them within the Devicelab framework. We decouple the tests from physical hardware by injecting an isolated, ephemeral iOS Simulator during the test's execution phase, allowing us to safely migrate the .ci.yaml targets from the physical hardware pool (Mac_ios) to the standard Swarming VM pool (Mac_arm64).

Why keep them in Devicelab instead of rewriting them?

1. Preservation of Testing Frameworks: The devicelab tasks heavily utilize the IntegrationTest and DriverTest factory classes, which handle complex, test-specific orchestration (temporary project scaffolding, --dart-define injections, platform setups). Moving to test.dart would require discarding and recreating all this framework glue.

2. CI Isolation: Devicelab maps one .ci.yaml builder strictly to one test script. When a test crashes or hangs, you immediately get a 1:1 mapped LUCI build failure. Integration shards bunch many tests together, meaning one severe crash/hang can take down the whole shard and mask downstream failures.

3. Safety & Reversibility: If a specific test ends up catching an obscure bug that only manifests on physical iOS devices, we can instantly revert that specific test back to the Mac_ios hardware pool without needing to rewrite it back into the Devicelab framework.

Trade-offs:

• Moving away from a globally provisioned simulator (like in test.dart shards) means we incur a small overhead to manage the simulator boot/teardown lifecycle within each isolated task script.

[okorohelijah]

Here is the comprehensive list of Devicelab targets I plan to migrate using this strategy.

Compile-Only Tasks

These tasks only verify that an iOS project can successfully build (running flutter build ios and inspecting the generated artifacts). Because they never invoke devices.workingDevice or launch an app, they can be safely moved to the Mac VM pool with a simple .ci.yaml change. (Note: Tests like build_ios_framework_module_test were already running on Mac_arm64 and are thus omitted).

• basic_material_app_ios__compile
• flutter_gallery_ios__compile
• hello_world_ios__compile
• imitation_game_flutter__compile
• imitation_game_swiftui__compile

Functional / UI Tests

These tasks verify UI layout, platform channels, and debugging workflows. While they do require launching an app, they do not measure raw device performance (unlike our benchmarking tasks, which must remain on physical hardware to prevent skewed metrics). We will migrate these by injecting the testWithNewIOSSimulator wrapper.

• flavors_test_ios (✅ Prototyped in this PR)
• channels_integration_test_ios
• external_textures_integration_test_ios
• route_test_ios
• integration_test_test_ios
• integration_ui_ios_driver
• integration_ui_ios_frame_number
• integration_ui_ios_keyboard_resize
• integration_ui_ios_screenshot
• integration_ui_ios_textfield
• ios_defines_test
• hello_world_impeller_ios_sdfs
• ios_platform_view_tests
• native_platform_view_ui_tests_ios
• platform_channel_sample_test_ios
• platform_channel_sample_test_swift
• platform_interaction_test_ios
• spell_check_test_ios
• keyboard_hot_restart_ios
• plugin_test_ios
• module_test_ios
• module_uiscene_test_ios

[vashworth]

LGTM after one request

[vashworth]

Here is the comprehensive list of Devicelab targets I plan to migrate using this strategy.

Compile-Only Tasks

These tasks only verify that an iOS project can successfully build (running flutter build ios and inspecting the generated artifacts). Because they never invoke devices.workingDevice or launch an app, they can be safely moved to the Mac VM pool with a simple .ci.yaml change. (Note: Tests like build_ios_framework_module_test were already running on Mac_arm64 and are thus omitted).

• basic_material_app_ios__compile
• flutter_gallery_ios__compile
• hello_world_ios__compile
• imitation_game_flutter__compile
• imitation_game_swiftui__compile

Functional / UI Tests

These tasks verify UI layout, platform channels, and debugging workflows. While they do require launching an app, they do not measure raw device performance (unlike our benchmarking tasks, which must remain on physical hardware to prevent skewed metrics). We will migrate these by injecting the testWithNewIOSSimulator wrapper.

• flavors_test_ios (✅ Prototyped in this PR)
• channels_integration_test_ios
• external_ui_integration_test_ios
• route_test_ios
• integration_test_test_ios
• integration_ui_ios_driver
• integration_ui_ios_frame_number
• integration_ui_ios_keyboard_resize
• integration_ui_ios_textfield
• ios_defines_test
• hello_world_impeller_ios_sdfs
• ios_platform_view_tests
• native_assets_ios
• native_platform_view_ui_tests_ios
• platform_channel_sample_test_ios
• platform_channel_sample_test_swift
• platform_interaction_test_ios
• wide_gamut_ios
• ios_debug_workflow
• spell_check_test
• keyboard_hot_restart_ios

Can you move this comment to the tracking issue?

[vashworth]

Suggested change

	- name: Mac_arm64 flavors_test_ios
	- name: Mac flavors_test_ios

I don't think there's a reason this needs to run exclusively on arm

[vashworth]

Correct me if I'm wrong

[okorohelijah]

not wrong, I had added it because we are deprecating intel(not that it affects per se) and also intel is slower

[auto-submit]

autosubmit label was removed for flutter/flutter/189442, because - The status or check suite Dashboard Checks has failed. Please fix the issues identified (or deflake) before re-applying this label.