Determining the Cause of Xcode/iOS Failures in CircleCI

Environment

The CircleCI macOS executor provides a clean, freshly installed, environment for each job. The software available in the VM depends on the image selected. In most cases, the environment will be very different to your local environment where you may already have certificates / profiles and specific dependency versions installed, along with build caches.

Hardware

It is also important to note that local machines will, on the most part, be a lot newer and faster than the machines used in a CI environment. With an extensive fleet of macOS hosts, we cannot update the hardware as often as a developer may replace their own Mac. In some instances this means apps may take a little longer to build and apps may launch / execute slower in the simulator.

Debugging

The best debugging step to start with is to collect the simulator crash reports. If you see the termination reason in the crash report as "SPRINGBOARD", then this means you app was too slow to start up and has been killed by the iOS subsystem (this can be anywhere from 5-8 seconds maximum launch time). This is one of the most common causes of a test failure. As explained above, due to different environments, and hardware, if your app is on the borderline of being too slow to launch normally, running in a CI environment may cause it tip over the limit. To resolve this, consider following best practises for speeding up your app launch.

If the issue I related to code signing, which works locally on your machine but not in CircleCI, the best method to resolve this is to redo your code-signing setup and start from fresh. As there are many moving parts to code signing, in most cases it is much faster to do this than try to debug a bad setup. We recommend reading our iOS code signing documentation for further information.