This is the most common way to get the path to the selected instance:
xcrun xcode-select --print-pathI recently spent a few hours helping a friend of mine investigate a weird issue in their Continuous Development infrastructure. Builds were failing with different fatal errors mostly related to SDK paths and .platform directory locations. At first sight, it was clear that something is wrong with the current selected Xcode, but all our initial attempts to catch the problem failed.
In the end, we isolated the problem; one of the tools they use changes PATH silently for the environment to simplify access to Xcode tools. Due to their internal logic, the CD pipeline changes a current selected Xcode a few times on the way within the same script. In some cases, the pipeline ended with xcodebuild in the environment's PATH that does not reflect the expected version after the xcode-select --switch command.
How? Pretty easy, actually. A simplified sequence looked like this:
xed is a command-line tool that launches the Xcode application and opens the given documents (xcodeproj, xcworkspace, etc.), or opens a new document, optionally with the contents of standard input.
If you work from the command line, this tool is a better option than open (which can open Xcode projects as well). Why?
xed knows about the current selected Xcode version (open behaves unpredictably if you have multiple Xcode installed)At the moment id don´t know how to authenticate so i have no clue to download the xip via curl/wget.
In my case i downloaded the file and copied it via scp to my mac.
eg. for Xcode 9.2 https://developer.apple.com/services-account/download?path=/Developer_Tools/Xcode_9.2/Xcode_9.2.xip
pkgutil --verbose --check-signature path/to/xip