Good afternoon. Welcome to session number 414, Building, Archiving, and Submitting Your App. You've probably spent most of this week learning how to take advantage of the great new features in iOS 6 and Mountain Lion while developing your application. So I thought that this afternoon we would do something completely different and talk about distribution, how you can get your software product into your customers' hands. And since I realize that I am all that stands between you and free food, we're going to keep it to three things.

Distributing your application outside of the App Store using a new technology called Developer ID. Then we're going to talk about how you can take your application and distribute it in the App Store, taking advantage of all the features and technologies available to both you and your customers. And then we'll talk about some best practices on iOS, as well as some new features that are available in the App Store this year in iOS 6. So let's get started by talking about how to distribute your application outside the App Store. The App Store offers you the opportunity to take advantage of a number of incredible technologies that exist on our platforms.

One of them is security. But we don't think that should be something that you can only take advantage of in the App Store. And to that end, we've introduced a new technology called Gatekeeper. Customers of the App Store have the advantage of knowing that the software that they receive from the App Store comes directly from you. And with Gatekeeper and Developer ID, they can do the same with your software that comes from outside the App Store.

Gatekeeper is turned on by default in Mountain Lion, and it's designed to protect your users from malicious applications. Now, this sounds a little scary, but in reality, this is actually a problem. Anyone with access to your web server can modify an application that you created and do whatever they want on your user systems, and that's bad. So Gatekeeper allows you to make sure that the application your customer is running is exactly what you intended it to be.

By default, Gatekeeper allows you to run applications that were obtained either from the Mac App Store or that were signed with a Developer ID. If neither of those is true, your customer will see something like this. How do you make sure your customer doesn't see something like this? You take advantage of what we've been talking about, Developer ID.

So what is it? A Developer ID identifies you as being someone who's trusted by Apple. And by virtue of the fact that you're trusted by Apple, the OS trusts you, and your software can run freely. And like other technologies for distribution, it has built-in support in Xcode so you can share your application with your customers right from the IDE.

Now we're going to talk about how to take advantage of this when you're ready to distribute your app, starting with how to obtain a Developer ID. If you've previously had experience distributing your software through App Stores, this will be something that's similar, but we're going to run through it now in case you haven't.

From the Organizer, you can choose this option from the Editor menu, which is to refresh from the Developer Portal. And once you do that, Xcode will communicate with the Developer Portal, figure out all the assets that you're entitled to based on what teams you're a member of, and ask you if you want to download them.

Naturally, it will say yes. And then once you do, it'll ask if you want to export them. And this is something that's actually very important, because your Developer ID is like your Social Security number. Anyone who has it can pretend to be you. And if you don't have it, you can't prove that you are you. So it's important to make sure you have a copy of it somewhere that's kept safe and secure.

And as an added convenience, if you want to set up a second Mac for development, your exported developer identity and profile is a single document that you can open inside of Xcode and get up and running. No need to go to keychain access, no need to download things from the portal. You can just double-click it and go. So once you've got that, you can take a look at what you've actually obtained. And these are the identities that are associated with your team.

And they come in, for Mac developers, two categories: those that begin with Mac, which are what you would use for your Mac apps for submissions, and those that begin with Developer ID, which is what I'm going to talk about right now. And there are two flavors: Developer ID application, and this is an identity that you use to sign your .apps, either that you distribute in an archive or on a disk image, and then Developer ID installer, which is what you use to sign the installer that you use to give your customers their .apps. And it's important to realize this, because, you know, installers are actually executable code. So there's a possibility for tampering there. So it's important to make sure that that's signed.

And once you have these, it's often useful to take advantage of them while developing your application. It's useful to test what your customers are actually going to receive by codesigning your application during development and working with it under a debugger. Similarly, codesigned applications are treated differently by the OS in a few circumstances, like when they actually are launched. So it's often useful to profile your application as if it was codesigned.

So to actually produce this, what you can do is go to your project editor, and the summary panel offers you the option to codesign the application. Checking this box will cause Xcode to automatically select the appropriate identity for your application. And usually this is correct. However, if you run a bunch of teams or you're doing something special, you can actually override this yourself inside of the build settings editor just by going to the code setting identity build setting and choosing a different one.

When you're ready to distribute your application, you can produce something called an archive from within Xcode. And this is a really fundamental and powerful feature that we introduced with Xcode 4. It lets you package up your application, its symbols, and some information that Xcode knows how to read into a single bundle that the organizer can deal with. And from that archive, you're ready to distribute it, submit it to the stores, validate it to make sure it's ready to go to the stores. These are all things we'll talk about later, but you can do them all from an archive from within the organizer.

So once we've created one of these archives, which we're going to show you how to do in a minute, you can choose to distribute it. And to distribute it, in this case, we're going to choose to distribute it as a Developer ID signed application. And once we do, we'll be prompted to save it someplace on the file system, and then we can distribute it to our customers however we choose.

That's one security feature that's available to customers of the Mac App Store. And as I said earlier, we don't want those to be features that are unique to the store. So to talk about two other features related to security present in the Mac App Store that are available to your Developer ID signed applications, I'd like to introduce up Yevgeny. Good afternoon. As Mac and iOS users, we love to brag that our platforms are really secure. And as developers, we really want to make sure that our products don't contain any security vulnerabilities on these platforms.

And a really good way to do that is to take advantage of a technology that we have called Application Sandboxing. The word sandbox is actually really appropriate here because it means that your app has the freedom to do what it wants in its own little space. But it's walled off from doing anything malicious or damaging to the system in case it misbehaves.

When you launch an app with sandboxing enabled, the security framework prevents it from doing a few things. You can't access the file system outside of your own sandbox directory. You can't connect to or host any network servers. You can't access devices such as the camera, microphone, USB devices or printers. And you can't access the user's personal data like contacts, calendars, and location services.

And what this means is that it's a great benefit to our users. Because even if a bug is found at some point in your software that creates an exploitable vulnerability, then the potential for damage is limited to just the files that are created by the user in your app.

And Xcode makes it simple for you to take advantage of app sandboxing. All you have to do is go into your app's target editor, click on the summary pane, and enable entitlements. Then click enable app sandboxing. Of course, as soon as you do that, you're soon likely to run into the situation where you want to do something that sandboxing won't let you do. Let's say you want to use the microphone or the camera. Fortunately, sandboxing isn't an all-or-nothing proposition. You can take advantage of something called entitlements to allow fine-grained access to system resources.

An entitlement is just a permission to use a resource in the system, like the microphone or location services. And in this way, you can take advantage of the principle of least privilege, meaning that your app only has permission to do what it needs to do in order to get its job done, and it's not allowed to touch anything else. And you can take advantage of entitlements in Xcode just as easily by going back to the target editor and when you enable sandboxing, you'll notice that there are check boxes and drop downs to select which entitlements your app wants to use.

And once you make those changes, then Xcode will create a property list file called the Entitlements file. It'll populate it with those keys and then package it into your app bundle. Then when the app is launched, the security framework will read it and grant your app access to those entitlements. And that's how easy it is to add a whole layer of security into your app.

So now how do we create an app that's signed by Developer ID? There are four steps to this. The first is to actually obtain the Developer ID from Apple. Once you have it, you want to configure your project to use code signing. Then enable sandboxing and entitlements in your app. And finally, build and distribute it.

So let's actually see this in action. I'd like to show you a demo of how we can sign an app with Developer ID. So let's say we've already got an app that's pre-built. And my app happens to be a recipe viewer. And I want to open it up and take a quick look at it. We'll go ahead and run it. And there it is.

On my left here I've got a sidebar with all of my recipes, and I can click through them, and I can take a look, I can see the description for how to make it, and I've got a nice image of how the food is supposed to turn out if I make it properly. And this app looks great to me. So I want to package it up and I want to ship it to developers.

Well, right away, there's already a couple of problems with this. If I take the app that Xcode just built and I put it on a website and have people download it, then anybody could download it and modify it. They could tamper with it. They could inject malicious code into it and then redistribute it to unsuspecting users.

What's worse is that the users will just, they won't know what happened. They won't know they're even running this malware. At best, they'll get a panel on Lion and older systems that says, "This app has been downloaded from the internet. Are you sure you want to launch it?" And most users will end up clicking "Yes." And on Mountain Lion, we've gotten more strict with Gatekeeper. And so your second problem is that, by default, if a user tries to launch your app on Mountain Lion, the system just won't let it run. It'll deny it. It'll pop up that panel that Rob showed you.

And that's great news from a security standpoint, but it's not so great from a usability standpoint. So what's the solution? Well, you just have to use Developer ID to sign your app. So I want to show you how to use Developer ID right now. Let's close up our app. And the first step is going to be to request the ID from Apple. You do that from the organizer.

In the Devices tab, click on Provisioning Profiles. Now, if you've already made a developer account, that's great. You need to have one to use this. If not, go and sign up for a developer account. But let's say you've already got one. So now what you can do is go to the Editor menu and click Refresh from Developer Portal. You sign in.

Save your password. And then Xcode will connect to the portal and check for which developer identities you're eligible. And if it finds that there are certain identities that you haven't yet downloaded, Xcode will offer to download and install them for you. And that's what it's doing here right now. And there are a few different kinds of developer identities.

And Xcode will ask me once for each kind. These include the Developer ID application and installer identities that Rob mentioned earlier, as well as Mac App Store submission installer and development identities that we're going to talk about later. So Xcode here is asking me once for each type of identity. So I'm just going to go ahead and say yes, submit the request.

And once that's done, Xcode is being really helpful here and offering to export my developer profile. And the developer profile is a way to package up all of your provisioning profiles and development identities and private keys into one file. The reason you want to do that is so that you can back it all up into a secure location. It's really important that you hang on to these credentials and don't let anybody else have them, because if you lose them, It'll be really painful for you. You're going to have to set up a new Developer ID.

You won't have access to your old one. You won't be able to submit new apps under it. And it'll be painful for both you and your customers. So we really want to stress that you should export your profile and keep it safe and secure. So I'm going to do this now.

Give it a nice name. Save it to My Desktop and give it a password. Again, make sure that the password is secure. Because if anybody gets access to your profile, they can have your identity, which means they can do anything on the App Store that you can, and that's bad. So here it is saved on My Desktop. And if you ever want to do this again in the future, you can go ahead in the organizer, in the sidebar, click on your team. Go to the Editor menu, and under Developer Profile, choose Export Developer Profile.

And as long as we're here, I want to point out a couple of things that you're seeing. When you click on your team in the organizer, it'll show you a list of all of the identities which you've downloaded from this team. Notice that only one of these identities has my name on it. That's because this is the only identity that's tied to me personally. The other identities are shared by the team at large.

Also notice that there is a green checkmark or badge next to each identity. That means that this identity is valid and you can use it to code sign. If you ever encounter a situation where that's not the case, where there is no badge, it means there is no private key installed and that identity can't be used to code sign.

Some of you might have the situation where none of your identities have a badge. And this usually happens when you have a couple of machines that you're developing on. You'll start a project on one machine. You'll submit your code to a repository, download your Developer ID, and submit apps, no problem. But as soon as you take that code and download it to another machine, You could forget to move your private key onto it.

And then, for some reason, you'll find that you're unable to sign. Well, I'm telling you now that that's because you probably just forgot your private key, and so go ahead and put it on your other machine. But anyway, let's get back to our app. We now have our Developer ID. It's been downloaded. And so we could, if we wanted to, sign the app with it and distribute it.

But if we did that, we'd be releasing a product that has not been tested. It's a different product than we've been developing because a Developer ID will sign your app. It'll codesign your binary, whereas by default, your development binary will not be codesigned. And so to the system, these appear different.

And so when you're testing and debugging and developing, you really want to be running the same thing you're going to be shipping. So we suggest that you enable codesigning while you're developing. You can do that in Xcode by going to your target editor, Summary Pane, and clicking on Codesign Application.

And now I want you to take a moment and ask yourself, well, why do I want to use a Developer ID in the first place? The answer is you want to create a product that's secure and that gives your users confidence that you're protecting their data. More and more, every day, we're seeing users be more concerned about security.

And they expect that developers will be taking these concerns very seriously. They are protecting their data 100% of the time. And as I mentioned, sandboxing is a great way to add a whole layer of security to your app. And so we strongly encourage all of you to enable it. And I'll show you how that's done.

Back in your target editor, enable Entitlements. When you do that, Xcode will helpfully enable sandboxing as well. And also notice that the Entitlements file has been created for us in the Project Navigator. I can click on it, examine its contents, and here I see it's just an ordinary property list. It's got the key for sandboxing already in there.

And I go back to my target editor and I notice that there are all these options for entitlements. And let's say that I want to add a couple of features to my app where I use the camera, for example, to take photos of my great recipes after I finish cooking them. And I also want to enable printing so that I can give a copy of my recipe to my grandmother who refuses to get internet access. So I can do that by clicking the appropriate check boxes.

And so now the app is ready to be shipped. It's got the security layer of sandboxing, it's got the appropriate entitlements, we've tested it with code signing, and so now it's totally ready to be shipped. So finally, let's distribute it with the Developer ID. We do that by going to the product menu and choosing Archive.

The app will compile and build, and it'll appear in my organizer. I can now click Distribute, and I'll choose Export Developer ID Signed Application. On the next page, I'll choose the Developer ID that I'm using for my team. And if it doesn't appear here, just click Refresh Developer ID.

Finally, on the next page, I'll be able to save it. And before I save it, Xcode actually needs to codesign my binary with the private key that I'm using. And since it's the first time that I'm using this key, the key chain is going to ask me to confirm that I really want to use it.

And so I'm going to go ahead and allow Xcode to use it. And we save the app to our desktop. And there it is. It's ready to go. It's fully signed and fully authenticated, and people can go and download it and feel really safe and secure. And that's how easy it is to distribute an app using Developer ID.

So now I'd like to invite my colleague Rob back to talk about how to distribute an app using the Mac App Store. So that's how you distribute an application outside of the App Store. But like I said earlier, there are tons of great features that you can take advantage of and provide to your customers if your application is in the store.

Things like iCloud, Apple's push notification service for responding to things happening while your application isn't running. Game Center, so that if you have a game, your customers can actually play with their friends regardless of where they are. And in-app purchase, if you'd like to provide additional content in your application to your customers.

Submitting to the App Store is a process that's well integrated in Xcode and used by thousands of developers every day. And while Gatekeeper works out of the box for applications distributed through the App Store or signed with Developer ID, users of the OS can actually tighten the security of the application.

So if you want to distribute an application outside of the Mac App Store, you can do that by using the security threshold and say, "I only want applications that are coming from the Mac App Store." So distributing here is the way to guarantee that your software will run on all of your customers' systems.

So we just built an application. What would it take to get it in the App Store? Well, we're going to talk about three things today-- the app's bundle ID and how it relates to the app ID you set up when creating your application in the portal, Sandboxing, and some entitlements that we use for App Store specific technologies, and how to make sure your application is technically ready and all set up to be submitted to the store.

Let's start off by talking about your bundle ID. This is represented by your application's Info.plist as the CFBundle identifier key. And by convention, it's something that we want to be unique throughout the system. A lot of our APIs expect that. It should match your app ID that you've created in your provisioning profile.

And if you have an application that you distribute outside the App Store and have turned on sandboxing for it, it's a really great thing for your customers if you have the same bundle ID for your application that comes from both the App Store and from outside the App Store. If they're buying two copies of your app, this guarantees that they can share data between them.

If we talk about sandboxing, sandboxing is required for distribution through the App Store. And if you, when we go back and think about the technologies that are available to our customers through the App Store, one of them is iCloud. And there are some entitlements you can set up for that for using either the Key Values Store or for custom document and data containers.

Submitting your app is something that you want to take seriously. And it would be nice to know that you've actually set up your project in a way that it will be accepted and appear on the store. And Xcode has a workflow to help you make sure that that's the case. And we call it validation.

It makes sure that things like your application's copyright string is set properly, that you have a category specified for your app, things that are essential for being listed on the store, as well as enforcing some other policies that are specific to the Mac App Store or to the iOS App Store.

And we actually update these over the web to make sure that they are exactly what you will be tested against when you submit. And to do that, once you've created an archive, you can actually validate it from right within the organizer. It's the button right on top of distribute. And you can choose to validate against the Mac App Store's requirements.

And now, if you don't pass validation, Xcode will tell you about it, and you can go and fix up the warning or the error and revalidate and then submit. To talk about some of the technologies that are available only in the Mac App Store and how you can take advantage of them in your app, I'd now like to invite up Itai. Thanks, Rob, and good afternoon, everybody. As Rob mentioned, when you choose to distribute your app on the App Store, you get to take advantage of some great technologies.

iCloud, Game Center, In-App Purchase, and Push Notifications are services that customers love. And if you take advantage of them in your apps, then customers will love your apps even more than they already do. So before I move on, I just want to point out that everything I'll be talking about is applicable to both the iOS and Mac App Stores, with a few exceptions that I'll point out as I go along.

So here's a brief overview of what I'll be talking about. Now, when you set down the path of building an App Store app, one of the things you should know about is provisioning profiles. So I'll tell you a little bit about what they are and how to create and use them.

In addition, one of the big new changes in Xcode is the addition of support for in-app purchase content. With the new version of Xcode, you can create, package, and submit in-app purchase content from directly within the IDE. And if you've used in-app purchase before, you'll find this greatly streamlines your workflow.

So a lot of what I'm going to show you involving provisioning profiles involves performing administrative tasks like creating provisioning profiles, registering devices and app IDs. And depending on how your team is set up, you may not necessarily have every team member have access to perform these administrative tasks. There are three roles that you can assign to each individual on your team: member, admin, and agent.

Now, most of the people on your team will probably be members. This is typically all of the development engineers or testers on your team. And people who are assigned the member role can download provisioning profiles, request certificates, and also obtain software assets like pre-release SDKs and beta releases of the tools.

So if you think of your team with a file system analogy, team members essentially have read-only access. They can download and use your development assets, but they can't create them themselves. In order to do most of what I'm going to show you, you'd have to be an admin. Now, admins can manage your team's membership. They create and approve certificates for your team members. They create provisioning profiles and also register hardware and app IDs.

Finally, the team agent is the individual who is the primary contact for your team, and they're responsible for your team's membership in the development program. Most importantly, they're also the only individual who can submit applications and can generate distribution certificates and distribution provisioning profiles. Now, if you stop and think about this for a moment, that makes a lot of sense because any software distributed using these assets reflects on your organization's identity and reputation. So you want to make sure that only responsible individuals can actually do this. So what is a provisioning profile? Now, this is a great topic to talk about just before the beer bash.

And I take no responsibility if this drives you to overindulge tonight. But I'm going to try to make provisioning profiles as simple to understand as possible. They're really not that complicated. So I like to think of a provisioning profile as a big blue box. OK, that's it. Let's move on.

Just kidding. Provisioning profiles contain three things that you need to know about. The first one is an app ID. Now the app ID, as Rob mentioned, is roughly analogous to a bundle identifier. And I'll talk about it in a little bit more detail in a couple more slides. But right now, all you need to know is this is a string that identifies an app developed by your team.

They also contain a list of certificates. Now, earlier, Yevgeny showed you how to generate certificates in Xcode, and these are essentially the public-facing half of each of your developers' identities. Each developer also has a private key, which they should keep to themselves and not share with anybody. That's why it's called a private key. The certificate is the public, shareable half of that, and each provisioning profile you create will contain a list of the developers in your team, essentially.

Finally, a list of device IDs. This is probably the most straightforward one. Every device that your team uses in the development process should be registered on the portal. All of your Macs and iOS devices have hardware IDs. And when you create a provisioning profile, it specifies a list of these.

So what do you get once you put all of these things in a box? Well, essentially, you get a provisioning profile which tells the operating system that an app signed by the following people may run on the following devices. That's essentially the most basic thing a provisioning profile does. It tells the operating system under which circumstances your app can launch.

Now, it does do a couple additional things. Most importantly, it tells the operating system which services your app should have access to, and things like iCloud. And the way it does that is via the app ID. So let's talk about app IDs a little bit. There are two kinds.

The first one is called an explicit app ID. And this is probably the simplest one to understand. It looks just like a bundle identifier. So the one you can see on the screen is com.apple.recipes. That's the bundle identifier for the Recipes app that Yevgeny showed you earlier. And that's an explicit app ID.

It matches one specific application developed by our team. And we can create these on the developer portal. We can make as many as we want. Each explicit app ID needs to be unique. And if you're going to use in-app purchase, game center, or push notifications, you actually have to create one of these on the portal before you can use those.

The other kind of App ID is called a wildcard App ID. And believe it or not, it's called that because at the end of the string is a wildcard character. I'm sure you didn't see that coming. The example you see on the screen, com.apple.*, essentially will match any application developed by our team whose bundle identifier starts with com.apple. So com.apple.recipes would match. com.apple.recipes beta would match. Anything like that.

Now, Xcode creates one of these automatically for you. So you may not actually need to create one yourself. And these tend to be useful when you start developing new apps. You can get off the ground very quickly without having to configure anything on the developer portal. Also, if you're not using any App Store-specific technologies or you're only using iCloud, then you can probably do all of your development using a wildcard app ID. So keep that in mind.

OK, so let's say you've decided you need to create your own app ID. How do you actually do that? So you start by logging into the Developer Portal. This is actually the version for the Mac. The iOS one is very similar. You choose to register a new app ID, and all you have to do is fill in these two fields.

You type in a description so you remember what this app ID is actually for, and you also type in your bundle ID search string, in this case, com.apploadrecipes. So remember this one, because I'm going to actually use this a little bit later. Once you've done that, you can enable your app ID for additional services.

On the Mac, you'll see checkboxes for iCloud, Game Center, and push notifications. Now, this is one difference from iOS. For iOS, if you want to use in-app purchase, you actually have to check a fourth box for that. On the Mac, as long as you're using an explicit app ID, you can use in-app purchase in your application. So in this case, I've enabled iCloud.

So that's all there is to know about App IDs, really. Now, a few other details about provisioning profiles that you should be aware of are that Xcode creates these team provisioning profiles for you. And you've probably seen them. If you're developing for iOS, there's an iOS team provisioning profile. If you're developing for the Mac, there's a Mac team provisioning profile.

These are essentially generic profiles that Xcode creates for you. It maintains them for you. And they'll automatically contain all of the devices and certificates that your team uses. They'll also use a wildcard app ID that matches any app developed by your team. So again, you can use these when you're developing new apps, get off the ground very quickly. And for some apps, this is really all you need.

If you need to create a provisioning profile with an explicit app ID, you can do that in Xcode, and I'll show you how to do that in a little bit. And finally, when it's time to distribute your app on the App Store, you need to use something called a Production Provisioning Profile on the Mac or a Distribution Provisioning Profile on iOS. And again, only your team agent can create and use these.

Now, changing gears a little bit, in-app purchase. In the new version of Xcode, we've added project templates for both Mac and iOS so that you can create in-app purchase content directly in the IDE. All you have to do is create a new project or add a target to an existing project, drag in your resources, and you can archive, package, and submit your in-app purchase content directly from within Xcode. And I'll show you how to do that, actually.

In just a moment, I'll head over to the demo machine and show you a few things, including how to enable iCloud, how to create a provisioning profile, and then how to submit an app and in-app purchase content to the App Store. So let's take a look at that.

So here we are looking at the Recipes app that Yevgeny showed you earlier. Now, what you might not know is that this app uses the iCloud Key Value Store. Now, before I can actually submit this app to the App Store, I need to do a little bit of work in order to enable that. If I look at the debug log from the last time Yevgeny ran the app, you'll see there's a somewhat scary-looking error message. But all it really says is that we haven't enabled iCloud for our app, and we're trying to use iCloud.

So how do we do that? There's a couple steps. I'll go back to the Target Editor and show you the first one. The first step involves turning on the entitlement within our app. And I can do that simply by checking this iCloud Key Value Store checkbox in the Target Editor.

Okay, that's half of what I need to do, and that was pretty easy. Now, the second half actually involves creating a provisioning profile. Now, if you'll recall, there are three things that you need to have in a provisioning profile. One is an app ID. I already created an app ID.

It was the one I showed you in the slide, so that's all done, and it's enabled for iCloud. The second one is a development certificate. Well, Yevgeny created that in his demo, so I already have that. The third one is a device ID, so I need to register my device on the portal before I can create a profile. So let's do that.

You can do that within Xcode's Organizer. I'll click on the Organizer button here in the corner. Click over to the Devices tab and select My Mac in the sidebar. And all I have to do to register my Mac on the portal is click this Add to Portal button on the bottom of the window. Now my Mac has been registered, and I can create a provisioning profile that refers to it. So let's do that.

In order to do that, I can click on the Provisioning Profiles item and click New on the bottom of the window. And now all I have to do to create a profile is fill out this sheet. So I'll type in a name. This should be something descriptive so that you know what this profile is used for, especially if you need to update your app six or 12 months down the line, it's useful to actually know which profile you're using. I'll click on Mac since this is for a Mac app. And now I need to select an app ID. I'll choose the one I created earlier, which is already enabled for iCloud.

And next, I need to choose the list of devices and certificates that I want to include in the profile. Now, if you're on a larger team, of course, you'll see a lot more devices and certificates in this list, and you can select just the ones you want, or you can select all of them. Now, in this case, I'm a one-person team with one device, so I'll just choose everything and click Finish. And you'll see that Xcode has created a profile for me on the portal and downloaded it to my Mac.

In order to use this profile, I need to first install it on my Mac, and I can do that simply by dragging it onto my Mac in the sidebar. And now if I click on Provisioning Profiles under my Mac, you'll see that it's installed. Great, so now it's ready to use. Let's go back to my project and configure it to use my profile.

The way to do that is via the Code Signing Identity build setting that Rob showed you. So I'll click on Build Settings for my target, and let's take a look at the Code Signing Identity build setting. You can see here that the automatic profile selector has actually already chosen the correct identity for me. I want to use my Johnny Appleseed identity, and it's also using my Recipe's development profile, which I just created.

But in case that's not choosing the right thing, you can also see further down in the list that Xcode lists all of the provisioning profiles I have installed, and all of the identities that are included in those provisioning profiles. And I can just choose the one that I want to use.

Now I'm ready to build and run my app, and iCloud should be enabled. So if I go look at the debug log again, We'll see no scary error message this time. Everything is working. OK, so now I'm ready to submit my app to the App Store. Everything looks great. So I'll start by archiving it, just like we did for Developer ID. And the archive will appear in the organizer.

Now, as Rob mentioned, one practice that we really recommend you do is to validate your app before you submit it. And you should do this frequently throughout your development cycle so that you don't get a nasty surprise when it's time to submit your app to the App Store. So let's start off by validating. And I can do that by clicking the Validate button, selecting Mac App Store, and hitting Next. Now, in order to validate, Xcode needs to connect to iTunes Connect and download all of the application records that I've already set up.

So I'll type in my iTunes Connect credentials, hit Next. And now you'll see that Xcode has downloaded all of my application records. If you don't see any here, it might mean that you haven't actually created one yet, so you'll want to go do that. And I can select the code signing identity that I want to sign this with and hit Next. Now, Xcode is going to codesign my application and upload it for validation. And once again, I'm being asked for access because this is the first time I'm using my Mac App Store distribution identity.

So since this is an application developed by some great Apple engineers, there shouldn't be any validation errors, right? But it looks like we do have one. And the important thing to keep in mind when this happens is that this is definitely Yevgeny's fault. So usually what I do at this point is type up an angry email and send it to Yevgeny and his manager. But since I want to actually show you how to submit an app to the App Store, let's go ahead and fix it.

In this case, it looks like we're missing an application category. And this is actually really common. If you're taking a pre-existing app and you want to submit it to the App Store, you might not already have a category set up because you distributed it through your website previously. It's also very easy to fix. So let's click Finish and go back to the project to fix it.

I'll select my project and return to the target summary editor. And you'll see at the very top, there's a pop-up from which you can select a category. So all I have to do is choose the one that looks right, in this case, Lifestyle. and build a new archive because I've modified my application's Info.plist, so I need a new archive. Now I should be ready to submit to the App Store. So to do that, all I do is click Distribute, select Submit to the Mac App Store, and hit Next. Once again, Xcode will want my iTunes Connect credentials.

This is the same as before. Again, if you're not seeing your app record here, you might have forgotten to create it, or you might have forgotten to mark it as ready for upload. I'll hit Next, and now my application again is being codesigned and uploaded to the store. And once this is done, I should see a very nice message that says, "My app has been submitted." So let's just give it a few moments. And there we are. That's how easy it is to submit an app from Xcode.

So that's great. Now my app is available for my customers. I was able to submit it from Xcode very easily. Now I'd like to add some additional value so that my customers enjoy using my app even more and keep coming back. So I can do that by creating in-app purchase content.

And now with the new version of Xcode, I can do it very easily. So let me show you how to do that. I'll go back to my project and hit the Add Target button. When I select Other here under OS X, I'll see that I have a new in-app purchase content template. So all I have to do is hit Next and give it a name.

And click Finish. And now Xcode has created a new target in my project for my in-app purchase content. You'll see we have a custom target summary editor for it, so I can choose to rename my in-app purchase content if I'd like, change its identifier, or change its content version. I can also drag some additional files into this group that's been created in my project. But in this case, I think this is all I need to do. So I'll go ahead and archive and submit this to the store.

The first thing I need to do in order to do that is to select the correct scheme. When I added the target to my project, Xcode added a new scheme for me. So I'll choose that and Archive. The archive appears in the organizer. I can click Distribute, choose Submit In-App Purchase Content, click Next.

Again, Xcode needs to log into iTunes Connect and download any records that I've created because there's a separate type of record for in-app purchase content. So you can see here my application record is listed, and the record I created for my in-app purchase content is available. And now all I have to do is click Next, and Xcode will upload my content to the App Store.

That's all you have to do to submit in-app purchase content now. You can do it all from within Xcode. And we're done. So now we've shown you how to distribute applications outside of the App Store and in the App Store, and I'd like to invite my colleague, Rob Marin, back onto the stage to show you some iOS application best practices.

Thanks, Itai. So most of what we just showed you applies equally to iOS and to Mac OS X. But right now, we're going to focus exclusively on iOS, beginning with a new feature in the App Store for iOS 6, Application Deltas. This is something that we've actually had in the Mac App Store since Lion. In fact, earlier this week, we released an update to Xcode 4.3 that was just 97 megabytes.

Gone are the days of needing to download 4-gigabyte installers just to get an updated SDK. Application Update Deltas are fantastic from the perspective of your customers. The good news is they're also fantastic for you. Deltas are generated from your application based on each file's contents, and they're managed entirely by the store.

It keeps track of which versions to publish, which ones to give to your customers based on what versions of the apps they have installed, and the store takes care of generating them for you. All you need to do is submit your application as normal. But there are some things you can do to make sure your application update delta is as small as possible.

For instance, if you were to change the name of a file, the entire file would be included in the delta. If you were to change the name of a directory, the entire directory's contents would be included in the delta, and it would take that much longer for your customers to download the update. And if you were to change your application's name on disk, all of the application's contents would end up in the delta, which would probably lead to some unhappy customers.

But that only really applies once you're ready to submit an update to the store. How do you actually know you're ready to go live with your update? For that, we have a process we call ad hoc distribution, which most commonly is used for producing a beta of your application to provide to your customers to test. A lot of you work in small teams, maybe one or two people, and you don't have a dedicated quality staff.

Doing a beta test allows you to make sure that the customers that matter to you are satisfied with the state of your application's quality. It lets you interact directly with them, obtain feedback, and respond to them in a rapid fashion. And it lets your customers feel like they're directly influencing the direction of your product. And as a bonus, it lets you, before your app actually goes live on the store, identify what the weak points and strong points of it are so you can start planning your next update.

So today we're going to talk about some best practices for doing this. And it's important to know that we don't want to do a lot of work. We have fantastic tools, and we want Xcode to do the work for us. So we're going to explore how to take advantage of the Xcode build system to set up our application beta. And then we're going to talk about how to get our beta into our customers' hands easily and quickly.

So, specifically, we have some goals. The first is we want our application to coexist on our customers' devices alongside the version shipping in the store. And to do that, we're going to take advantage of the app's bundle ID. As it turns out, iOS devices unique installed applications on the home screen via the bundle ID. So we're going to provide a different one for our beta application.

Second, we want our beta to be something that can be quickly identified alongside our shipping application by our customers. So to do that, we're going to provide a separate icon. And keeping in mind our earlier goal of doing less, we want Xcode to figure out which one to produce for us.

And then, of course, we actually want our customers to test our product. So we want to make sure we can provide them with our application in a way that they can quickly and easily install wirelessly. And in fact, you can do that from Xcode. Once you've produced an archive of your application, you can distribute it in a way that allows you to save it for what we call ad hoc or enterprise deployment.

And when you do this, you'll be prompted to provide some additional information to Xcode, and it can produce one of these installer manifests for you. The things you'll need are a URL where you plan to host the .IPA file that Xcode will save out, as well as the title of your app. And then you can give it some artwork or some additional text, and it'll show that when it provides the installer UI on the device.

And once you save this out, Xcode will give you not only your IPA, but a property list file that's pretty short. It looks something like this. And for those of you who like to view your property list in the source code editor, it would look like this. And if you were to host this on a website alongside the .IPA, if you browse to it in Safari, and your application-- and your device, rather-- is listed in the provisioning profile for your application, your device will offer to install it. It's great.

So now, I think I'm going to show you how to do that. So I'm going to go ahead and close this because I'm working on an iOS app, and I'm hoping Yevgeny hasn't touched it. So I have a copy of it here, and I'm going to go ahead and open it.

And since I know that you really don't want to see me type, I've gone ahead and written out some text already that I'm going to use. Specifically, if I take a look at my project in the project editor, I'm taking advantage of a feature of Xcode called Configurations. I've created a new configuration for my application called a beta.

And I did so by just hitting this plus button. And what I would like to do is tell Xcode that when I'm building for the beta configuration, I want to take certain things into account, and those things are build system settings. So I've defined those in my target.

And if I go to the Build Settings Editor, I'm gonna hide this inspector, go to the bottom, you can see I've defined two build settings in the User Defined section, one of which is recipe_bundle_id_suffix, because build systems really like underbars. And I've provided a value for that only for the beta configuration, which is .beta, And this is going to allow me to provide the Xcode build system the context that says, when this string appears in something that we're going to preprocess, replace it with .beta. And similarly, I specified one for my recipe icon name.

And in my project, I actually have Two icons, one of which is recipe, and one of which is recipe beta. So where we're going to use these build settings is in our Applications Info.plist. So for the bundle identifier, I've actually-- At the end of the string, appended RecipeBundleID suffix.

And for our icon, I've specified recipe icon name suffix. Now, when I build my application as normal for debug or release, those two build settings are going to evaluate to an empty string and everything will be left alone. But when I build it for the beta setting, they'll actually be real values. So I'm going to go ahead and actually build my application for the simulator in its normal configuration to show you what it looks like, just to, you know, make sure there's no tricks here.

Here's the app, and if I go to the home screen, there it is. As you can see, it's the standard application, standard icon. So what I'd like to do now is to actually provide the iPhone simulator the beta configuration of it. So to do that, I'm going to manage my schemes, and I'll actually duplicate this recipe scheme.

And what I want to do is tell it, when I'm building, use the beta configuration. And similarly, I want to provide this to my customers. So when I'm archiving, use the beta configuration. I'll hit OK. And now I'm going to run again on the iPhone simulator. My application is still running, so I'll stop that. And now I'll run again on the iPhone simulator. And here we are. Here's the application.

If I hit the Home button, you can see, there it is alongside our regular version. It has the new icon. Great. So now I want to provide it to my customers. So I'm going to archive this application, but before I do that, I want to actually provide them with a device version, so I'll choose that as our active device. And now I'll archive the application.

Now Xcode is going to show me this inside of the Xcode Organizer. And I can distribute it in the same fashion as we've been seeing all day. But I can distribute it for enterprise or ad hoc deployment. And if I choose that, Xcode asks me for a code-signing identity. My secret alias is actually Johnny Appleseed, so I'll hit Next.

And when it's done, it's going to prompt me to save this somewhere. And I'm going to choose this Save for Enterprise Distribution flag. And at this point, I'm going to tell Xcode where my IPA is going to be hosted. Since those recipes look pretty good naturally, this will be right on apple.com.

Typing on stage is a lot harder than it might seem. Interesting fact about WWDC. And then I'll give it a title. So now I've chosen to save out an IPA of my app to my desktop along with this install manifest, which is a property list that contains the URL to the IPA. So I'll go ahead and save that. And if I go back to Finder and take a look on my desktop, there's the IPA and there's the property list. And I'll open that next code for a second, and you can just see what its contents are.

And if I put this property list on a web server, as I said, and browse through it with the device, it'll prompt me to install. I'm going to go ahead and close that. Now we'll switch back to slides. So let's talk about what we went over today. First, how to distribute your application outside of the App Store in a way that ensures that it's available to your customers running Mountain Lion, as well as providing them with a sense of security and confidence in the quality of your application and its security. We also talked about how to take advantage of technologies available through the Mac App Store and how to submit your application to the Mac App Store and the iOS App Store.

And in iOS, we talked about how to provide your customers with a pre-release copy of your application distributed ad hoc in the form of a beta, as well as some new features in the App Store in the form of deltas and how to make sure that your delta is as small as possible.

For more information, please feel free to contact Michael Jurowicz, our evangelist. You've probably seen him around this week. He's the guy in the suit with the big camera. There's also some documentation in the form of the Tools Workflow Guides for Mac and for iOS. And if you have any questions, we're available on the dev forums.

If you're interested in the OS X application sandbox or taking advantage of Gatekeeper and Developer ID, there were some sessions about that earlier in the week. It'll be available on video. There's also a session on how to take advantage of some new features in iTunes Connect for those of you managing a lot of in-app purchase content. Thank you.