Code Signing 101
If you do not setup code signing, buddybuild can only perform simulator builds of your app; that’s a build that can only run in an Xcode’s device simulator. For simulator builds, your unit and UI tests can be run to verify the functionality of your app, however a simulator build cannot be deployed to testers or published to the App Store.
If you’d like to learn more about code signing, read on.
Certificates and Private Keys
Device builds on iOS are required to be signed with a developer’s certificate. Code signing allows iOS devices to verify the app developer’s identity, and that the app has not been tampered with.
Developer identities are tied to two artifacts — a certificate and a private key that unlocks the certificate. Both these artifacts are probably already present if you’ve ever deployed builds to a device.
Typically, there are two types of certificates available to iOS developers — one is a development certificate used for local development and testing — the other is a distribution certificate meant for builds destined for the App Store.
If you’re part of the Apple Enterprise program, you also have an Enterprise Distribution certificate that allows you to deploy apps within your enterprise.
You must code sign iOS applications before any iOS devices will accept them for installation.
Buddybuild creates builds on your behalf, so we need access to your developer identities in order to sign builds. Managing these can be a pain. Use the Automatic Cert-Uploader to quickly and easily upload the relevant certificates to buddybuild.
When you upload your certificates to buddybuild, your app transitions from using simulator builds to using device builds (a required step before publishing to the App Store). Device builds typically take longer than simulator builds, for several reasons:
If you need faster builds while working on new features or bug fixes, you can disable Build for archive in your app’s build settings. You need to re-enable this setting when you are preparing to deploy to iTunes Connect.
You could also use a branch override setting, so that Build for
archive is only enabled for your
Development devices also need to be included in the Provisioning Profile of the development-signed app bundle before they can accept them for installation.
Provisioning profiles are generated and signed by Apple. Any modifications — like adding a new device UDID — requires the following:
A request to Apple to regenerate the profile,
Download and installation of the generated profile on to your development machine,
Rebuilding your app with the updated profile.
Buddybuild can also transparently manage these for you. Simply enable the Auto-Syncing Provisioning Profiles feature to take advantage of this functionality!
After an app has been built, it is not possible to alter, remove, or replace the provisioning profile used during the build. Whenever provisioning profile changes are required, your app needs to be rebuilt.
Xcode lets you create development provisioning profiles on your local computer, for deploying apps to connected devices. However, you cannot use a development provisioning profile to deploy your app to the App Store or to other devices.
To upload your app to the App Store, the app must be signed with an App Store provisioning profile. If you have your code signing type set to iOS Distribution and you have an Apple Developer Portal Connection, buddybuild automatically generates App Store provisioning profiles for you, and uses those to build a version of your app compatible with the App Store.
Getting App Store signed builds requires:
If, for any reason, you are not able to add an Apple Developer Portal Connection, please contact us.