How To Create A Certificate Signing Request Mac

iOS App Certificates and Distribution 👈

Edit (5/3/2018): I see people are following this article, couldn't be more happy than helping people, so added expressions to the article 😄 😉 😜 😅 😺

Well, it is not a rocket science to create certificates and distribute th e app to testers/users, but if you are doing it for the first time you may have to google about the process. Often developers get frustrated 😠 with Apple's security scheme to distribute the app, but trust me that's the reason why 🍎's App Store has many trusted apps over Android's Play Store (I love android too 😬). Although there are many Stack Overflow links out there which are handy to help you finish this setup but I want to summarize and give a brief idea of everything related to the process of creating certificates, generating builds and uploading it to the App Store. It is always better to know why it is done than how it is done. I will divide this article into three sections, One, Development/Distribution Certificates, Two, Sharing builds through TestFlight, Three, Uploading it to App Store 👍

1. Creating Development/Distribution Certificates

First of all, we have to understand Apple's terminology to identify its users, apps and devices. There are three things that Apple attributes an iOS app, identifier of the app, cryptographically signed entity (certificates) and its devices (provisioning profiles).

Identifier:

Identifier is a unique identifier of your app, known as bundle identifier. Which is also referred as Application Identifier because it is used to identify your application in App Store. Imagine there are 100s of ToDo apps but app store has to identify each and every app so it uses this identifier. Typically it has a reverse domain nomenclature e.g: com.companyname.appname. Let's create this identifier in our developer account. Under the section App IDs we can create the application identifiers and explicitly mention all the services it offers.

Under App IDs, we can also see previously created identifiers or we can create a new App ID. Let's go ahead and create a new App ID by clicking the plus button on the top-right corner and it shows a new window to create the app id. Here we have bunch of mandatory fields to fill, App Id Description (e.g: AppName), App Id Prefix (Apple generated developer team identifier) and App Id Suffix (unique identifier of our application). App Id suffix can be a unique identifier or a wildcard app id (eg: com.companyname.*) if we plan to use same services for different apps, it depends on the organization and the app and give the identifier. As I mentioned before it is suggested to use reverse domain pattern.

Now, we have to select the services that we are offering in our app. Most common service is Apple's Push Notifications.

Based on our choice of services we may need to do few more steps to configure them, such as for eg: Push Notifications service we need to do additional certificate configuration, I will explain how to setup the configurations towards the end.

Certificates:

Apple provides the best security in terms of deploying the app through its security scheme. It is very flexible, there are many scenarios where it allows us to deploy the app.

1Securely apps can be distributed through App Store as they are cryptographically signed by Apple Inc

2Enterprise or Organizations can distribute their apps securely without publishing it to App Store.

3Developers can deploy development binaries to up to 100 their own devices for testing.

4App developers can run a beta program by directly deploying signed apps to customers.

Certificates: Apple is stringent when it comes to security. Any build that we generate, if it has to go to any Apple device it has to be signed properly to ensure the security. Which is why we need cryptographic certificates issued by Apple. There are two different worlds that Apple looks at when it comes to deployment of apps, they are Development and Distribution. We need to create certificates for these two cases. When we create a certificate we first have to create the certificate signing request from Mac, to define you, as the entity/organisation who is requesting Apple to issue a certificate for either development/distribution. For this you have to create the request file through keyChain Access.

Give the organization's email id and name to create the request file.

Once we are done with creating the file, save it on your disk, and open developer account to create the certificate. Navigate to the certificate section, we can see a list of certificates which are already issued by Apple, and by clicking the plus button on top-right corner we can create new certificate.

We have to select the type of certificate we want to issue, there are two types Development and Production. Development is often used to issue the certificate to deploy the app on developer's device (to limited devices) for testing, but now apple automated this process in latest xcode. On the other hand, Production is used to issue the certificate to deploy the app on many devices either through App Store/ Ad-Hoc (to distribute internally in enterprises). Based on the services and environment, we have to choose appropriate option. After the selection continue to upload the request file to get the signing certificate.

Upload the generated signing request file.

After creating the certificate, download it on your disk. We can export the Apple signed certificate to other developers in .p12 form in order to avoid the dependency or single point of failure of the private key issued to this entity on this machine.

Provisioning Profile:

Provisioning profile is the most confusing part of this process. It combines the identifier and certificate to the devices.

Provisioning profile simply says that applications with this Identifier signed with this Certificate's private key are allowed to run on these devices.

We can create provisioning profile again to two different worlds, Development and Distribution. Development profile has device limitations where as Distribution is often used to deploy it on App Store or to distribute the app internally in the organization.

Configuration of Push Notifications: While creating the app identifier, if we have selected the push notifications service then we have to configure it corresponding web servers. In order to setup this we have to create another certificate, as Apple wants to bring another level of security to bind the web server and app. Now that, we have already created the app id, click on edit, under the push notifications we can now see the additional configuration certificates.

Creating certificate to bind the APNS to push notification server.

2. Sharing builds through TestFlight

Developers often find it difficult to share the iOS binary file to users/testers. It is not as easy as Android developers share the build by attaching the `.apk` file in email. Apple gives a default way of exporting the app in `.ipa` format file through Ad-Hoc profiles, but that is a tiresome process and the users should connect their devices to iTunes to get the .ipa file. There are many third party apps which makes this process easy by providing an interface to upload the app and give a downloadable link e.g: Fabric/Crashlytics, DIWAI, installrapp etc.

Apple acquired TestFlight an app sharing platform to make this process simple, on after its acquisition Apple updated its iOS operating system and which made it difficult to other third party apps to provide the platform to share the builds. Now, it is easy to share the builds through Apple's platform and to collect the feedback from the testers and see the crash reports right in the xcode without any hassle.

Let's create a build and see the process of sharing the app through TestFlight.

Create a new app in iTunes connect, and fill necessary information regarding the app. Archive the code with appropriate code signing certificates and provisioning profiles for the identifier. Once we archive the build, xcode opens the organizer.

Click on Upload to App Store and it will upload the build to app store. Once it is done, we can see this activity under Activity pane. At first apple does a sanity check on the APIs, assets and other entitlements offered in the app, once it is validated, it can be used to send to either App Store/TestFlight for testing.

To share the beta build for testing we can upload this build in TestFlight pane, by filling necessary app information.

The best part of the TestFlight is, it records the sessions, installations and gives crash reports with lot of developer friendly details for debugging the app. We can see these crash reports directly in the xcode Organizer>Crashes.

TestFlight categories the testers into two types, internal testers and external testers. Internal testers are the one's who has developer accounts and wants to test the app, for them we can share the build directly. For external users we have to go for a Apple's beta testing to share the build through email id and then they will be able to install the app via TestFlight iOS app. We can add up to 2000 external users and 20 internal users for testing (as of 2016).

Each build that we share to external users expires in 60 days, and we can update the build by uploading the new builds and it automatically shows the update to the testers in TestFlight app like how it shows in AppStore.

Crash reports are beautifully shown in the xcode's organizer, helps the developer to fix them.

3. Uploading app to App Store

Uploading the app to app store is relatively the easiest task of all. Through out the process Apple does several sanity checks to the build and throws error if it doesn't comply the development guidelines. Most common errors are the assets alpha channel error, asset size mismatch and sometimes swift library errors. Once all the tests are passed we can submit the app for App Review, for formal approval of the app release, it will take around 7–10 working days depending on the complexity of the app/third party app interactions etc. If the app did not met the guidelines they will reject it by stating the errors, there are certain review guidelines that they follow to review the app, make sure you follow them or check before the submission.

We can also expedite the app review process by requesting the apple review team (by writing to them via contact us in iTunes Connect) with appropriate reason. Most of the times they accept the expedite request if the app release is associated with any real-time events like PR event etc.

Apple team is pretty cooperative with the app release process, if you fail to upload the build or if the app gets rejected in the review process. You can contact them for assistance and explain the behavior of the app. If they consider the reasons are valid they will pass the build. But releasing an iOS app is one heck of a task. Developers have to struggle till the app gets approved by the Apple Review team. Thanks for reading till the end. Feel free to share your comments below. Keep reading 🤘