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.