Unable to locate Xcode 12.5.1 when building on macOS Monterey beta 7

[timsutton]

Description of the problem / feature request:

As of macOS 12 Monterey beta 7, Bazel's xcode locator logic is not able to expose Xcode 12.5.1 as a usable version.

Apple does not officially support Xcode 12.5.1 on Monterey (this is new to beta 7, but is behaviour expected to stay).

Apple isn't supporting Xcode 12 on Monterey because debugging does not work - however, it seems still very capable at building projects.

Feature requests: what underlying problem are you trying to solve with this feature?

Be able to specify Xcode 12.5.1 as an Xcode version when building on macOS Monterey.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Upgrade a macOS system to Monterey beta 7
2. Install Xcode 12.5.1
3. From the HEAD of bazelbuild/bazel, run: bazel run tools/osx:xcode-locator, which will output the list of mappings of version keys to Xcode paths.

What operating system are you running Bazel on?

macOS Monterey beta 7:

$ sw_vers
ProductName:	macOS
ProductVersion:	12.0
BuildVersion:	21A5506j

What's the output of bazel info release?

release 4.2.1

Have you found anything relevant by searching the web?

Apple's brief notes about this:

• https://developer.apple.com/news/?id=ufox7ci5
• Monterey beta 7 release notes, stating Xcode 12.5.1 won’t launch on macOS Monterey.

I've heard from other contacts at Apple that this behaviour is expected to stay in Monterey, i.e. that it's not some transient issue with beta 7.

Any other information, logs, or outputs that you want to share?

The underlying reason 12.5.1 doesn't show up usable on Monterey is because LaunchServices considers it not able to be launched, that its version is too low. It's the same reason one can't launch the app by double-clicking it in the finder, but it can be still executed directly at the command line and xcodebuild CLI builds seem to work still fine.

The API used is LSCopyApplicationURLsForBundleIdentifier here in bazel.

In this gist I tried calling this API on beta 6 and beta 7 systems to compare the difference, and so it seems like something at the OS level knows for LaunchServices to mark this Xcode version as too old.

I realize it's potentially a stretch to try and work around this, seeing as Apple doesn't officially support it, and that the supported path is to instead migrate a project to Xcode 13+. However, I'm wondering if there's some sane way to force specifying Xcode 12.5.1 either via the locator or to somehow otherwise override its output with a known fixed path to an Xcode 13 bundle?

[keith]

Realistically I think the most viable potential path here is to figure out specifically what launch services is using to exclude Xcode 12.5.1 from the results, and change that in your Xcode installs. In the past I had this issue with newer versions of Xcode where changing the minimum system version to be lower made launch services discover it.

I think the second most viable approach, if you're willing to build and distribute your own version of bazel, would be to replace the Xcode locator tool at build time with one that you alter to have this custom behavior in (even if you use your own cc toolchain there is a pre-compiled xcode locator binary bundled with the bazel distribution that I think would also have to be updated)

Besides those options I don't think there is any way to make bazel pick this up without making some weird changes in Xcode locator, which we probably wouldn't want to do because of the explicit unsupported state of this

[timsutton]

@keith Yeah, both of these approaches you suggest seem sensible.

The minimum version constraint is interesting in this case (a minimum Xcode required rather than a minimum OS version), ie nothing I see inside the app bundle's plist that would somehow constrain the macOS version (and it is fine in b6). But maybe there are some keys that b7 is programmed to reject as being incompatible.

I will keep digging to see if there is some way to do convince LaunchServices otherwise.

Figured this issue was worth filing here regardless of Apple's support for this version combination, so that if others have the same need there is some common thread to refer to.

[steeve]

We got it running and recognized by LSCopyApplicationURLsForBundleIdentifier by overwriting the Info.plist from Xcode 13.1, launching, and restoring it back. And then our bazel build ran fine. Which seems to confirm that the nag screen is purely cosmetic.
I'm going to find out which key is responsible for this. This is hard to test as once Xcode has been recognized, it stays recognized.

I'm using my script #14174 to debug LSCopyApplicationURLsForBundleIdentifier.

[steeve]

I found a workaround, see https://blog.zen.ly/xcode-12-5-on-macos-monterey-23c257260316.

The trick is to use Xcode 13's CFBundleVersion in Xcode 12 to let Launch Services register it. After that, xcode_locator properly detects Xcode 12.5 on Monterey.

[timsutton]

Going to close this original issue as I don't think it's something that can/should be reasonably fixed via Bazel's Xcode locator.