Xcode Treasures: Security

The first update to the Xcode Treasures beta release went out yesterday, and it’s a doozy: Security. Actually, in my original proposal and outline for the book, this was called Code-Signing Hell. Obviously, I knew I had to cover it, but was not looking forward to the experience.

Xcode treasures security toc

As I dug into the material again — we did cover code-signing and App Store submission in iOS 10 SDK Development and its predecessors, after all — it turns out that the approach of this new book really helped out. After all, everything Xcode touches is fair game, so I could start with a simple Mac-only concept: sandboxing. That lets the chapter start of with a simple introduction to the current target’s capabilities tab, before getting into the whole kielbasa of iOS code-signing and App Store submission.

After a simple look at local-only sandbox concerns, things actually fell into place for a coherent narrative. Go beyond sandboxing and you find that there are capabilities like push notifications and iCloud that touch Apple’s backend or the user’s private data, and therefore require entitlements. And to deal with entitlements, you’ll need an AppID that specifies your entitlements, which you manage at

And when you find the AppID in the “Certificates, Identifiers, and Profiles” section, you’re already on top of the other two parts of the equation: the profile that will connect an AppID to a permitted action like installing on a development device or distributing via the App Store, and the certificate that you use to sign it, thereby proving your identity to Apple and ultimately your end-users.

Xcode’s automatic signing helps to teach this stuff, because you can let it generate all of these for you automatically. It makes it much easier to get to the final step, which covers manual signing. That’s a pain, but it feels like having made the journey there step-by-step, you can see how the pieces fit together, and take care of it yourself (if you must).

Xcode project editor general signing manual

It really helps that my editor, Tammy Coron, is also an Xcode user and has had to deal with app-signing struggles, so she was able to make sure the line through this material was clean (she had me rearrange some stuff where AppIDs get introduced), and pushed me to really justify manual signing in the era of automatic signing.

The other thing that helped this fall into place was re-titling the chapter “Security”, although at first that’s misleading. This isn’t entirely about Xcode keeping you secure. By and large, these systems exist to protect Apple and its users from you, or at least someone pretending to be you. It doesn’t feel great to have to jump through hoops and show your bona fides to get your app up on the store, but it’s not unjustified either.

And honestly, it’s a hell of a lot better than it used to be. For me, the biggest improvement has been that you can have one development certificate per machine, rather than per account. In the bad old days, you’d inevitably caught on your laptop with a bad configuration, have to manually revoke your old cert and create a new one, and then clean up everything when you get back to your desktop Mac. Multiple development certs, plus automatic signing, made this material a lot easier to write than it was five years ago.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.