zlacker

All of this could be avoided if their CLIs worked reliably and well. Instead the randomly fail (you fix them by running the same task from Xcode), and output 5k lines of useless unstructured output (tools like xcbeautify try to help but it’s an uphill battle).

I feel like Xcode knows how to work around xcodebuild’s shortcomings, and instead of fixing them they just wrapped Xcode in an MCP server.

Better than nothing I guess, but reliable CLIs would allow a whole ecosystem of tools.

>>scosma+(OP)
This is true of the CLIs that start with `xcode` but not of the CLIs that start with `swift`. As `swift-format` and `swift-test` have come into their own, they're just as reliable as any other language ecosystem. And the difference is indeed staggering. I wrote this guide last summer on extracting all your app's code into a (nonsensically necessary) Swift package dependency simply so you can test it with Swift Testing https://justin.searls.co/posts/i-made-xcodes-tests-60-times-...

>>searls+N4
Yes! If you’re lucky enough to be writing a library you are in good shape. Swift did things right.

I have UI and UI tests and xcodebuild is my nemesis.

>>scosma+Lj
That’s why you should break out all of your code into SPM packages/targets. The workspace code only really needs to be the entry point, lifecycle and maybe target-based dependency injection (if you’re into that) or environment config since your SPM dependencies don’t know about your projects preprocessor macros (I.e. `#if DEV` `#if APP_STORE` etc.).