Code signing and managing provisioning profiles has been an ongoing annoyance for many developers over the years. I have written and spoken extensively to help people understand what code signing and provisioning profiles are and how they can be better managed. So, you can imagine my surprise and excitement when Matthew Firlik mentioned code signing and provisioning during the Platforms State of the Union (53:30) at this year’s WWDC. It was also revealed that the schedule contained an entire session, What’s New in Xcode App Signing, and two Labs dedicated to the topic. So, does Xcode 8 solve all of my code signing and provisioning profile grievances? Pretty much.
In the past, code signing has been hidden away in the Xcode’s “Build Settings” tab. The CODE_SIGN_IDENTITY and PROVISIONING_PROFILE setting were hard to get to and not directly linked to each other. A developer was often left looking at “No Matching Provisioning Profiles Found” error or an “The entitlements specified in your application’s Code Signing Entitlements file do not match those specified in your provisioning profile.” error, if they were lucky. If they were unlucky, the build would succeed but the app would fail to run on a device or the app would crash because of a missing App Group entitlement. The changes in Xcode 8’s completely rebuilt provisioning system should address all of this.
You now have a choice in how you code sign and provision your apps1. Automatic Code Signing is what many people are excited about. Automatic Code Signing uses a new Xcode managed, dedicated profile that is separate from any that you have created. This is really an extension of the dreaded “Fix Issue” button but is segregated so as not to stomp on any of your existing managed profiles. Automatic Code Signing looks great and it will probable be used by a ton of developers.
However, it is not what excites me most about the new Xcode 8 code signing improvements. People that work on large teams or developers that do not have access to the team and developer portal for the app they are working on require more fine-grained control over the code signing in their apps. Customized Code Signing delivers just that. Customized Code Signing is how we have been managing our profiles and apps for years and it allows us the most control over how our apps are code signed. Xcode 8 brings the dark art of customized code signing and provisioning profiles into the light for all to see. Instead of being buried in the Build Settings, Code Signing is now displayed front and center in the General tab. When “Automatically manage signing” is unchecked we can specifically select the provisioning profile we wish to use for each Configuration. Now this in itself is nothing new, we have always been able to do this in the Build Settings tab. The awesome sauce comes in with the smarts that Xcode 8 displays here. The drop down list of profiles now groups the Eligible profiles above the Ineligible profiles. Meaning that profiles that match the bundle identifier absolutely or with a wild card will be displayed above any profiles that don’t match at all.
Not only that, if you select a profile that doesn’t match the bundle identifier you now get error messages that will tell you exactly what the problem is.
This is a massive improvement over what we had in the past. No longer is Xcode hiding the details from us. No longer should we have to hunt and peck to find out what might be wrong. Xcode 8 will tell you exactly what is wrong, misaligned, expired, or missing. If we stopped right there I would be completely satisfied with the code signing changes. I know I sound like an infomercial but, it get’s better!
The Xcode team has included a new report in the Report Navigator that outlines everything Xcode does on your behalf related to code signing.
This report completely lifts the covers off of the “API” that Xcode uses to talk to the developer portal. Older versions of Xcode would communicate with the Apple Developer Portal under the covers. Now when Xcode 8 handles code signing on your behalf, you can see exactly what checks are being performed, and what Xcode 8 is doing in order to fix the problems it identifies.
One more thing that really surprised me was the existence of a new Build Configuration setting, PROVISIONING_PROFILE_SPECIFIER. In the past you could specify the PROVISIONING_PROFILE by name and Xcode would instead reference the UUID of the profile in the project file like so: PROVISIONING_PROFILE = “9b7bca71-29ac-44de-a96d-131d06b46501”. If the profile with that exact UUID ever went missing, Xcode had no way to reconcile this on its own. You would have to go into Build Settings and find the profile name in your list again in order for Xcode to get the new UUID. PROVISIONING_PROFILE_SPECIFIER allows you to specify the provisioning profile name, but now Xcode 8 will save the following in your project file: PROVISIONING_PROFILE_SPECIFIER = “9K9F9LCV74/KeyGrinder Dev”.—a combination of the Team ID and profile name (as it is named in the Developer Portal, not necessarily the actual filename). This way Xcode will always use the latest profile of that name regardless of UUID. Xcode will no longer use an old, out-of-date profile after you have updated it. With this addition, Apple has sherlocked our very own set_project_profiles script. And we couldn’t be happier.
The last thing I want to highlight is a best practice that Apple mentioned both in the session and during the Labs. Application distribution is a two-step process: compilation and code signing. Your app should first be compiled into an XCArchive and then exported to an IPA for distribution. Because of this, you do not need to have the exact release certificates and profiles set in your Release configuration. As long as the app compiles with the correct release flags, optimizations, etc., it can be signed with an AdHoc or even a Development profile. You just need to use the correct App Store or Enterprise profile when you export the IPA or submit to the App Store. This can help developers who don’t have access to the release credentials and certificates from seeing unnecessary errors that they cannot do anything about.
With this release of Xcode 8, I feel like Apple has listened and given us everything we have asked for.
TLDR: Dear Apple Xcode Team, Thank you.