Possible removal of Build with Xcode (BwX) mode in a future update

[brentleyjones]

Build with Bazel (BwB) mode is the default and fully supported mode of rules_xcodeproj. BwX mode on the other hand is supported as best we can.

We are currently rewriting the generator to use an improved architecture, which will unlock big performance improvements. BwX mode has special requirements in the data it collects, and on the shape of the generated project, which has impacted the current architecture. If we were required to continue to support BwX mode (or at least support all of the same capabilities as we do today) then we won't be able to have the best possible BwB performance, saying nothing of the additional work needed to re-implement the BwX specific pieces in the rewrite.

So, given all of that, we wanted to make sure we heard for you, the community, on your usage of BwX mode. But in particular, we wanted to know if having a BwX mode was a hard requirement for you.

[CognitiveDisson]

I voted to remove the BwX mode (No).

Here are a few use cases we've seen for the BwX mode:

• We considered using Xcode mode to investigate indexing issues if they came up, but the index build log was sufficient in all cases.
• It could be a Plan B if something really bad and unfixable happens with Bazel.
• We may need Xcode mode to check new features of Xcode that may not be supported with Bazel mode and could be hard to implement with it.
• Xcode mode can be useful for comparison with Bazel mode, in terms of performance (building without any cache) and for checking the flags passed to the compiler, linker, etc.

So far, none of these use cases have happened. Additionally, Xcode mode has never actually worked for us.

[brentleyjones]

Additionally, Xcode mode has never actually worked for us.

AFAIK it has, at least in a limited capacity, since I recall having Patrick test it on occasion?

[CognitiveDisson]

From time to time, with some additional fixes, we were able to make it work.

[BalestraPatrick]

I can confirm that BwX mostly works for our project after removing some specific linker flags which aren't really translatable/don't work properly in Xcode.

[sanju-naik]

+1 to all the above points by @CognitiveDisson . our thought process is also the same around why we need BwX and having it gives that extra confidence to remove our In-house Xcodegen setup and 100% rely on rules_xcodeproj.

As of today, our Bazel migration is still in progress, and we have our In-house Xcodegen setup which generates projects for BwX, so having BwX in rules_xcodeproj gives us enough confidence to remove our in-house version.

[brentleyjones]

I don't see a "yes" or "possibly" vote yet, which seems to align with what you are saying? You use the word "need", which implies to me that a "no" vote ("The removal of BwX mode would not prevent you from using rules_xcodeproj"). Just checking to confirm I understand your comment correctly.

[sanju-naik]

Yes, that's correct. added my vote as well. Removing BwX won't stop us from using rules_xcodeproj but it would be really great to have BwX support.

[erikkerber]

Also voted "No" per the question, because of how important and transformational rules_xcodeproj is to our project. These issues are inconveniences that would not block us from using rules_xcodeproj (or forking it), but would be a detriment to some use cases and may reduce observability/confidence.

My assumption is the benefits for dropping BwX outweigh the detriments—if not only for the reasons stated above but maintainability as well. BwX simply adds overall complexity. With that said, these are what would concern us most:

Performance "Control"

Today, we have a performance gap between BwB and BwX. The gap is largely rooted in performance issues related to hashing (bazelbuild/bazel#18614) and will "just be fixed" in future releases via the BLAKE3 hashing algorithm.

Without BwX, we would have no easy way of knowing if our builds were on par with an equivalent xcodebuild build. If future enhancements to Swift are introduced (swiftc, driver, linker, etc) that require improvements to our setup or rules, it will be harder for us to identify them.

Long Tail of Niche Xcode Features

Our developers often want to use all of the debug tools Xcode provides. Most of these work, but sometimes new or more complex debug features do not. Some debug features our developers use BwX for include:

1. Unable to debug BGTaskScheduler with BwB
2. Unable to navigate to source using Malloc Stack Logging
3. Unable to navigate to source using Thread Performance Checker

Each of these are essentially paper-cuts, and all almost certainly could be fixed with contributions. My assumption is that there will always be some combination of unknown bugs, or new Xcode features, that will prevent developers from using them if we only have BwB.

[thiagohmcruz]

For us the use case would be allow devs to test new features that are not yet supported or fully supported in Bazel.

That said, seeing the other comments here wanted to +1 that it could be useful for folks in the process of migrating to Bazel or from other generators (been there).

I'm personally not against removing it though since there's a major blocker for us: it doesn't work with rules_ios. I know that BwX support for rules_ios was never a goal though, so my vote should have less weight than who's depending on it.

[lgreydev]

I agree with the author.

[louwers]

BwB is quite slow for us, because it is not building in parallel. Maybe there is a fix for this.

Sometimes BwB also fails to find a provisioning profile. If we can make a reproduction of this we will make a bug report.

[louwers]

@mwilsnd According to @brentleyjones BwB should build in parallel.

There is swiftlang/swift-llbuild#841, but because we no longer do target dependencies in BwB, it should all be parallel.

Could you explain what you are observing?

[louwers]

I have the same issue now (again). This is the issue that is would be a blocker for us (inability to run on device tests with BwB) #2395

Also we are still using xcodebuild to create XCTest bundles for AWS Device Farm, but that seems to work with BwB somehow. https://github.com/maplibre/maplibre-native/blob/main/.github/workflows/ios-ci.yml#L162

[brentleyjones]

An update: Bazel 7 makes it really hard to support BwX mode, so it's been disabled there. Also, the new incremental generation mode that is coming out soon also drops support for BwX mode. Thanks for everyone's feedback!