Xcode 8 introduces a new default way to manage provisioning profiles and signing certificates called Automatic Signing. Automatic Signing can make managing provisioning profiles much easier, but for some developers it can be a frustrating experience at first.
“I suppose I could try and go back to the manual signing, but I thought the whole point of this Automatic signing would be that it would make my life easier.”
Especially for developers who have been using Xcode before automatic signing, it can be confusing to get the Xcode project configured correctly, and to understand what Xcode is now doing at each step in the new workflow.
The most fundamental change that happened alongside Automatic Signing is that archived builds should now be code signed with the Development Signing Identity, instead of the Distribution Signing Identity. So to take advantage of Automatic Signing, you must use your Developer signing identity for both Debug and Release configurations. (This is where some developers get confused, because previously this was not the case. In the past the Debug configuration would be code signed with the Developer Identity, but the Release configuration would be the Distribution Identity. Now both Debug and Release should use the Developer Identity for code signing.)
If the release build configuration incorrectly specifies a Distribution Signing Identity, Automatic Signing will no longer be able to operate, and Xcode will produce a build error informing you to fix the configuration. Just update the top-level “Code Signing Identity” to “iOS Developer” to correctly configure the project.
When archiving the app, it will be signed with the Developer Identity. The Xcode Organizer now has the ability to re-sign the archive with the Distribution Identity when needed. For example, when you use the Xcode Organizer to upload an archive to iTunes Connect, Xcode will include the Production provisioning profile and re-sign the build with the Distribution Identity. In this way, iTunes Connect will receive your app build with the correct provisioning profile and code signing.
However, this new workflow presents a problem for certain testing scenarios. Specifically, if you need to test a feature such as Push Notifications in the fully production environment, the build you test must be provisioned for distribution, unlike what happens during a normal “build-and-run” development cycle.
“I sometimes would switch to the Release config in the ‘run’ part of the scheme to test parts of the app that needed to be signed with a Distribution profile (in our case, testing push notifications or IAP). But having trouble with Xcode 8.”
This is still possible with Automatic Signing, but there is a new workflow for testing release builds. Use the export archive feature of the Xcode Organizer window to create an app that can be tested on device. Here’s the new workflow to test a production build while using Xcode 8’s Automatic Signing:
- First create the archive. Xcode will create a release version of the build and code sign it with the Development Signing Identity. The archive will appear in the Xcode Organizer window.
- Click the “Export…” button to allow this archived release version of the app to be deployed on different devices for testing.
- Choose the Ad Hoc option. Xcode will re-sign the build with an Ad Hoc Distribution Provisioning Profile and Production Signing Identity.
Once the Ad Hoc export has been tested, you can then use the exact same archive to upload to iTunes Connect. This workflow has the benefit of ensuring that you are testing the same compiled code as what is submitted to iTunes Connect. That means the archived code is the same between testing and what is delivered to the App Store. Likewise, if you need to test a build that has previously been sold on the App Store, you can use the archive for that build to generate an app file you can install on your test device.
Subscribe to the newsletter to stay up to date with new articles.