Distribute apps in Xcode with cloud signing

♪ ♪ Hi, my name is Balraj, and I am an engineer on the Xcode team. Today, I would like to tell you all about app distribution in Xcode 13. There are a variety of different ways to distribute apps, and today, I'll be discussing how to upload apps to App Store Connect, distribution options outside of App Store Connect, and how to automate distribution. I will also be going over new features we have added in the distribution workflow in Xcode 13, so you will find the content in this session valuable, whether this is your first time distributing an app or hundredth. Lately, I've been baking quite a lot, so I felt inspired to create an app to get others started called Baker. Baker will help people make a variety of different types of bread and baked goods. I recently completed the first build of the Baker iOS app, tested it extensively, and want to distribute the app to beta testers for feedback. For beta testing, I want my app to be available on TestFlight, which is a service for distributing beta builds of apps and getting feedback. In order to make a build of Baker available on TestFlight, I will need to first upload the build to App Store Connect.

App Store Connect is where I can manage the builds of Baker on TestFlight, as well as configure settings for my developer team. App Store Connect is also where I will manage builds of Baker for the App Store. So whether I am intending to make Baker available on TestFlight or the App Store, I will need to first upload a build of Baker to App Store Connect. I will upload my beta build of Baker to App Store Connect right in Xcode, so the distribution process starts right where I have been developing my app. Xcode 13 has some exciting new changes in distribution that allows me to upload Baker without performing any setup on App Store Connect or my local machine.

The first new addition in Xcode 13 is that you can create an app record directly in Xcode prior to uploading. Next, Xcode can manage your app's build number for you during the distribution process. And finally, with cloud signing, certificates and private keys will be stored in the cloud, meaning you will no longer need to manually set them up locally when using automatic signing. Let's take a look at how this all works by uploading the Baker app to App Store Connect from Xcode. I have the Baker project open, ready to be uploaded. The first thing I need is a build of the Baker app that can be processed for distribution. To perform this type of build, I will first select the Any iOS Device run destination in the toolbar, as I need to ensure Baker can be ran on any supported iOS device.

I then will select Product in the menu bar, and click Archive. An archive is a developer-signed release build of an application, which contains metadata about your app and team that will be used when distributing. After the archiving operation is complete, the Xcode organizer will automatically appear. The built archive is automatically selected, which is what I want to use for distribution. In the inspector on the right, I can also see information about the archive, such as version, bundle ID, team name, as well as a big blue button in the top right corner for distribution. In addition to storing archives, the organizer is also where I will be able to view different app analytics for all of my apps such as crashes, energy, insights, and metrics. As Baker is being beta tested, I will definitely be checking back here to get insight on how the app is running. To get started with distribution, I'll use the currently selected archive and click the Distribute App button.

The first step of distribution is selecting how I want to distribute Baker. App Store Connect is the default method, and I'll leave that selected, as this is where I want to upload to. There are a variety of additional ways to distribute your app displayed in this window, such as Ad Hoc and Enterprise, and I'll go over these in more detail later. To continue uploading to App Store Connect, I will click Next in the bottom right hand corner of the distribution assistant. I am then brought to a step asking whether I want to upload or export. Upload will take my archive, sign and generate an IPA, which is the format of an app packaged for upload, and send it to App Store Connect, while Export will also build an IPA and sign the content in the exact same way. The only difference is that Xcode will not upload the IPA to App Store Connect, but rather move it to a designated directory on your machine. This IPA can later be submitted to the App Store using Transporter. As I wish to upload Baker to App Store Connect right now, I will leave Upload selected and click Next to continue. Xcode will now check App Store Connect status and perform a variety of distribution setup steps. New in Xcode 13, I am shown a prompt to create an app record on App Store Connect, which is required before we can upload the actual build of Baker. The app record creation step provides default values for properties like app name, bundle ID, and primary language, which are derived from the Baker archive and system settings. I am happy with the default options, so I will click Next. Xcode now creates the required app record on App Store Connect. An app record is where I can view all the uploaded builds of Baker and is where I can set up TestFlight, in-app purchases, pricing information, and so much more. The Baker app record is now available on App Store Connect and is visible in my list of apps. The newly created Baker app record will be where all the builds of Baker will be managed, so I won't have to create a new app record again when performing subsequent uploads. After Xcode has created the Baker app record and validated our App Store Connect settings, I will be provided with a list of options that is determined by the content of my archive and how I am distributing an app. I would like to build for bitcode, I would like to include symbols so crash reports of my app are detailed and descriptive, and I would like to ensure the build number of Baker is consistent across every framework, so I will keep the default values selected and click Next to continue. I am now brought to a page asking how I want to sign Baker. Signing is used to validate that Baker is coming from a trusted developer and to ensure that software is secure to run. The two options provided to me are automatic and manual signing. Automatic signing lets Xcode handle signing for me, while manual is for when I want full control over the signing process. I want Xcode to handle signing for me, so I will keep automatic signing checked and click Next to continue. Xcode will now transform the Baker archive into an IPA and sign it for distribution. Automatic signing in the distribution workflow has underwent some exciting changes that makes signing work with no local machine setup. The signing process requires a certificate and private key to validate that I am a trusted developer. When locally signing, I would need to ensure that I had a distribution certificate and private key installed on my machine, which would often require manual setup before entering the distribution workflow. In Xcode 13, when using automatic signing, no certificate setup is required. Certificates and private keys can now be securely stored in the cloud, where the signing operation now takes place. This means that when using automatic signing, I don't have to set up certificates at all. This new style of signing is supported by every distribution method in Xcode, such as App Store uploads, Developer ID, and Enterprise distribution. Cloud signing works completely behind the scenes by managing all of your signing assets and signing your app. Let's go over how this works in more detail. Xcode will take the developer-signed Baker app in your archive and generate a partial signature for it. This partial signature contains hashes of the content within your app. A copy of those hashes are then sent to our servers, who, using a private key and certificate, signs your app in the cloud. We then return the remaining part of the signature and insert that into the partial signature to complete the signing process. Now, by using automatic and cloud signing, we have a fully distribution signed Baker app that can be uploaded to App Store Connect.

Anyone with an Admin or Account Holder role on App Store Connect can cloud sign for App Store Connect distribution by default. If I want someone with a Developer role to upload Baker using cloud signing, I can grant them permission on App Store Connect by checking the Access to Cloud Managed Distribution Certificate checkbox. Xcode has now completed packaging and cloud signing the Baker app and shows me a summary page before I perform the upload to App Store Connect. I can see information such as the type of certificate used, the version number, and the entitlements the Baker app was signed with. I am happy with what I see, so I will go ahead and click Upload. Now, Xcode will upload the first build of Baker to App Store Connect. Now, when I get onto App Store Connect, I can see the first build of Baker in the app record Xcode created earlier. From here, I will be able to set up Baker for TestFlight and start beta testing. For information on how to set up your app on App Store Connect for TestFlight, and also the App Store, please see our guide in the description. After getting Baker on TestFlight and beta testing, I have addressed many bugs and feedback. I now want to upload another build of my app with the needed updates. The process looks mostly the same as what we just went through. I will archive my app with the desired changes and distribute through the Xcode Organizer. There will be two differences. First, I won't need to create an app record again, and second, I will need to make sure the build number of Baker is different, as App Store Connect keeps each build and uses version and build number to differentiate them. I can do this by modifying the build number in my project file before archiving. But if I don't want to manage my build number, the distribution workflow can now do this for me.

New in Xcode 13, if Xcode detects I am distributing with a build number that has already been used on App Store Connect, or that is not incrementing, it will offer to increment the build number in the archive to one that is valid. Take a look at the Manage Version and Build Number option to see the build number Xcode selects.

As I let the distribution workflow manage my build number, I followed the exact same process as the first upload of Baker, and I now have a second build of Baker on App Store Connect. This cycle of releasing beta builds and addressing feedback will continue until I have a build that meets the desired quality needed for an App Store release.

To get Baker on the App Store, I can promote one of the TestFlight builds on App Store Connect, or upload another build in the organizer to App Store Connect in the exact same way we did before. Once Baker is on the App Store, I can then continue working on adding new features, bug fixes, and enhancements to the Baker app. When I am ready for the next upload for either TestFlight or the App Store, I can follow the same process in Xcode again. With the new additions we have made to the distribution workflow in Xcode 13, such as cloud signing, app record creation, and build number management, it is now possible to distribute apps with no prior machine setup or setup on App Store Connect. This makes distributing your apps more streamlined than ever. Xcode provides a multitude of different distribution options. Let's take a look at some of the other options for distributing apps, starting with Mac apps. Most iOS apps, including Baker, are available on Apple silicon Macs by default. To configure this setting, I can go to the Privacy and Availability section of the Baker app record. I want Baker to be available on Intel Macs as well, though, so I can create a Mac Catalyst version or native Mac version of Baker, and then I will have two options for how to distribute my app to the world. I can distribute the build of my Mac Baker app to the Mac App Store by cloud signing and distributing in the exact same way we did for iOS. If using the same bundle ID as the iOS app, my Mac app will use the same app record as the iOS version. This will also mean that certain features, such as in-app purchases, will be shared across the two platforms. I will also be able to make my Mac app available in TestFlight, as it is newly available in MacOS Monterey. This means I will be able to use TestFlight for beta testing Baker across all Apple platforms.

If I want people to download Baker outside of the Mac App Store, I can choose to distribute my app using Developer ID. Developer ID distribution cloud signs Baker with a Developer ID certificate and uploads the app to be checked for malware in a process known as notarization. Once Baker has been signed and notarized, macOS will trust the app to run on any Mac.

For more information on distributing using Developer ID and notarization, please view the "All about notarization" session. Developer ID and the Mac App Store are the two main methods of distribution for macOS, and both are great options for getting your app to the world. Now that we have gone over the different ways to distribute on Mac, let's take a look at a couple more ways to distribute your apps on iOS. Sometimes, I want to directly send my teammates a distribution signed build of Baker. This can be done for testing a bug fix, testing an experimental new feature, or a variety of other reasons. For this use case, I will want to use ad hoc distribution. Ad hoc distribution allows me to sign Baker to run on up to 100 devices registered to my team per device type. Using Xcode, I can choose the ad hoc distribution option, export my app, and then send Baker to one of my teammates with a registered device. Finally, my team has an app called Campus Explorer that we'd like to distribute internally within our company. Xcode provides two options to distribute in this way: custom apps and enterprise distribution. To use custom apps, I can distribute to App Store Connect and set up my custom app there. Second, if I want to distribute privately through the enterprise program, I can select the enterprise distribution method in the organizer. For more detailed information on custom app distribution, please view the "Custom app distribution with Apple Business Manager" session.

We have now distributed Baker in a variety of different ways and for many different builds. Over time, I will continually select the same options and methods when distributing, so I'll want to start automating the distribution process. Automating distribution is especially great when using a continuous integration service, as I can build, test, and distribute my app in one continuous workflow. The new Xcode Cloud CI service is great for this. Once you have built and tested your application, Xcode Cloud supports automated distribution of your app to App Store Connect. To learn how to set up and distribute your app in Xcode Cloud, please take a look at the "Explore Xcode Cloud workflows" session.

If you want to automate distribution using a different CI service or automate it locally on your machine, you can use the Xcode command line tool, xcodebuild. The `xcodebuild -exportArchive` command is used to automate distribution, and it takes in an archive, export options plist, and credentials. I can create the archive in Xcode, like I did during the first upload of Baker, or I can build it using xcodebuild's archive command. To refer to the built archive, I will use the `-archivePath` argument and pass the path to my built archive.

Next is the export options plist, which is like a recipe for distributing apps. This is where all of the options I selected manually in Xcode's distribution workflow are specified. If you export an IPA, an export options plist is saved to your exported directory with all the options you selected. When we uploaded Baker to App Store Connect, an export options plist was created, keeping track of options such as selecting upload, enabling bitcode, and selecting automatic signing. When xcodebuild uses this plist, it will distribute by selecting the exact same options as we did in Xcode. For a list of options that are available in an export options plist, you can run `xcodebuild -help` on the command line.

To specify the export options plist, I need to pass the `-exportOptionsPlist` argument, with a path to my plist file. Finally, I'll need to ensure xcodebuild has access to valid credentials in order to successfully cloud sign and upload to the App Store. There are two ways to do this. The first way is to sign in to Xcode prior to running xcodebuild, and the session will persist on my machine for a period of time. If I sign in with Xcode, the only required flag will be `-allowProvisioningUpdates`, which gives permission for xcodebuild to communicate with the Apple Developer website. New in Xcode 13, you can use App Store Connect keys to sign in to xcodebuild without ever signing into Xcode. The keys can be fetched from App Store Connect and passed to xcodebuild. The three things you'll need is the Issuer ID, which is passed to xcodebuild using `-authenticationKeyIssuerID`; the Key ID, which is passed using `-authenticationKeyID`; and finally, you'll need to download the API Key using the Download API Key button. The path to the downloaded file can be passed to xcodebuild using `-authenticationKeyPath`. xcodebuild still requires allow provisioning updates, as it still needs to communicate with the developer website. Once you have that and all the App Store Connect keys, you will have the credentials needed for xcodebuild to distribute your app. Now that I have an archive, export options plist, and credentials, I have everything needed to construct the full xcodebuild command. Here are all the elements put together for the command to automate distribution for Baker. I want to continue to provide updates to my beta testers once a week, so I will set up my CI to do this using this command for distribution.

And that is all the ways to distribute apps using Xcode 13. From distributing to App Store Connect for TestFlight and the App Store, to distribution methods such as Developer ID, ad hoc, and enterprise. Then, finally, to automate the distribution process, you can use xcodebuild or the Xcode Cloud CI service. For more information on how to distribute your app using Xcode Cloud, please view the "Explore Xcode Cloud workflows" session, and for more information about other distribution methods in detail, the "App Distribution — From Ad Hoc to Enterprise" session has some great information. Thank you so much for listening, and have a great WWDC! [upbeat music]