If you are or want to be an iOS app developer, you know words like Certificates, Identifiers, Devices, and Profiles. We go through those terms once we publish our apps to the world or an external group. They are not rocket science, but sometimes they become very daunting. Nowadays, Certificates, Identifiers, Devices, and Profiles are automatically handled by Xcode. But knowing them upfront gives us an understanding of how things are happening behind the scenes. Moreover, if we are distributing the iOS app other than the Apple platform(like the TestFlight), then it is always the manual way. In this blog post, we will address those terms(Certificates, Identifiers, Devices, and Profiles) to draw a relationship among them.
To move further, we also need to go through the different types of Distribution schemas like Development distribution, App Store distribution, and Ad Hoc distribution. After that, we will map those distributions with the regular distribution concepts like Alpha and Beta distribution.
Purchase of the subscription
This is the phase when we want to distribute our developed app to the customer. The iOS app distribution is not free. To distribute an iOS app, it is necessary to purchase an Apple developer program subscription, which costs $99 yearly. On the Apple developer program, we can find more details. There will be some email confirmation after the subscription purchase.
Mapping App Store, App Store Connect, and Developer portal
Usually, we distribute our app through the App Store. But to get that app to the App Store, we need to have an entry of that app on the App Store Connect. And to get to the App Store Connect, we need to create some entitlement on the Apple developer portal. That means we will create app identifiers, certificates, device lists, and provisioning profiles on the Apple developer portal. Once we have the provisioning profile, we can upload the app binary to the App Store Connect. After that, we need to submit our app for review. And once it gets reviewed, we can distribute the app to the users.
Let us now move to a more granular level.
How Alpha and Beta distribution are mapped in iOS app distribution
First, let us talk a bit more about different types of iOS app distribution. We can say there are mainly two types of distribution based on build variance. One is Development distribution, and the other is Production distribution.
In the case of Development distribution, we need to run our undergoing development app on some devices that we can/will not plug into our Mac. An example can be the verification of a hotfix. The hotfix can not be merged into the production code without the tester’s approval. In this situation, Development distribution helps a lot.
Another one is Production distribution. Production distribution can be of three types. They are App Store Distribution, Ad Hoc Distribution, and Enterprise Distribution. App Store Distribution is the standard distribution of our iOS app to the general people through the App Store. We distribute the iOS app to a limited number of customers on Ad Hoc distribution. Finally, on the Enterprise Distribution, we distribute the iOS app to the employees of an organization.
We often use the terms Alpha and Beta versions of an iOS app. Let us see how they map with the above distribution types.
In general, Alpha testing is done by the development team. It is very common to ad testers or QA guys in the Alpha testing. Alpha testing is regarded as the very first level of testing of an iOS app. As a result, the Development distribution of an iOS app is the Alpha distribution for that iOS app. We might use the dev environment APIs here on the Alpha/Development distribution.
On the other hand, Beta testing is done by some specific groups, not conducted by the Development team. Multiple small groups are invited to the Beta iOS app testing. The diverse groups give the development team a wide range of perspectives. One important thing is that the Beta iOS app is very close to the actual release. As a result, production APIs are used here. Thus, the Beta distribution is the Ad Hoc distribution of an iOS app.
Let us have an overview of different types of distribution in a single image.
Code to Apple developer portal
In this flow, most of our app distribution process will be addressed. Here are the concepts for this flow.
- Identifiers
- Devices
- Certificates
- Profiles
Identifiers, App ID
There are various types of IDs available on the Apple dev portal. But we will only concentrate on App IDs. This App ID will uniquely identify the app. App ID is required to avail of different Apple services. Another important thing is that the Provisioning Profile, which we will discuss shortly, will use this App ID to identify the app.
The standard format of App ID uses a reverse domain name notion. An example can be com.mobidevtalk.blog where blog the app name mobidevtalk is the company/organization name com is the domain type of that organization.
The certificates, provisioning profiles, and the app’s bundle identifier all use App ID. So please think before picking a name for our app. 🤔
There is sometimes a tendency to use a wildcard app ID. This has a name format like com.mobidevtalk.*. The only use case of this wildcard app ID is to support multiple apps sharing the same bundle seed ID. However, using the wildcard app ID has huge limitations. Wildcard ID can not used in the Apple Push Notification, Purchase, etc. We can use the wildcard for temporal cases. But for permanent cases, we need to use the proper app ID.
Device(s)
Apple only allows registered devices to run the beta version of an app. If we want to run our debug app, directly build and run the app from our Mac, we need to register the device. For ad hoc distribution, registration is also required. We can not run our app on devices without registering them in the Apple dev portal. Thats it!
The Xcode will automatically register the device for development if we allow the automatic signing of our app in the Xcode and then connect a device with our Mac. But we will need to register devices over the air. Moreover, we will not always use automatic signing.
How can we register devices, iPhones, iPads, Macs, etc.? There are three ways such as automatic, half-manual, and full-manual.
The automatic way works only on the Apple platform. That means using TestFlight from Apple for the OTA(Over-the-air) distribution. Here is the workflow.
- Push the app builds to the App Store Connect
- Invite the people, either adding them as internal or external tester on the App Store Connect
- The invitee needs to open the invitation link, sent to his email, on the iPhone/iPad/Mac
- A new App will be downloaded called TestFlight from the App Store
- From Now on the invitee can download the app directly through TestFlight, even the old versions
Interestingly, TestFlight way to the distribution does not decrease the total number of devices in the Apple Dev Portal. We will continue this talk in future talks regarding the Xcode Cloud part of our CI/CD blog post.
Now, let us talk about the half-manual way of adding the devices. This is true for most Beta App Testing Platforms like Firebase, TestFairy, HockeyApp, and App Center. All of them except Firebase will provide a Device Management feature to collect the UUIDs of the testers. On the other hand, Firebase will provide a dynamic link to the tester. All of those platforms ultimately let the tester download their app from where the UUID of the tester’s device will be collected and sent to the corresponding Beta App Testing platform. After that, the developer will collect those UUIDs from there. Then, the developer will add those UUIDs to the Apple Developer portal.
On Manual device registration, we need to ask the tester to send the UUID of his iPhone/iPad. And then add it to the Device section of the Apple developer portal by the developer.
Remember, you can add a limited number of devices.
Keep in mind that people in your organization will come and leave. If you are registering an organization-owned device, please ensure the appropriate name for it. Perhaps add a suffix before the device name. So, anyone can understand those names and remove that device entry if required. Once an employee leaves the organization, you must remove his iDevice entry from the Device and Profile section of the Apple developer portal. Thus, he will lose access to the builds using the latest provisioning profile.
Certificates
Certificates are the most important and most confusing part of iOS app distribution. These Certificates digitally sign the iOS apps.
Now, why digitally sign our iOS app? Because Apple wants to make sure every time an app is run on an iPhone/iPad/Mac, that app is digitally signed by a known authority. So, how does Apple know that authority? The developer creates a CSR(Certificate Signing Request) file on his Mac. He uses his keychain. He will provide the email with other information. Then, the developer uploads the CSR file to the Apple Developer. He has to have access to the Apple Developer portal. That’s how Apple knows the authority.
The following diagram shows the general process of Certificate creation.
Types of Certificates
Based on the distribution type we will have two different types of certificates. One is a Development Certificates, and another is a Distribution Certificates. Development certificates are used to run the iOS app on the developer’s iPhone/iPad/Mac. On the other hand, Distribution certificates are used to run the app on the customer’s iPhone/iPad/Mac. The customer can be internal or external.
Both types of certificates are created the same way.
Development Certificates
Ideally, one developer should create his Development certificate. How can he share his Development certificate on his other Mac? He needs to export that Development certificate from the existing Mac and then import it into the other Mac. What if we use this process to share a Development certificate among teammates? Then, this is a very wrong process. Again, ideally, each developer should create his development certificate. On a team, they should have access to the Company/Organization’s Apple Developer Program as individual developers.
Distribution Certificates
Distribution certificates are used to distribute the iOS app to the customers. Ideally, all the production-type distributions, such as Ad Hoc and App Store distributions, use identical distribution certificates. Unlike the Development Certificate, one team member manages the Distribution Certificate. Yes, he is a bottleneck. But that’s how Apple designs the Distribution Certificates. Fastlane, an automation tool, has an elegant way of resolving this issue. We will see this in detail in some future blog posts.
Here is an insight into different types of certificates.
Provisioning Profile
The Provisioning Profile is a container. I like to think of the Provisioning Profile as a container or a bag. So in this bag, Provisioning Profile, two things/concepts are at least kept. What are those two things? Well, Certificates, list of authorized devices (iPhone/iPad) list. Both the Development and Ad Hoc Provisioning Profiles contain these two. But on an App Store provisioning profile, there is no device list. Most of the time, the Provisioning Profile also carries an app identifier.
Combining all together
Let us combine all the basic concepts(Certificates, Identifiers, Devices, and Profiles) in a single place. The takeaway here is the Developer provisioning profile will contain a Developer Certificate. Similarly, an Ad Hoc provisioning profile will hold its Ad Hoc certificate. Finally, the App Store profile will carry its App Store certificate. Only the App Store provisioning profile will not contain any device list, as this one is used to upload the build for the App Store.
Conclusion
Knowing the basic concepts like Certificates, Identifiers, Devices, and Profiles will give us the confidence to use those properly. Not understanding how these concepts are glued together creates confusion and frustration. A simple go-through will reduce the frustration always. So please revisit this blog before these basic concepts get dusted. See you in the next blog. ✌️ ✋