Hi, good morning. Thanks.

Welcome to What's New in Xcode Signing. Signing your apps can be complicated. We understand this. And what you need to know is, in Xcode 8 we've made it really easy and fast to manage signing. In fact, it's automatic. And on the other hand, if you want 100% control over what Xcode does and when it signs your apps, you now have that as an option. And Xcode won't modify or create profiles.

Signing identifies you to users. And they know that when they get your app, it came from you and it hasn't been tampered with. Signing also prevents spoofing your apps. When you register your bundle ID with the developer website, another developer team can't come along and use that one. Signing also allows access to system services like iCloud internet payments.

We're going to go over four things today. We're going to start out by talking about the fundamentals of signing. What do you need in order to sign your apps? After that, we'll talk about some exciting changes that we've made involving setting up new machines with signing certificates. Today, you have to do things like sync private keys.

Or revoke and recreate certificates. And that's a thing of the past. Yeah [applause] you're going to love that. And after that, we're going to introduce you to some new workflows that makes managing signing really easy. And we'll finish by talking about some best practices with setting up your projects.

Let's talk about the fundamentals. Now when Xcode builds and signs your app, behind the scenes it uses a tool called codesign. Now if you're new, you don't need to think about this. Xcode does this for you automatically. And if you're experienced, you might be wondering, signing. How does it work? Well, we use this codesign tool. And what codesign does is, it takes your app's bundle and applies a code seal.

And this allows the system to detect changes that have been made after the app has been signed. So if someone messes with your app, it won't install or launch. Codesign also applies a code signature to the application. So it can be identified. And people know where the app came from.

There are three things that you need in order to sign your apps. The first thing is a signing certificate. Signing certificates establish your identity as a developer. Provisioning profiles are all about your apps, and they grant permissions. And entitlements declare support for capabilities. Like iCloud or Wallet. So certificates.

These are issued by Apple. And this is important because the device needs a trust chain back to Apple so it can install the app. And certificates come in two forms. You have development certificates, which are for build and run. And you have distribution certificates. Which are used for authentication with iTunes Connect. Or, if these are enterprise certificates, it's for distribution to users.

And all signing certificates require a private key. This private key has to be in the keychain if you want to sign your apps. And the private key for a certificate is created when the certificate gets generated. And so it's very important to have this private key. And it's worth noting here that Apple never has a copy of your private keys. You can't go to the developer website and download them.

Now the good news is, in Xcode 8, for your development certificates, you don't need to worry about this anymore. And we'll talk more about that in a second. Provisioning profiles are also issued by Apple. And in contrast to certificates which are all about your identity as a developer, the profiles are all about your apps.

Profiles allow access to things like running on devices. There's a list of identifiers in a profile. And at install time, the device runs down those list of identifiers to check if yours is included. And if it is, you can install the app. Profiles also allow access to entitlements.

There's a white list of entitlements in a profile. And if you want to use an entitlement, it has to be in that list. Now once again, if you're new, you don't need to think about this. Xcode handles this for you. And if you're experienced, you might be wondering why you need a new profile when you add an entitlement to your app. It's because of that white list.

Speaking of entitlements, entitlements declare support for capabilities. And fundamentally an entitlement is just a string with an associated value. Like a string or a bowl. And these are defined per target. So if your app uses one set of capabilities, and your app extension uses another set, that's fine.

And Xcode has a dedicated editor for working with capabilities, called the Capabilities tab. And the Capabilities tab will manage your entitlements PLIST in the configuration details. So you don't have to visit the developer website. You can do it all from within Xcode. So those are the things you need in order to sign your apps.

Now what happens when Xcode goes to sign your app? It needs to know which certificate to use, and which provision and profile. The way that works is, Xcode will build your app. And then it looks at the list of certificates on your machine. And it picks the newest one that matches your development team.

Xcode then looks at the list of profiles. And it picks the newest one that matches your bundle ID. And these two things are brought together. The profile is embedded in the app. And the certificate is used with Code Sign to apply the code seal. So that's a quick run through of some of the fundamentals of signing your apps. Let's talk now about the changes we've made for setting up new machines with signing certificates. So who's seen this before? Yeah. Your account already has a certificate, and Xcode offers to reset it. So what happens when you click that button?

Yeah, so what happens is it gets rid of your current cert and makes a new one. And why is this? Well, your development account has a limit of one signing certificate. And if you have a single machine, this works great. The cert is created. You have a private key that's generated, and it stays in your keychain and it just works. Now what happens if you have a second Mac? Well, to build and sign on that second Mac, you need a signing cert and a private key.

And you can either sync that over using keychain access or Xcode and import the private key on the second Mac. Or you can create a new signing certificate. But that first requires getting rid of the old one. And now you can build on the second Mac, but you can't build on your first Mac anymore.

And it's easy to repeat this process, and go back and forth between being able to build on one machine, and not being able to build on another one. And this is really frustrating and cumbersome. Well, the good news is in Xcode 8, you can now have multiple development certificates. So -- yeah [applause].

Each of your machines can have their own dedicated certificate and private key. So you never have to sync private keys for development, and you don't have to see this again. These changes apply just for development certificates. Your distribution certs still have a limit of one that you need to manage.

These are created both through Xcode or the developer websites. And these are created in Xcode 8 and later. And if you have an old copy of Xcode on your machine, and you create one of these new signing certificates, it works. They're 100% backwards compatible. So that's what we've changed about signing certificates in Xcode 8. I'd like to turn the stage over to my colleague, Itai, who's going to tell you about the new workflows in Xcode 8 [applause].

Good morning everyone. So Joshua's walked us through the fundamental pieces that are involved in signing your applications. You need a signing certificate and a provisioning profile that matches your device and your app's entitlements. But many of you also have app extensions. Watch apps. Or embedded frameworks in your app. And each of those brings its own signing requirements.

All this can add up to a complicated picture, where signing becomes a bit of a puzzle. And fitting all the pieces together can be pretty difficult sometimes. So Xcode for many releases has provided assistance to help make this easier. In Xcode 7, the Fix Issue button would appear whenever Xcode detected that something was wrong with your signing setup.

Now sometimes clicking on Fix Issue would fix the problem, and you can return to developing your app. But a lot of the times it wouldn't fix the problem. Or you had to click it multiple times. And in all cases, Xcode wasn't very communicative about what the issue was. What it did when you clicked Fix Issue, and why. And really, if Xcode knew how to solve the problem, why did it need to interrupt your development workflow and make you click a button?

Interacting with signing in Xcode 7 often felt like you were talking to a black box. You couldn't see inside, but you could mash the red panic button whenever you got frustrated. So that didn't work out very well. And in Xcode 8 we've gotten rid of the Fix Issue button. But we've also done a lot more.

We fully redesigned how signing works in Xcode 8. There's a brand new signing infrastructure which is much faster and more reliable than before. On top of that, we built new workflows, and a new user interface in the General tab. So you can see and manage your signing settings all in one place.

Then we took a look at how Xcode communicates with you about signing issues. A lot of the error messages were not very actionable or communicative. And so we've revised them all in Xcode8. So that you see much more helpful and actionable information when something goes wrong. And for those of you who are very curious about what Xcode does on your behalf when it fixes a signing problem. We've added new status reporting. So you can always see exactly what Xcode did and why.

So as Joshua mentioned at the beginning, there are two new ways of working with signing in Xcode 8. The first one is automatic signing. Now automatic signing has been fully redesigned, and it takes care of all of your signing needs for you. You'll never need to create a profile, or update your app ID. And Xcode will do it all in the background. So while you're developing your application, Xcode will keep your signing up to date.

For those of you who want full control over how your application is signed, you can enable customized signing. In this mode, Xcode will never create or modify one of your provisioning profiles. And it will never change your signing settings. So let's take a look at how these work in a little bit more detail. Starting with automatic signing.

When you create a new project, automatic signing will be on by default. But if you're an experienced developer, or you're opening an existing project, you can enable it in the General tab in this new signing UI. All you have to do is check the box. And then tell Xcode your development team. From that point on, Xcode will take care of creating profiles and signing certificates for you. And it will even show you the profile and certificate that will be used when you build your app.

So what sorts of things will automatic signing do for you? Well, it will create your signing certificates. So if you're developing an iOS app, it'll create an iOS development certificate for you. It will also create and update your app ID's and profiles. And it does this in the background while you're working on your application. So you can stay focused on developments.

But there are still some instances where Xcode 8 will prompt you. In particular, when you connect a new device to your Mac. One that's not already registered on your development team. Xcode will ask you before it registers it. Because we know device limits are finite, and you want to have full control over how those are allocated.

And finally, if you're curious about what Xcode does on your behalf in the background, you can view the signing report to see exactly what Xcode did, and why. So let me show you how this all works on the demo machine. So I'm going to show you automatic signing on Xcode 8, using a brand new iOS app.

I'll hit Next. And I'll give this a name. I'm not a great cook, so I like easy recipes. Now the first thing I'd like to call your attention to in the new project assistant is the new popup labeled "Team". When you create your project, you can immediately choose the development team that you'd like to use for signing. And from that point on, your project will already be configured for automatic signing with the right team. So I'll just hit Next.

And I'll create this on my desktop. So what did Xcode just do? It created a brand new project, and automatic signing is turned on by default. When I created the project, it immediately generated the signing certificate and a provisioning profile for me. I can zoom in on here so it's easier to see.

If I'd like to change my development team, I can also do that there. So that's how easy it is to set up a brand new project. I can immediately build and run on a device. I never had to click "Fix Issue" or configure any profiles myself. All I did was create a new project, and tell Xcode my team. But let's make this a little more interesting.

As Joshua mentioned earlier, you can use the Capabilities tab to enable platform features that you'd like to use, like Cloud Kit. So let's do that in this application. We'll go to the Capabilities tab. And here I see all the capabilities that my app can support. And all I have to do is flip this switch to turn one on. I'd like to use Cloud Kit here, and Push Notifications.

So when I did that, Xcode made a few changes to my project. It linked frameworks. It modified my Entitlement's file. But it also communicated with the developer portal to download a new profile. And now I can build and run my app. And I can immediately start using these features. Again, I never had to click a Fix Issue button, or type in any entitlements myself.

Now, I happen to know that Xcode downloaded a new profile, because I'm an Xcode engineer. But most of you probably aren't. So if you're curious about what Xcode did, you can always click over to the Reports Navigator. Where you'll see a brand new report called Update Signing. Whenever Xcode resolves a signing problem for you, one of these reports will be created. Let's take a look at the most recent one to see what it contains.

And I'll zoom in to make that easier to see. So here we can see Xcode diagnosed a problem. And I can see more information about that problem by selecting that row and expanding it. So Xcode's telling me my existing profile doesn't support iCloud. And immediately below that, I can see that it created a new profile for my app. So that's how easy it is to see exactly what Xcode does on my behalf whenever it fixes a problem.

Now there are a few more things you should know about automatic signing. The first one is that it does development signing. Distribution is handled through a different workflow; which Joshua will describe a little bit later. And it's limited to Xcode created provisioning profile. These of course are profiles Xcode makes on your behalf, and it keeps them up-to-date as you're working on your application. And as a result of these, you can use automatic signing without ever having to worry about your distribution signing assets being touched by Xcode. So your distribution certificate and provisioning profile will never be modified by automatic signing.

So automatic signing. It's been completely redesigned in Xcode 8. It stays out of your way, and it manages signing. So you can focus on what's really important, which is developing your app. Now let's take a look at the other side of the fence. Customized signing. As you'll recall, this is a mode where you have full control over how your app is signed.

You can enable customized signing by unchecking the checkbox in the General tab. And once you've done that, Xcode will let you choose different provisioning profiles for each of your build configurations. This is really handy if you have a continuous integration system. Or you need different profiles for free and paid versions of your app. Now you have the power to do that. And you can configure this all within the General tab. You don't have to visit the Build Settings Editor anymore.

So this is a really powerful new UI for configuring your signing settings. But we wanted to take this one step further. Those of you who have manually chosen profiles in the past, have probably run into some weird installation or runtime issues usually having to do with entitlements. And we wanted Xcode to give you more helpful information about that before you run into those issues.

So we've added new error reporting right within the General tab. And you can see this right alongside your settings. So it's easier to choose the right profile. Here I can see that my profile doesn't support the capabilities that my app is using. So I know exactly what I need to do in order to resolve the problem.

In addition, I can see more information about my provisioning profile by clicking the profile info button. And here I can see a lot of details. Like when my profile was created. Which capabilities it supports. And again, it's easy to tell when there's a problem, exactly what I need to do to resolve it.

Now customized signing is limited to manually created profiles. These are profiles that you or someone on your team has created using the developer website. And Xcode will never modify these. And you can choose any type of profile. So as I mentioned, if you want to use development profiles for some build configurations, and distribution profiles for others, you're free to do that.

Now this is a really cool thing. Especially for those of you experienced developers who have manually chosen profiles in the past. There's a new build setting in Xcode 8 called Provisioning Profile Specifier. And what this does is it references your profiles by name. Now the reason this is a big deal is because prior to Xcode 8, Xcode would reference your profiles by their unique ID.

Whenever a new developer joined your team, or you added a new device, you'd need to generate a new version of your profile. And when you did that, you'd get a new unique ID. So then you'd need to update your project. Well, now in Xcode 8, since we reference profiles by name, all you need to do is generate a new profile, and Xcode will automatically pick it up. You don't need to update your project [applause] thank you.

So let's take a look at how customized signing works on the demo machine. Okay. I'm going to show you another app I've been working on called, Scrapbook. And let me zoom in on that. So Scrapbook is set up for customized signing. I've chosen different profiles for the free and paid versions of my app.

And it's really easy to configure that in the General tab. This is all I had to do. Just select different profiles from those pop ups. And since I don't see any error messages here, I already know I can build and run on a device, and everything will work.

But as in the earlier demo, let's make this a little more interesting. I'd like to use the Capabilities tab so I can use iCloud and Push Notifications in this app as well. Now if you've used the Capabilities tab in the past with a manually specified provisioning profile, you might've noticed that it sometimes would change your signing settings. Or make changes that you didn't really want.

In Xcode 8, the Capabilities tab is now safe to use in customized signing mode. It'll make the local changes that are safe to make, such as updating your entitlements PLIST. But it won't touch your profiles. It'll just tell you what steps you need to take manually in order to resolve those problems. So let's take a look at that.

I'll click on Capabilities, and then turn on iCloud and Push Notifications. Now Xcode is showing me checkmarks next to the steps that it was able to complete. And little error icons next to the steps that I still need to complete on the developer website. I can see more information about this in the General tab. I'll zoom in on that.

And if you look at that error message, you can see Xcode's telling me my selected profile doesn't support iCloud and Push Notifications. That's kind of obvious since I just enabled those. But it's really clear. I can tell exactly what I need to do to fix this problem. Whereas in the past, if I had tried to build and run, my app either wouldn't install or wouldn't run correctly.

And finally, if I want to see more information, I can click the Profile Info button. And Xcode will show me more detail about my profile. Like the capabilities that it supports and those it doesn't. So again, it's easy to see exactly what I need to do to fix a problem. So let's go fix this one. As I mentioned earlier, in customized signing mode, Xcode won't modify profiles for me. I need to visit the developer website to do it myself.

So I'll open up the developer website and click on Certificates, Identifiers, and Profiles. The first thing I need to do is update my app ID. So I'll select App IDs. And I'll choose the app ID I've already created for this app. This shows me all the capabilities that are available. I'll hit, Edit. Scroll down and turn on iCloud.

Now this alert message that I'm seeing is reminding me that after I update my app ID, I also need to download a new version of my provisioning profile. So I'll just hit, Okay. And then I'd like to enable the newer version of iCloud. So I'll turn that on. And again I'm reminded that I need a new profile. So I'll click, Okay.

Scroll down and turn on Push Notifications. And now I'm done. The next step is updating my profile. So I'm going to click on Development. And you'll see the two scrapbook profiles are now marked as invalid. That's because I've made changes to my app ID. But I haven't regenerated the profiles yet. So they're out of date. Let's update the Scrapbook Free profile.

I'll select it and click, Edit. And I can scroll down through all of this. I'm not making changes to certs or to devices. And I'll click on Generate. And then download the new profile. Now the very last step is I need to install this profile so that Xcode can use it. I can do that just by clicking it in the Downloads folder.

So what just happened there? I'll zoom in on that. When I clicked on the profile, Xcode installed it, and immediately updated to start using it. So we can see the errors in the free build configuration of my app have disappeared. You might also have noticed that I didn't make any project changes here. This is provisioning profile specifier working behind the scenes. Once I installed the new version of the profile, Xcode just started using it automatically. Now I can build and run the free version of my app, and everything will work. I can use iCloud and Push.

But it looks like I still need to update the premium version of my app. Does everybody want to see me do that on the developer website? Or we get the idea? Okay. It's a little bit tedious. If you were paying attention to the earlier demo, you might have noticed this is actually -- all those steps I just performed are the exact same steps that Xcode performed for me in automatic signing.

So that's customized signing. A brand new mode in Xcode 8, where you have full control over how your app is signed. Xcode won't interfere with your settings, or modify your profiles. But I'd like to encourage you all to try out automatic signing. It's been completely redesigned in Xcode 8, and it's provides a really seamless development workflow that I think you'll really enjoy. Now I'd like to invite Joshua back up to show you some best practices [applause].

Thanks Itai [applause]. So we just saw the new workflows in Xcode 8 that makes it really easy and fast to manage signing. Now I'd like to talk about some best practices for managing signing in your projects. The first thing is, use automatic. Automatic is designed to make your life as easy as possible. And it works great with individual developers, or large teams. So you should add all of the developers that work on your app to your development team.

You should use the Capabilities tab to manage entitlements. So you can avoid visiting the developer website to configure things like iCloud containers. If you use customized signing, don't set code sign identity. You have a specific signing certificate that is linked to your account. So if you set this to your particular signing cert and someone else pulls your project, they won't be able to build.

So you should leave that with the default value. Instead of visiting the Build Settings Editor, you should use the new UI in the General tab of the Target Editor. This allows you to see more information about the profile. And it also correctly sets the profile specifier by name, so you can avoid churn in your projects.

You should also use the Capabilities tab in Customized Signing Mode to manage your entitlements PLIST. And if you use development signing for all of your project's configuration, you should try out automatic. When you get back to your Mac, go check that checkbox in the target editor and try it out.

When it comes to distributing your app, Xcode has a dedicated workflow for this. And it's based around building an archive. Archives contain a copy of your app. And it's important to note that you should use development signing. If you sign your app with a distribution certificate, you won't be able to test the exact bits that you were trying to develop. So this should be development signed.

And when it comes time to distribute that, when you use the organizer, Xcode will resign the app using your development certificate and provisioning profiles. And if you clicked Upload it will go straight to iTunes connect. Or if you clicked Export, you'll get an IPA file or an app that has been distribution signed. So that's the best practice for distributing your content.

We've covered a few things today. We've talked about the new changes to signing certificates that makes it really easy to set up new machines. We've talked about the new automatic workflow, which takes a lot of the pain out of developing your apps. And we talked about the new customized signing mode. So you can configure your projects as you see fit. If that's what you desire. If you want to learn more, check out this link. If you want to learn more about security or Xcode, check out these sessions. And with that, thank you.