`ios_build_test` and `ios_application ` cannot be directly used with default platform from apple_support

[yyuting]

on Bazel 7.0.2 and rule_apple 3.3.0, I'm unable to use ios_build_test and ios_application with the default platform from apple_support.

Here's a minimum example with a hello world ios_build_test target.
https://github.com/yyuting/bazel_apple_platform/tree/main

The target is set to only be compatible with ios arm64 device (not simulator).

Build succeeds with a custom platform and explicit platform mapping:

bazel test //:ios_build_tests --platforms=//:platform_ios

But building with the default ios_arm64 platform from apple_support would fail, it seems apple rules is picking up ios_sim_arm64 for the cc_library that the ios_build_test target depends on.

bazel test //:ios_build_tests --platforms=@build_bazel_apple_support//platforms:ios_arm64

Here's the error message:

Target //:ios_build_tests failed to build
Use --verbose_failures to see the command lines of failed build steps.
ERROR: Analysis of target '//:ios_build_tests' failed; build aborted: Target //:ios_build_tests is incompatible and cannot be built, but was explicitly requested.
Dependency chain:
    //:ios_build_tests (7e114e)
    //:hello_world (9a2e98)   <-- target platform (@@build_bazel_apple_support//platforms:ios_sim_arm64) didn't satisfy constraint @@platforms//:incompatible
INFO: Elapsed time: 0.097s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
ERROR: Build did NOT complete successfully
ERROR: No test targets were found, yet testing was requested

[keith]

In your example your first command works because of your platform_mappings file. If you want the second command to work you'd have to add that entry to the platform_mappings file as well

[yyuting]

Thanks! According to the discussion in #1658 , I thought we no longer need platform_mappings on bazel 7.x+. Or am I missing something?

[keith]

hrm yea interesting. so the problem is that currently --ios_multi_cpus takes precedence over the --platforms setting. This happens with the default value even though you're not passing it explicitly. It's because of our current transition for this. We are following in google's footsteps here and it looks like they're still using the same behavior there too. I'm not sure what implications of changing that would be.

this is actually the same as #1650

[yyuting]

thanks for the explanation!