Briefly about the main thing

Since time immemorial, the Apple Developer Center employs a rather sophisticated system of certifying your applications at each of the key stages — development, testing, and publishing.

Often at the first immersion into this system, beginners (and not only) developers have serious problems with understanding how the Apple Developer Center functions (we will call it “devcenter” for simplicity). As a result, in the course of my professional activity, I often had to observe in the new places of work huge dumps of profiles and certificates in the devcenter, as a result of which I had to proceed to “digging debris”.

In this case, the network is not quite such a large selection of materials on this topic. Of course, Apple’s official documentation is all well structured and described in great detail, but often there’s just not enough time to study so much material. As a rule, you want to quickly understand exactly what and in what order you need to do for the application to work correctly during the development, testing and publishing process in the App Store. In the Russian community, I did not see such materials collected in one place and in convenient access at all, so I decided to write this article. For all interested - welcome under cat.

What are we going to disassemble?

We will analyze the process of managing your application in the Apple Developer Center from its creation to publication in the App Store. We will only talk about basic things, such as development, testing and publishing, as well as discuss APNs (Push Notifications).
')
I will note the fact that later on I will describe the principle of operation of the center as of March 31, 2016, so if you read this article later, everything could have changed.

What do we need?

Actually, for work we need the following:

• A working Mac, or PC with a virtual machine and Mac OS installed on it.
• Valid Apple ID. It can always be registered for free on the official Apple website .
• Your Apple ID (or one of the companies that added your Apple ID to your team) must have the so-called Apple Developer Program activated — a “subscription” paid once a year, giving you access to the Apple Developer Center and the ability to publish your applications to App Store. Currently, the cost in terms of the year is small and amounts to around $ 99 per year of use.
• And, of course, iOS development skills.

Orientation by sections

In the devtsentre for full-fledged work with your applications, we need only two points:

• Certificates, Identifiers & Profiles. The section provides management of the entire certification system of your applications. We will analyze the work with this section in this article.
• iTunes Connect. Gives access to internal and external testing through TestFlight, as well as to manage the publication of your applications in the App Store.

Terminology

Let's take a closer look at the concepts underlying the functioning of the Apple Dev Center.

Certificates

This section gives you access to managing certificates held by your Apple ID account. Each of the stages that you will undergo, whether it is development, testing or publishing, including all significant components of the Apple ecosystem such as Push Notifications, requires the presence of a current (active, Active) certificate. Simply put, your application cannot even sneeze without permission from the Apple Developer Center. A little more about the subsections:

• Pending The certificates you requested are being processed by Apple. For Dev (Development) and Prod (Production) certificates specifically in my case, this subsection is most often empty.
• Development. Dev certificates that provide the ability to debug your application on specific devices (one or several) via Xcode, as well as creating dev assemblies “in debug mode”. In more detail we will talk about them below.
• Production. Prod certificates that ensure the performance of the application when tested in TestFlight and when published in the App Store.

Now analyze the types of certificates.

Development type certificates

First of all, you need to know that the developer certificate is always tied to one particular machine . Therefore, to debug on your Mac, you will need access to this certificate. There are options. For example, if you are employed by an iOS programmer, and your tasks include debugging on devices (as a rule, it is), then there are two ways to decide (which one to choose depends on you and the conditions of work in your company) :

• Create a separate dev-certificate specifically for your Mac, download and install it. Plus, you will need to generate and install a developer profile on your Mac based on this certificate, but more on that later.
• Or, export the * .p12 / *. Pfx file from the machine on which the certificate is entered (this can be done in the Apple keychain). Such a file is protected by a password when exporting, and, knowing this password, the certificate information can be imported to any other Mac. In this case, there is no need to create separate Development-certificates and separate Development-profiles for each Mac. A small disclaimer: the profile should be generated for the machine to which the exported certificate is issued, but you need to add the UDID of your device to this profile before issuing the profile to you for installation, otherwise nothing will work.

Instructions for the process will be shown to you in the Apple center at the beginning of the creation of the certificate, everything is written out in great detail and is understandable, step by step should not arise. In short, after selecting the certificate type ( iOS App Development , for debugging the application, or APNs Sandbox , for debugging push), you will have to create a Certificate Signing Identity Request file, on the basis of which the developer certificate will be generated. If you want to debug the application, and debug the push notification in the sandbox, then you need both of these certificates. Looking ahead, I will mention that a similar process is also used when creating prod certificates.

Having a dev certificate means that by downloading it and installing by double-clicking on the Keychain (Apple Keychain), you can run your application directly through Xcode in debug mode on the device, and connect the device to your Mac. The list of allowed specific Apple devices will need to be specified when generating a developer profile, but more on that later. Also, you can build and export an assembly with a dev profile, but it’s worth considering that in this case your application will not have access to production capabilities (APNs will only be in sandbox mode, for example).

Certificates of type "Production"

First of all, just in case, I’ll explain that the assembly of an iOS application is called the * .ipa-file, an archive produced in compliance with Apple certification rules through the Project - Archive command in Xcode.

Now about certification. Prod-certificates ensure the functioning of various subsystems of the application in “combat” conditions, that is, in the App Store, as well as on devices where internal and external testing of the application is performed through TestFlight. Here, by analogy with Development-certification, there is the App Store & Ad Hoc Production type, as well as the APNs Production type, which is used by the web server for sending push notifications. If you plan to release an application that supports pushing, then you will need both certificates, such as App Store & Ad Hoc (based on which you build and send the application to iTunes Connect) and APNs Production (you will give it to the server). will use it to obtain the right to send a message to push). In the appendage to the already mentioned subsystems, there are several others that provide access to Wallet, Apple Watch, and so on, but their review is beyond the scope of this article.

Very often the question arises of what is the difference between the App Store and thus Ad Hoc. Previously, they were presented with different certificates, for some time Apple has united them into a single whole, for which many thanks to them. A little more about these varieties:

• The release of assemblies such as App Store. Provides the ability to test the application in TestFlight, both in internal mode and in external testing mode. Also provides an opportunity to publish the application in the App Store.
• Release of Ad Hoc type assemblies. The term "Ad Hoc" can be translated as "special", "for a specific purpose." This type of certification provides the ability to run your application (including all the necessary subsystems such as APNs) in combat conditions, but only on specific devices, and without the participation of Xcode in the launch process. In other words, Ad Hoc is necessary if you want to put your application on a third-party device without having direct access to it (that is, without connecting it with a wire to your Mac, because in this case you would have enough Development-certificate), but and without putting the app in iTunes Connect. This certificate is used to create a special Ad Hoc profile, which will be discussed later.

Another frequent question: what is the difference between assemblies assembled on a pair of Development Certificate + Development Profile and assemblies created through the Distribution Certificate + Ad Hoc Profile link? After all, both there and there it is necessary to indicate the list of devices allowed for installation, and both can be installed via iTunes. What is the difference? In fact, the difference is that the dev-build will run “in debug mode”, that is, for example, APNs will only be available to it in the sandbox mode. Production assembly will have “combat” rights, with access to all Apple subsystems like “real” APNs, iCloud, and so on.

Intermediate Certificates

Some time ago, Apple made changes to the logic of the devcenter and its certification system, after which most computers lost the ability to build applications, despite the presence of active vir- and prod-certificates and relevant profiles. The reason for this was that Apple added an additional requirement that a special certificate called the Worldwide Developer Relations Certificate Certificate Authority be installed on your Mac in a keychain. It is installed automatically with new versions of Xcode, but those who already have Xcode installed earlier simply had to install this certificate manually by downloading it from a direct link from the Intermediate Certificates section in the Apple center, after which the build problems disappeared. No more semantic load this certificate does not carry.

Identifiers

This section provides identity management. For your application in the minimum version, you will need App ID, which is available in the same section.

In literal translation, “App ID” means “application identifier”, which fully reflects its essence. Any of your applications that you want to debug on an Apple device, test through TestFlight and / or publish to the App Store, must have its own unique name, by which it can be uniquely identified among thousands of other applications. When adding a new App ID, you will be prompted to enter several items:

• App ID Description. The name of your application. For example, if your application is called Mail Printer , then we write it in this text field just like that.
• App ID Prefix. The prefix of your application, it will be given to you automatically and will be common for the specific Apple Team where the Apple Developer Program is active and active.
• App ID Suffix. Here we need to select Explicit App ID to specify the bundle of the application. This is an identifier, usually of the form com.mycompany.myappname , where mycompany is the name of your company or your domain. For example, com.homecompany.MailPrinter . I draw your attention that exactly the same bundle must be set up in the Target settings of your application in Xcode (General settings section, Bundle Identifier field).
• App Services. Here you need to mark the services that you plan to use in your application. By default, only Game Center and In-App Purchase are marked there, their use is mandatory, they cannot be removed. Connect other services as needed.

After creating the App ID, you can use it to generate any type of profiles, more on that later.

Devices

This section hosts all Apple devices that you can use as part of your Apple Developer Program. There is a limitation, a maximum of 100 registered devices of the same type (iPhone, iPad and so on) per account per year, usually this is more than enough. If you need to debug on the device or release Ad Hoc-assembly, simply add here the UDID of the devices you need and use them when generating profiles.

Profiles (Provisioning Profiles)

Literally, the name of this section is translated as “Provisioning Profiles”. In a little more detail, I would describe the concept of a “profile” as “A special file that provides access to some functionality in a specific assembly of your application.” In this section of the devcenter, you can manage your profiles, ensuring that you can release the application assemblies for various purposes, that is, “profile” it. In essence, a profile is the result of combining two (sometimes three) components:

• Active certificate of a certain type (section Certificates). Using a certificate, the profile confirms that your application has the right to perform a specific group of actions.
• App ID (section Identities). Specifies the specific application for which the profile is issued.
• In some cases, you still need a list of registered devices (section Devices). Defines the list of devices on which it is authorized to install your assembly. Used only with certain types of profiles.

At the exit, we get a profile for the release of assemblies with specific goals. Let's look at the types of profiles.

Development type profiles

This is a development profile, that is, its main purpose is to debug your application on specific devices via Xcode with a direct connection of the device with a wire to your Mac. Dev profiles are represented by two types:

• iOS App Development. Requires an indication of the list of allowed devices from the Devices section.
  Used for debugging iOS applications.
• tvOS App Development. Similarly, only used for tvOS applications.

Distribution Profiles

These profiles are used to release assemblies of your application for various purposes. Production profiles are represented by four types:

• App Store. Used for testing (both internal and external) in TestFlight, as well as for the release of the application in the App Store.
• tvOS App Store. Similar to the previous one, only for tvOS.
• Ad Hoc. Requires an indication of the list of allowed devices from the Devices section.
  Used if you want to release an assembly that can be installed in the Production mode, but only on some devices. The real situation when it may be needed, for example, is the following. You are developing an application, and in the process, the customer asked you to “let him touch the application” on his Apple device. In iTunes Connect, you are not yet ready to activate external testing, but the customer’s request has to be fulfilled - this is where the Ad Hoc profile generated on the basis of the App Store & Ad Hoc Production Certificate is useful. An important point : in my case, there were often problems when exporting assemblies in a similar way, if Development-certificate was also not installed in Xcode. Errors were of different kinds, from the inability to sign the assembly to the absurd “App ID is not available”, although this was not actually the case (replacing with another bundle did not give anything). Therefore, in my opinion, for the successful export of Ad Hoc assemblies, it is necessary that, in addition to the Ad Hoc profile, the dev certificate is also installed with the corresponding profile.
• tvOS Ad Hoc. Similar to the previous one, only for tvOS.

Briefly about iTunes Connect

This service provides you with the ability to manage internal and external testing in TestFlight, as well as upload the application in the App Store. Consideration of this process is beyond the scope of this article, I will mention only the fact that for correct operation this service requires assemblies created based on a profile of the Distribution-App Store type (for iOS or tvOS). Other profile types are not supported here.

We summarize

In fact, when accessing the devcenter from the active Apple Developer Program, your sequence of actions should be as follows:

1. Decide on which particular machines will be debugging directly on devices via Xcode. Identify among them the main machine (it could be a Mac developer, from which it is most often planned to debug). Generate development group certificates for the main Mac, download and install them. If necessary, export information about these certificates to * .p12 / *. Pfx files, which can then be sent to other target machines, where you also plan to debug applications.
2. Find out which machine you plan to build assemblies for testing and / or publishing on the App Store. Generate a Distribution group certificate for it. Repeat the procedure with the export from the previous paragraph, if you need support for multiple machines.
3. Check for the presence of the required application identifier in the App IDs section and whether the bundle specified there corresponds to the value of the Bundle Identifier field in the project in Xcode, if there is a discrepancy, eliminate it either in the devcenter or in Xcode (where it will change, depending on your particular situation).
4. Remove (Revoke / Delete) all certificates, and then profiles that are marked Expired (expired certificate) or Invalid (invalid profile). Also note that, unlike certificates, profiles can be edited. That is, having generated new certificates, instead of deleting old profiles, you can simply edit them, specifying them new certificates as a signature.
5. If there are no profiles, or the necessary ones are missing, then generate the necessary profiles.
6. Download and install certificates and profiles for your machine on your computer. Installation is done by double clicking on the file. Certificates will be installed in the Keychain (Apple Keychain), profiles - in Xcode.
7. Specify in the Xcode project settings the certificates you need in the Build Settings section - Code Signing Identity - Development / Distribution , as well as specify the required Provisioning Profile .

This completes the preparation and cleaning of the center. Then you can do any of the following items as needed:

• Run in debug mode (Project - Run) via Xcode on an authorized device using the dev profile.
• Create an assembly (Project - Archive with the selected target device Generic iOS Device ) based on the Ad Hoc production profile for installation on specific devices (such an assembly can be sent, for example, by e-mail to the customer, so that he can install it on his authorized device).
• Create an assembly similar to the previous paragraph, but based on the App Store production profile. This will be an assembly for internal and / or external testing, as well as for display in the App Store, which can be used in iTunes Connect.

I hope this detailed description will help you understand the specifics of the functioning of the Apple application certification system, as well as help to clean up the Apple Developer Center.