App Signing, Provisioning Profiles & Certificates

iOS Development — Production & Publishing

Chapter 4 · App Signing, Provisioning Profiles & Certificates

Every chapter so far has run the app straight from Xcode with almost no thought given to why it was even allowed onto a real device in the first place. This chapter opens that up directly — the real machinery of certificates and provisioning profiles that has been working quietly in the background the entire course, and that becomes unavoidable the moment an app needs to leave a single development Mac.

Why Code Signing Exists at All

iOS refuses to run any binary that isn't signed by a real, trusted identity — this is the real, fundamental reason a random unsigned app can't simply be copied onto an iPhone and launched. Code signing exists to answer one specific question before the OS ever runs a line of code: who, exactly, is vouching for this binary?

Certificates: A Real Public/Private Key Pair

A signing certificate is built on a real public/private key pair. The private key stays on the Mac that created it, held securely in Keychain — it never leaves, and it's what actually signs the app binary. The public key is the half embedded in a provisioning profile, letting iOS verify that a signature genuinely came from the identity it claims to.

Apple's own current certificate types, verified directly against Apple's real certificates-overview documentation:

Certificate	Owned By	Real, Concrete Purpose
Apple Development	An individual (per-Mac)	Run and debug an app on real, registered devices during development
Apple Distribution	The team as a whole	Distribute the app for testing or submit it to App Store Connect

A Real, Verified Detail

An Apple Development certificate genuinely appends the Mac's own computer name to its identity — a real certificate might literally be named something like "Philip Osztromok (MacBook Pro)". An Apple Distribution certificate, by contrast, belongs to the whole team rather than one machine, and only an Account Holder or Admin can create one — a real, verified permission restriction, not an arbitrary convention.

What a Provisioning Profile Actually Binds Together

A provisioning profile is the real bridge connecting every other piece of code signing into one package. It contains:

App ID

The real, unique bundle identifier this profile is valid for — the same identifier Chapter 1's own app-icon/launch-screen setup already relied on

Certificate (public key)

Lets iOS verify the app's own signature was really produced by the matching private key

Entitlements

The real capabilities the app is permitted to use — directly tied to Architecture & Data Chapter 8's own camera/location/notification permissions

Devices

For development and ad hoc profiles: the real, specific device UDIDs the app is allowed to run on

The Four Real Provisioning Profile Types

Profile Type	Real Device Limit	Real Use Case
Development	Specific registered devices	Testing on the developer's own real devices
Ad Hoc	Specific registered devices (max 100)	Beta testing with a small, named group
App Store	No device limit	Public release via the App Store
Enterprise	No device limit	Large-scale internal distribution

A Real, Concrete Distinction Worth Remembering

Development and Ad Hoc profiles are genuinely limited to a specific, named list of real devices — App Store and Enterprise profiles carry no such limit at all. This is exactly why an Ad Hoc build sent to a beta tester's iPhone that was never actually registered will refuse to install, no matter how correctly everything else was signed.

Automatic vs. Manual Signing in Xcode

Xcode's own real "Automatic" signing mode creates and renews certificates and provisioning profiles on the developer's behalf whenever it detects they're missing or expired — the mode every earlier chapter in this course has quietly relied on. "Manual" signing instead requires selecting a specific, already-created certificate and profile directly, giving full control at the real cost of managing renewal by hand.

The Real Apple Developer Program Membership

None of this is possible without a real, paid Apple Developer Program membership — verified directly against Apple's own current program page at $99/year, which unlocks App Store distribution, TestFlight, and code-level support. A separate real Apple Developer Enterprise Program, for private internal distribution to a company's own employees, costs $299/year.

Hands-On Exercises

Exercise 1

Explain, in your own words, why a provisioning profile embeds only the certificate's own public key rather than the private key, and what would go wrong if the private key were included instead.

📄 View solution

Exercise 2

A beta tester reports the app refuses to install on their own real iPhone, even though the build was signed correctly. Using the chapter's own real device-limit distinction, explain the single most likely cause and how to fix it.

📄 View solution

Exercise 3

Explain, in your own words, why the Push Notification capability from Architecture & Data Chapter 8 requires an entitlement inside the app's own provisioning profile, connecting the two chapters directly.

📄 View solution

Chapter 4 Quick Reference

A certificate is a real public/private key pair — the private key stays on the Mac, the public key goes into the provisioning profile
Apple Development — individual, per-Mac; Apple Distribution — team-owned, one per team
A provisioning profile binds together the App ID, certificate, entitlements, and (for Development/Ad Hoc) a real list of registered devices
Development and Ad Hoc profiles are device-limited (Ad Hoc: max 100); App Store and Enterprise are not
Xcode's Automatic signing manages certificates and profiles for you; Manual signing requires choosing them directly
Apple Developer Program: real $99/year; Enterprise Program: real $299/year