Note: the device names changed in Xcode 7, so you no longer specify them using iPhone 5 (9.1 Simulator) but rather iPhone 5 (9.1).

Use xcrun instruments -s to get the current list of devices and then you can pre-launch it using:

xcrun instruments -w "iPhone 5 (9.1)" || echo "(Pre)Launched the simulator."

Prelaunching

I got to a point where what I proposed down there wasn't working anymore. In addition to making the changes mentioned here, you need to launch the simulator xcodebuild is expecting BEFORE xcodebuild is ran:

# First get the UDID you needxcrun instruments -s# Then launch itopen -a "iOS Simulator" --args -CurrentDeviceUDID <sim device UDID># and wait some time....sleep 5# Then launch your unit testsxcodebuild [...] -destination 'platform=iOS Simulator,name=<device name matching the UDID>' 

Old post

This bug is fixed in Xcode 6.3 and above. If you are experiencing similar problems in newer Xcode, it's likely another bug.

Apple follow up regarding Bug ID# 18001199:

The context provided by LaunchDaemons is not supported for running GUIapplications. The SSH service, and the default setup for Jenkins, areboth implemented as LaunchDaemons. In earlier versions of Xcode 5xcodebuild could run tests on the iOS simulator in this context, butthat was never a supported configuration, and as you have noted thatis no longer working as of Xcode 6.

Unlike LaunchDaemons, LaunchAgents provide a context where you can runGUI applications - if the user is logged in at the time, with a windowserver / Aqua session. Converting your Jenkins configuration frombeing a LaunchDaemon to being a LaunchAgent would avoid the reportedissue. You can also use launchd for running tests on the iOS simulatorfrom a SSH session, either by crafting a LaunchAgent and manuallyloading / starting that, or by using "launchctl submit”.

Ok, after some more digging around the comments around here (many thanks to Opal), I found out that launching the slave via JNLP instead works.

As many people mentioned, it is not currently possible to run the unit test over SSH, so you might want to turn towards the JNLP agent for now until Apple fixes it.

If connecting with JNLP still does not solve it, try the solution mentioned in this comment.

i.e.: Run these on command line:

DevToolsSecurity -enable

sudo dscl . -append /Groups/_developer GroupMembership "user-that-runs-the-sim"

security authorizationdb write system.privilege.taskport is-developer

See References here and here.

I've recently found out that if you install a new version of Xcode and do not launch it. The simulator might start timing out again. To solve this, I've had to manually launch Xcode, and install the additional tools it requested.

I ended up solving this on Xcode 5 by doing the steps here, essentially running:

sudo security authorizationdb write system.privilege.taskport allow

This will eliminate one class of these authentication popups. You’ll also need to run:

sudo DevToolsSecurity -enable

However, once I upgraded to Xcode 6, I now get an infinite hang when trying to run xcodebuild tests over SSH. They continue to run just fine as long as I'm logged into the console, and running them from the keyboard.

I ran into the same issue. My working theory is that SSH on OSX is started as a LaunchDaemon, and LaunchDaemons are not allowed to present a UI; Reference.

I was able to work around the issue by using Java Web Start to launch the Jenkins slave. I then installed the Jenkins slave as a launchd service.

Unfortunately the Jenkins slave then installs itself as a -you've guessed it- LaunchDaemon, leading to the exact same problem of not being able to launch the tests; Reference.

I worked around that issue by moving the Jenkins Slave LaunchDaemon plist and jar files in /System/Library/LaunchDaemons into ~/Library/LaunchAgents, and updated the paths inside the plist file.

That finally allowed me to run XCode6 (Beta6) tests on an OSX jenkins slave.