DevOps Log

Several projects were being baffled by the fact that their iOS builds were failing to launch tests. The only error that developers’ saw in the build log was :

xcodebuild[60283:14778851] iPhoneSimulator: Timed out waiting 120 seconds for simulator to boot, current state is 1.

The Xcode builds were running on the Jenkins slaves and we had applied all the rules in the book for running tests without an active GUI session i.e running the simulator in headless mode.

Remote logging into the slaves did show us that the simulator was booted up. But the tests just didn’t want to run for those projects. The confusion and frustration were compounded by the facts that we had other projects that were running tests just fine on the same/similar infrastructure.

Now while trying to debug the issue we noticed that the simulator was indeed booted but the device that it was running was not compatible with the tests that we were trying to run on it.

We were resetting our simulator i.e killing all the running instances and bringing up one just before the build starts. This was starting the simulator but with the same device that the last simulator instance used. It did not change the device based on what was being called out by the xcodebuild.

This is different to how simulator behaves when you do have an active UI session for e.g. running it on the dev machine. This basically suggested that the simulator behaviour is different when doing a build on the slaves (we are connecting to the slaves via JNLP) and that our script needs to be more intuitive when it starts the simulator.

Based on what device the build needs, we grabbed the device ID using the following command :

xcrun instruments -s | grep <required_device>

Please be aware that there might be multiple versions of the same device based on the
different SDKs that you may have installed on your OS.

The last step is to launch the simulator with the correct device ID using the following command;

open -a "iOS Simulator" --args -CurrentDeviceUDID <ID_FROM_LAST_COMMAND>

And Voila ….. All the build lights suddenly turned green..

Last week, while creating new Jenkins slaves running Yosemite and Xcode 6.3.2,  we encountered the following error when trying to build and package our existing iOS application (with Watch Kit app extension):

"Embedded binary validation utility error: Error Domain=XCEmbeddedBinaryValidationUtilityErrorDomain Code=0 "error: Embedded binary is not signed with the same certificate as the parent app. Verify the embedded binary target's code sign settings match the parent app's."

The build was running successfully on the old slaves without any issues. As the error message suggested, we started our debugging process with checking the certificate that was being used by the code signing process. But no matter what certificate we used it would spit out the same error. We tried out all possible provisions profiles and certificates combinations but to no avail.

After much digging around, we found out that it was the trust setting of the enterprise certificate that was causing the issue.

The trust setting was set to “Always Trust” . Changed it to “System Defaults” and BOOM..... the error vanished. 

Apple requires that all the certificates that are being used for code singing should have the trust setting set to “System Defaults”. A proper error message would however would have saved me a lot of time and effort 🙂