Yea that one is fine and well covered in the blog post, and pretty easy to spot in light testing. I'm much more worried about the ones that are harder to spot until you have a false negative that turns into a real bug which would be caught by 1 tool and not another.
Can you add some examples of the things users care about that aren't well covered by this? I empathize with everyone who wants a feature comparison chart so they can be confident switching without unknowingly losing important safety checks.
This isn't the primary part of this conversation but I found this quote pretty interesting:
> Now, we are starting to work on Safari again but look at Chrome. They put out releases at least every month while we basically do it once a year.
Even though this was in 2013 nothing about the release cycle (still only major changes with the major OS release versions). I wonder if some of the other emails have more context on this.
I've had similar problems contributing to bazel (Google's open source build tool) for the past few years. I've found contributing only goes smoothly if there is a single Googler working in your area who cares about open source. Otherwise everything is very Google centric and the open source community is definitely a secondary concern (which is of course their right!)
In this case I meant taking an approach similar to this one for bazel[0] that is not limited to only code that works on Linux. It would only allow you to build on Linux and would require any testing / running would still happen on macOS, but that might still be worth it in some cases. Theoretically you could deploy your iOS app that way as well.
For bazel users there is also this project[0] which runs the tools natively on Linux without requiring this layer. Although you lose tools like ibtool / actool which don't have open source re-implementations.
This does generally work, but it requires a lot of manual effort to setup the environment correctly with Xcode's SDKs to satisfy the compiler / linker.
> The entire pbxproj format is horrible, but at least you have stuff like BUCK (https://buckbuild.com/) that can mitigate some of that.
FWIW I'm still not sure what the BUCK workflow is suppose to look like for most teams. It seems like if you use BUCK you're expected to not use Xcode even as an editor, yet there isn't another editor to pick up the slack (assuming you want autocompletion and decent highlighting). I think there's still a lot of work to be done for it to be a viable replacement, even for Objective-C, for Swift it's even further away.
The videos from many WWDC sessions are altered. So even if you got the right session it may not have this. I've been in sessions where much less interesting this have happened that haven't made it in to the video. Also last WWDC they started pre-recording sessions so they could be up on the web sooner. Many of the video sessions from last year don't have any audience noise and differ significantly from the live session.