This is the most common way to get the path to the selected instance:
xcrun xcode-select --print-path
I 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