Certificates / App Ids / Profiles
Terms | Description | e.g. |
---|---|---|
Profiles / code signing identities | are files generated by the Developer Center that allow Xcode to sign your apps in a way that allows iOS on your devices to identify as valid. | |
Development profiles | These are tied to specific devices, so the app can only run on those. | |
Distribution profiles | These are used to sign your app before you submit it to Apple for approval. They contain no device-specific information, but you can’t use them to install apps on any device yourself, because Apple still has to sign the app after the approval process. | |
CSR | Certificate Signing Request | Keychain Access\Certificate Assistant\Request a Certificate From a Certificate Authority |
iOS App DevelopmentCertificate | ios_distribution.cer | "e.g. Name: iOS Development: Wayne Hsiao Type: iOS Development Expires: Mar 26, 2017" |
App Store and Ad Hoc Certificate | ios_development.cer | |
Provisioning Profile | A provisioning profile joins together all the pieces you have done so far, including certificates, device identifiers, and the App ID. | |
Development provisioning profiles | Are used to build and install versions of your app during your development process | |
Distribution provisioning profiles | Are used for submitting your apps to the App Store and beta testers | App Store, Ad Hoc, Enterprise |
Setup Flow |
---|
1. Generate CSR |
1.1 Keychain Access\Certificate Assistant\Request a Certificate From a Certificate Authority |
1.2 Fill profiles (email, common name / developer's name) |
2. Request Certificate (Dev / Prod) |
3. Registe Device |
4. Create App IDs |
5. Generate Provisioning Profile (Development / Distribution) |
5.1 Select App ID for new profile |
5.2 Select Certificate |
5.3 Select Devices |
APP ID |
---|
1. You can elect to have all of your apps share the same seed prefix, if you want to share keychain information between them. Say you have a suite of apps that all make use of the same website via a login. If the apps share the same seed prefix, and one app saves the user’s login information to the iOS keychain, any other app in the suite can get this login information from the keychain. |
2. You can create two different types of App ID: an Explicit App ID, or a Wildcard App ID. Explicit App IDs must be used when you wish to incorporate services such as in-app purchases or iCloud. Wildcard App IDs should be used when you want to use the same App ID for multiple apps. |
3. In an Explicit App ID, the Bundle ID search string has to be unique for each of your apps. It will be used by Apple’s push notifications service, for in-app purchases and for other services such as iCloud storage. |
4. Apple recommends that you use “a reverse-domain name style string” for the Bundle ID. For an Explicit App ID, the suggested format is “com.domainname.appname”; for a Wildcard App ID, the suggested format is “com.domainname.*”. |
5. Remember, if you use a Wildcard App ID, you won’t be able to use any of the neat services normally available, such as push notifications or in-app purchases. You might not plan to use these services now, but if you change your mind, you won’t be able to change your App ID without creating a new app. |
Reference: https://www.raywenderlich.com/127936/submit-an-app-part-1