-
-
Notifications
You must be signed in to change notification settings - Fork 194
Description
(a.k.a iOS provisioning hell)
Naïve overview on iOS provisioning and certificates
Provisioning profiles can be 3 types and each of them binds together some properties to identify its type, the devices it can deploy to, the code signing certificate that can be used with it:
- AdHoc
- Name and UUID
- Supports all devices
- Bound to a single distribution certificate
- When app signed with AdHoc provisioning profile is deployed on device it requests additional permissions to launch the app
- Application identifier
- Team ID
- Expiration date
- Development
- Name and UUID
- App identifier
- Signing entitlements (specifying extended range of native capabilities such as push notifications)
- Device UDIDs that apps signed with this provisioning profile can be deployed to
- Development code signing certificates that can be used to sign with this certificate
- Team ID
- Expiration date
- Distribution
- Name and UUID
- Can not deploy to device but rather upload to the App Store
- Bound to a single distribution certificate
- App identifier
- Team ID
- Expiration date
In addition as of Xcode 8 there two signing styles: "Manual" and "Automatic". When enabled "Automatic" signing style within the Xcode the IDE will be allowed to recreate provisioning profiles and code signing certificates, during build a team id is provided, either through the flags in the pbxproj or xcconfig and the xcodebuild command line tool would select a provisioning profile and signing certificate for that team. When set to "Manual" a provisioning profile is provided either through the pbxproj or xcconfig and the xcodebuild will use this exactly provisioning profile. When a certificate is automatically generated by Xcode it can not be used with "Manual" signing.
N.B> The team id and provisioning profiles can also be specified through the command line of xcodebuild but when building multi-target projects (such is the case with Cocoapods) the provided signing is also applied to the pods frameworks, often resulting in mismatch. (given provisioning profile with org.nativescript.* app id it will fail to sign the org.cocoapods.* frameworks).
App identifier can be categorized in:
- Wildcard (org.nativescript.*) that can support broad range of app ids
- Specific (org.nativescript.examples) that can target a single id but such non-wildcard identifier is required for most advanced native capabilities such as push notifications, keychain access, health kit etc.
Certificates can be two types:
- Distribution
- An organization can have a limited number of distribution certificates
- Development
- Every developer in an organization can have exactly one code signing certificate
Certificates contain a public and a private key, the public key is uploaded to apple member center, while the private key stays on the admin or developer's machine. Loosing the private key requires the certificate to be revoked and a new one to be created. Recreating a certificate results in cascading need to renew the provisioning profiles it was used in.
- Every developer in an organization can have exactly one code signing certificate
Within {N}
Currently we have to support three main separate scenarios:
- Development
- App Store submission
- CI
Development
During development a provisioning profile should be provided in order the app to be sign so it can be deployed on a device.
AppStore
Building for the store requires the app to be built for release and distribution provisioning profile in pair with distribution certificate to be used when signing the app.
CI
CI usually is performed either for test and automation or automated App Store submission.
Existing Microinteractions in the NativeScript CLI
Specifying provisioning profile with Manual signing style using --provision
With the #2393 specifying provisioning profile and "Manual" signing style has been enabled. The workflow is as follow:
- Run
tns prepare|build|run ios --provision
will list a table with eligible provisioning profiles. The App ID, devices, etc. will filter provisioning profiles that will not support the current app. - Run
tns prepare|build|run ios --provision <uuid-or-name>
will save the specified provisioning profile in the platforms/ios/.pbxproj` along "Manual" signing style. Once set all subsequent commands will use the provided provision.
Along this, should "Manual" signing and a provision be specified using Xcode in the .pbxproj the CLI should respect it and use it if no --provision is specified on the command line
This behavior should also allow for CI to set a provision during build
Specifying development team with Automatic signing style using --team-id
When tns build|run ios --team-id <team-id>
is called, the team-id will be provided to the xcodebuild and Automatic signing style will be used to sign the app.
N.B.> In contrast with --provision this will not update the pbxproj as this option precede the --provision and during its implementation we had no convenient method to update the pbxproj.
N.B.> This have been reported to fail due to xcodebuild picking a wrong provisioning profile when multiple profiles are available.
Specifying team-id for Automatic signing style when no other means to sign the app si provided
When tns build|run ios
is called and targets a device, and no signing is specified in any other way, an interactive dialog will prompt for a team-id. It can be persisted in the app/iOS/build.xcconfig. The team-id will be provided to the xcodebuild and Automatic signing style will be used to sign the app.
N.B.> This have been reported to fail due to xcodebuild picking a wrong provisioning profile when multiple profiles are available.
Specifying singing in the xcconfig
Currently the app/App_Resources/iOS/build.xcconfig
is used for the app target and as such can hold flags used for singing. The workflow would be as follow:
- Run
tns prepare ios --provision
to list provisioning profiles and team along with their ids. - In the
app/App_Resources/build.xcconfig
set either:
DEVELOPMENT_TEAM = CHSQ******;
or
PROVISIONING_PROFILE = 5dca****-bd**-4d**-ab**-************;
Note that step 2 can either be done manually or it can be automated with CI scripts to allow for {N} apps to be build on CI.
Building and uploading to the App Store
tns publish ios
will build the app for release, produce Xcode archive, then export ipa signed for App Store distribution and use the Application Loader program to upload it to the App Store. Several options can be provided either through the command line or should command line args be omitted - through interactive dialog: iTunes Connect username and password, distribution provisioning profile;
As some of these interactions differ in behavior, we should consolidate the whole provisioning experience.