iOS code signing explained (2026)
What code signing actually is
Every app that runs on a real iPhone or goes to the App Store has to be signed. The signature does two jobs: it identifies you as the developer through a certificate issued by Apple, and it guarantees integrity, so iOS can detect if the app binary was altered after signing. If the signature is missing or invalid, iOS refuses to install the app, and App Store Connect refuses the upload.
This is a security model, not red tape. It is what stops a random binary from impersonating your app or running unverified code on a user's device.
Certificates, profiles, and how they fit together
Four pieces have to line up for a valid signature:
- A signing certificate. Issued by Apple and tied to a private key on your machine, it represents your identity as the signer. There are development certificates and distribution certificates.
- An App ID. A unique identifier for the app, matching the app's Bundle ID, for example com.yourcompany.yourapp.
- A provisioning profile. A file that ties together your certificate, the App ID, the entitlements, and, for development, the specific devices allowed to run the build. It is the document iOS checks at install time.
- Entitlements. The capabilities the app declares, such as push notifications or iCloud. These must be enabled for the App ID and reflected in the profile, or signing and review will fail.
When people say signing is "broken," it is almost always a mismatch among these four, for example a profile that does not include the certificate you signed with, or an entitlement the App ID does not have.
Development vs distribution signing
The same app is signed differently depending on where it is going:
- Development signing uses a development certificate and a development provisioning profile, which lists the registered test devices. It lets you install and debug on your own hardware.
- Distribution signing uses a distribution certificate and a distribution provisioning profile. This is what App Store Connect requires to accept a build for TestFlight or the App Store. There are no per-device lists for App Store distribution, since Apple delivers the app to users.
Uploading to TestFlight or submitting for review always requires the distribution path. A build signed only for development cannot be submitted.
How AppFlight handles signing for you
AppFlight builds your app as a native Swift binary and signs it for distribution as part of its pipeline, then uploads to TestFlight and App Store Connect. You do not have to create certificates, register an App ID, or assemble provisioning profiles in Xcode by hand. You still need a paid Apple Developer account, since signing identities are issued under it. If a signing-related issue blocks a build, AppFlight surfaces it and works on the fix as part of the build and submission flow. Understanding the pieces above helps you read what is happening, but you do not configure them manually.
FAQ
What is iOS code signing?
It is the process of cryptographically signing your app so iOS can verify who built it and confirm it has not been tampered with. Without a valid signature, iOS will not install or run the app on a device or accept it for the App Store.
What is the difference between a development and a distribution signature?
Development signing lets you run the app on your own registered test devices. Distribution signing is what you use to upload to TestFlight and the App Store. They use different certificates and provisioning profiles, even though the app is the same.
Do I need to understand certificates and profiles to ship an app?
Not with AppFlight. The concepts help when debugging, but AppFlight handles distribution signing as part of its build and submission flow, so you do not assemble certificates and profiles manually in Xcode.