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 need
xcrun instruments -s
# Then launch it
open -a "iOS Simulator" --args -CurrentDeviceUDID <sim device UDID>
# and wait some time....
sleep 5
# Then launch your unit tests
xcodebuild [...] -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 GUI
applications. The SSH service, and the default setup for Jenkins, are
both implemented as LaunchDaemons. In earlier versions of Xcode 5
xcodebuild could run tests on the iOS simulator in this context, but
that was never a supported configuration, and as you have noted that
is no longer working as of Xcode 6.
Unlike LaunchDaemons, LaunchAgents provide a context where you can run
GUI applications - if the user is logged in at the time, with a window
server / Aqua session. Converting your Jenkins configuration from
being a LaunchDaemon to being a LaunchAgent would avoid the reported
issue. You can also use launchd for running tests on the iOS simulator
from a SSH session, either by crafting a LaunchAgent and manually
loading / 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.