Xcode exit code 65

Hello, I was also getting this Xcode exit code 65 issue. It was generated from UITests Scheme. For me UITests Scheme was not much important as I have only functional test coverage, so I deleted the UITests Scheme & able to run all test cases without any issue.
May this help for few people.

1 Like

isolated some really promising root causes and we’re testing

I assume this didn’t get anywhere?

Is this still present on Xcode 8 builds as well?

@anon47539524’s post covered what ended up being the majority of cases. If you’re still having issues, let us know! Exit Code 65 is a generic Apple error code so I fully expect that there are still many of them - just less now.

The issue reappeared in XCode 8 and the workaround is not working for us any longer:
When using the workaround as following:

    - xcrun instruments -w '2D96E690-BFB5-44D5-8B22-31D9C57EDADF' || true
    - sleep 15

I’m seeing the following error

Instruments Usage Error: No template (-t) specified
instruments, version 8.0 

Any ideas?

1 Like

Hey Ben,

Could you please open a support ticket and provide this link as a reference so that it’ll end up with me. Please also link to the failed builds.


I am having the same issue as Ben with Xcode 8. The fix no longer works. I would greatly appreciate if you could keep this thread up to date rather than having to communicate on an individual basis as I’m sure others are having the same issue.


For those wondering, here are the simulator UUIDs for iOS 10 that are available in the build container. I got these by SSH-ing into one of my builds and invoking xcrun simctl list with DEVELOPER_DIR set to the Xcode 8 directory. I’ve only tried the iPhone 6 one but it seems to be working correctly.

-- iOS 10.0 --
    iPhone 5 (85D8FE66-1208-4478-811C-7BD1AA3B33CA) (Shutdown)
    iPhone 5s (1FB033A8-440D-45F3-B95D-03E4E38B51DF) (Shutdown)
    iPhone 6 (33D34EBA-703E-4A82-8838-BE75171492E1) (Shutdown)
    iPhone 6 Plus (5525775C-A351-4986-9BF4-144A84E253AA) (Shutdown)
    iPhone 6s (F08BA729-6AD2-42DF-A210-34DC8D990011) (Shutdown)
    iPhone 6s Plus (A310FC97-435A-4026-AF85-F1216F856BA5) (Shutdown)
    iPhone 7 (2D96E690-BFB5-44D5-8B22-31D9C57EDADF) (Shutdown)
    iPhone 7 Plus (D4155E82-B930-450B-AFC7-F4800669EC65) (Shutdown)
    iPhone SE (84A11478-B7D4-4968-A626-E27CE7372148) (Shutdown)
    iPad Retina (D56EBD40-B853-4D56-B482-D4C40E69A3FC) (Shutdown)
    iPad Air (B9257F59-88B3-421D-B1F2-2BD92F0858D0) (Shutdown)
    iPad Air 2 (AC291080-8EFE-4095-8C55-B1E952EFFC36) (Shutdown)
    iPad Pro (9.7 inch) (F9C94E2A-F080-4AB0-93D6-A41135919D8E) (Shutdown)
    iPad Pro (12.9 inch) (BF8D8AD2-6A96-4A62-8059-A836738BB873) (Shutdown)


I’ve created a new thread in order to keep better track of this here: Xcode Exit Code 65 + UI Tests

I’m working on it nonstop but I haven’t yet found a solution.

ditto to this - i’m having UI tests consistantly fail when they pass locally. it seems that the simulator isn’t loading for a particular test suite

We no longer recommend using UUIDs to start simulators. The OS X image has been updated to resolve the underlying issue with multiple simulators available for the same device type and iOS version, and using UUIDs is no longer necessary. Please check out this post for examples of how to choose the simulators by name, both in xcodebuild commands and when pre-starting the simulator.

1 Like

If you’re running into the error code 65 here’s a command you can pipe on the end of your xcodebuild (assuming you’re running tests) command to get back more consistent results:

(XCODEBUILD_COMMAND_HERE) | awk 'BEGIN {success=0} $0 ~ /.* tests, with 0 failures \(.*/ {success=1} {print $0} END {if(success==0){exit 1}}

This looks for tests, with 0 failures ( in your output text, thus using the text output of xcodebuild instead of the status code of xcodebuild to determine success.

Note: Keep in mind, if you do something like NSLog(' tests, with 0 failures ('); in your code you make get a false positive, it’s very unlikely to happen by accident. You may have to update tests, with 0 failures ( in the awk script between updates of xcodebuild. But, having consistent results with xcodebuild is definitely worth that price.

After months of off and on issues, we have completely resolved our Error 65 issues and this solution has been in place over several hundred builds across the past 20 days.

The key has been separating the steps in our Makefile for performing a xcodebuild build, and xcodebuild test. This builds as expected in the first step, and then runs tests with derived data from the previous step.

Here’s a relevant portion of our Makefile if the above is not clear.

If I don’t respond here right away, feel free to reach out to me on Twitter. Hope this helps others!

Hey everyone,

Please checkout this post: I’m looking to gather as much information as I possibly can in order to help Apple improve xcodebuild and the underlying toolchain for all of us.

If you’re interested please E-Mail me. All the data will be anonymized!


We managed to fix this issue by running:
xcodebuild build-for-testing
xcodebuild test-without-building

instead of build and test. You can read about this in details here.

I hope this will help some of you, cheers!

1 Like