Once the developer account application is complete, it’s time to apply for a certificate and start debugging and publishing the APP
Developer Center
Certificate
A Certificate is used to sign an application, and only a signed APP can guarantee that its source is trusted and that the code is complete and unmodified. In the Code Signing Identity of Xcode Build Setting, you can set the certificate to be used for Signing your Code.
IOS certificates are digital certificates used to prove the validity and integrity of iOS App content (bundle with Executable and Resources). For an App intended to be installed on a real device or published to the AppStore, only after the Signature is Validated can the source be trusted and the content of the App be complete and untampered.
As we all know, before we apply for a Certificate, we need to apply for a Certificate Signing Request (CSR) file.
Certificate signing request
This process actually generates a pair of keys (public and private) that are stored in your Mac’s Keychain. It is this asymmetric key based encryption method that code signature uses private key for signature and public key for verification. As shown in the picture below,
The key
The associated public and private keys are stored in your Mac’s keychain login, and the certificate contains the public key. You can only sign with a private key, so if you don’t have a private key, it means you can’t sign, so you can’t use the certificate, you can only revoke the previous certificate and apply for another one. Therefore, it is a good idea to export and save your private key when applying for a certificate. When you want to share a certificate with another person or device, just pass it the private key. The private key is stored on your Mac, while the Certificate apple generates contains the public key. When you sign code with your private key, Apple can use the public key in the certificate to verify that you are the one signing the code and not someone impersonating you, as well as ensuring the integrity of the code, etc.
Identifiers App ID
App ID Identifies one or a group of apps. The App ID is the same or matches the Bundle ID in Xcode. There are two main types of App ids:
Explicit App ID: Explicit App ID. This App ID is used to uniquely identify an application, for example, com.abc.demo1, which identifies the application whose Bundle ID is com.abc.demo1. Wildcard App ID: Wildcard App ID, used to identify a group of applications. For example, you can represent all applications, and com.abc. You can represent all applications that begin with com.abc. Each time we create an App ID, we can set the App Services that the App ID uses, that is, the additional Services it uses. Each additional service has different requirements. For example, if you want to use Apple Push Notification Services, you must have a explicit App ID to uniquely identify an application.
The simplest Device Device is the iOS Device. Devices contains all Devices in the account that can be used for development and testing. Each device is uniquely identified by a UDID. The limit is 100 devices per account (100 for each type; iphones and ipads count as two types).
Note: Deleting a device will not restore the device quota immediately, but will not release the quota until the first device is added until the current developer account expires and is successfully renewed. Example 🌰: the membership is valid from August 8, 2017 to August 8, 2018. Currently 80 devices have been added, and the number of devices that can be added is 20, delete 10 devices. The total number of devices is 70, and the number of devices that can be added is 20. Until August 8, 2018, when you successfully renew the fee, the number of devices will be released when you delete devices during this period. For example, if you delete all devices, 100 devices can be added. However, once a device is added and then deleted does not release the quota.
Equipment reset date
A Provisioning Profile contains all of the above: certificates, App ids, devices. Is a comprehensive description file.
If we want to package or run an application on a real machine, we first need a certificate to sign the application, which identifies it as legitimate, secure, complete, etc. Then you need to specify its App ID and verify that the Bundle ID matches it; Again, if it is a real machine debugging, you need to confirm that the device can be used to run the program. A Provisioning Profile packs all this information together so that we can use it in debugging and distribution packages so that we can simply choose different profiles in different situations. And the Provisioning Profile will be embedded in the.IPA package at packaging time.
For example, as shown below,
Provisioning Profile.png
A Provisioning Profile for Development contains the App ID, available certificates, and devices for that Provisioning Profile. This means that using the Provisioning Profile wrapper requires the Provisioning certificate and running the application with the App ID on a device included in the Devices.
As mentioned above, the process for running an application on a single device is as follows:
The validation process
