Building, Archiving, and Submitting Your App 

Session 414 WWDC 2012

Xcode has significantly improved workflows to help you build, package, and prepare your application for distribution. Discover the best practices for handing your iOS and OS X application to beta testers, see how to validate your app bundle and submit it to the App Store, and get ready for Gatekeeper by learning how to sign your Mac application with Developer ID.

Rob: 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. We thought that this afternoon we would do something completely different and talk about distribution, how you can get your software product into your customer’s hands.

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. 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.

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. We don’t think that should be something that you can only take advantage of in the app store. 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. 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. 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’s systems and that’s bad.

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 they 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. What is it?

A Developer ID identifies you as being someone who’s trusted by Apple. By virtue of the fact that you’re trusted by Apple, the OS trusts you and your software can run freely. Unlike other technologies and for distribution it has built-in support in Xcode so you can share your application with your customers right from the IDA.

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 previously had experienced 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. 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 we’ll say yes. Once you do, it’ll ask if you want to export them. 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. It’s important to make sure you have a copy of it somewhere that’s kept safe and secure.

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.

Once you’ve got that, you can take a look at what you’ve actually obtained. These are the identities that are associated with your team. They come in, for Mac developers, two categories, those that begin with Mac which you would use for your Mac app store submissions, and those that begin with Developer ID which is what I’m going to talk about right now.

There are two flavors: Developer ID application, this is an identity that you use to sign your data .apps, either that you distribute in an archive or on a disc image; and then Developer ID installer which is what you use to sign the installer that’s used to give your customers their .apps.

It’s important to realize this because installers are actually executable code so there’s a possibility for tampering there. It’s important to make sure that that’s signed. 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 code signing your application during development and working with and under the bugger.

Similarly, code signed applications are treated differently by the OS in a few circumstances like when they actually are launched. It’s often useful to profile your application as if it was code signed.

To actually produce this, what you can do is go to your project editor and the summary panel offers you the option to code sign the application. Checking this box will cause the Xcode to automatically select the appropriate identity for your application. Usually this is correct. However, if you’re in 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 signing 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. This is a really fundamental and powerful feature that we introduce 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. 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.

Once we’ve created one of these archives which we’re going to show you how to do in a minute, you can chose to distribute it. To distribute it in this case we’re going to choose to distribute it as a Developer ID signed application. Once we do, we’re prompted to save it some place on the file system and then we can distribute it to our customers however we chose.

That’s one security feature that’s available to customers of the Mac app store. As I said earlier, we don’t want those to be features that are unique to the store. 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.

Yevgeny: Good afternoon. As Mac and iOS users, we love to brag that our platforms are really secure. As developers, we really want to make sure that our products don’t contain any security vulnerabilities on these platforms. 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. You can’t access the user’s personal data like contacts, calendars, and location services.

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.

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 in 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 a system like the microphone or location services. In this way, you can take advantage of the principle of least privilege meaning that your app only has permission what it needs to do in order to get its job done and it’s not allowed to touch anything else.

You can take advantage of entitlements in Xcode just as easily by going back to the target editor. When you enable sandboxing, you’ll notice that there are checkboxes and dropdowns to select which entitlements your app wants to use. Once you make those changes, then Xcode will create a property list file called the entitlements file. It’ll populate it with those cues 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. That’s how easy it is to add a whole layer of security into your app.

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.

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. Let’s say we’ve already got an app that’s prebuilt. My app happens to be a recipe viewer. I want to open the app and take a quick look at it. We’ll go ahead and run it. There it is.

On my left here I’ve got a side bar with all of my recipes. 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. This app looks great to me. I want to package it up and I want to ship it to developers. Right away, there are already a couple of problems with this.

If I take the app that Xcode just built, I put it on a website and have people download it, then anybody can download it and modify. 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 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 in older systems that says “This app has been downloaded from the internet. Are you sure you want to launch it?” Most users will end up clicking “Yes.” On Mountain Lion, we’ve gotten more strict with Gatekeeper. Your second problem is that by default, if a user tries to launch an app on Mountain Lion, the system just won’t let it run. It’ll deny it. It’ll pop up a panel that Rob showed you.

That’s great news from a security standpoint but it’s not so great from usability standpoint. What’s the solution? Well, you just have to use Developer IDs on your app. I want to show you how to use Developer ID right now. Let’s close up our app.

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. Let’s say you’ve already got one.

Now what you can do is go to the editor menu and click refresh from developer portal. You sign in. Save your password. Then Xcode will connect to the portal and check for which developer identities you’re eligible. 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.

There are a few different kinds of developer identities. 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.

Xcode here is asking me once for each type of identity. I’m just going to go ahead and say yes. Submit the request. Once that’s done, Xcode is being really helpful here and offering to export my developer profile. 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 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 start up a new Developer ID. You won’t have access to your old one. You won’t be able to your old one. You won’t be able to submit new apps under it. It’ll be painful for both you and your customers.

We really want to stress that you should export your profile and keep it safe and secure. I’m going to do this now. I’d 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 in the app store that you can and that’s bad. Here’s it’s saved on my desktop.

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. Under developer profile, choose export developer profile. 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 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 check mark 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 this situation where none of your identities have a badge. 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. As soon as you take that code and download it to another machine, you could forget to move your private key onto it. 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.

Anyway, let’s get back to our app. We now have our Developer ID. It’s been downloaded. We could, if we wanted to, sign the app with it and distribute it. If we did that, we’d be releasing a product that’s not been tested. It’s a different product than we’ve been developing because a Developer ID will sign your app. It’ll code sign your binary whereas by default, your development binary will not be code signed. To the system, these appear different. When you’re testing, debugging, and developing, you really want to be running the same thing you’re going to be shipping. We suggest that you enable code signing while you’re developing.

You can do that in the next code by going to your target editor summary pane and clicking on code sign application. 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 everyday we’re seeing users being more concerned about security. They expect that developers will be taking these concerns very seriously, that they are protecting their date a hundred percent of the time. As I mentioned, sandboxing is a great way to add a whole layer to add security to your app. We strongly encourage all of you to enable it. 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. Also notice that the entitlements file has been created for us in the project navigator. I can click on it and examine its contents. Here I see it’s just an ordinary property list. It’s got the key for sandboxing already in there. I go back to my target editor. I notice that there are all these options for entitlements.

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. 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. I can do that by clicking the appropriate check boxes. 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. Now it’s totally ready to be shipped.

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. It’ll appear in my organizer. I can now click distribute. 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. If it doesn’t appear here, just click refresh Developer ID. Finally, on the next page, I’ll be able to save it. Before I save it, Xcode actually needs to code sign my binary with the private key that I’m using. 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. I’m going to go ahead and allow Xcode to use it.

We save the app to our desktop. There it is. It’s ready to go. It’s fully signed and fully authenticated. People can go and download it and feel really safe and secure. That’s how easy it is to distribute an app using Developer ID.

Now I’d like to invite my colleague Rob back to talk about how to distribute an people using the Mac app store.

Rob: That’s how to distribute an application outside of the App Store. 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 Push Notification Service for responding to things happening while your application is running, and Game Center so that if you have a game your customers can actually play with their friends regardless of where they are, and in that purchase if you 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 everyday. While Gatekeeper works out of the box for applications distributed through the app store were signed with Developer ID, users of the OS can actually tighten the security threshold and say, “I only want applications that are coming from the Mac app store.” Distributing here is the way to guarantee that your software will run on all of your customers’ systems.

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 an application in the portal; sandboxing and some entitlements that we use for app store’s 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 CF bundle identifier key. By convention, it’s something that we wanted unique throughout the system. A lot of our APIs expect that. It should match your app ID that you created in your provisioning profile.

If you have an application that you distribute outside the app store and have turned down 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. When we go back and think about the technologies that are available to our customers through the app store, one of them is iCloud. There are some entitlements you can set up for that for using either the key value store or for custom document and data containers.

Submitting your app is something that you want to take seriously. It will 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. Xcode has a workflow to help you make sure that that’s the case. 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, and 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.

We actually update these over the web to make sure that they are exactly what you will be tested against once you submit. 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. You can choose to validate against the Mac app store’s requirements. 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, 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.

Itai: Thanks, Rob. 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. If you take advantage of them in your apps, then customers will love your apps even more than they already do. Before I move on, I 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.

Here is a brief overview of what I’ll be talking about. Now when you set down a path of building an app store app, one of the things you should know about is provisioning profiles. 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 ID. If you’ve used in-app purchase before, you’ll find this greatly streamlines your workflow.

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. 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 developing engineers or testers on your team. People who are assigned the member role can download provisioning profiles, request certificates, and also obtain software assets like pre-release of the case and beta releases of the tools.

If you think of your team with the 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’ll 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 developing program. Most importantly, they’re also the only individuals 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. You want to make sure that only responsible individuals can actually do this.

What is a provisioning profile? Now this is a great topic to talk about just before the beer bash. I take no responsibility if this drives you to over-indulge tonight. I’m going to try to make provisioning profiles as simple to understand as possible. They’re really not that complicated. I like to think of a provisioning profile as a big blue box. Okay. 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. 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.

Earlier, Yevgeny showed you how to generate certificates in Xcode, and these are essentially the public-facing half of each of your developer’s 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 developer’s inner team, essentially. Finally, a list of device ideas. 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 provision profile, it specifies a list of these. What do you get once you put all of these in a box?

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 you’re app can launch. 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 we have the app ID. 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. The one you could see on the screen is That’s the bundle identifier for the recipes up that Yevgeny showed you earlier. 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 could 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 screen is the Wildcard character. I’m sure you didn’t see that coming. The example you see on the screen* essentially will match any application developed by our team whose bundle identifiers starts with, so would match. beta would match, anything like that.

Xcode creates one of these automatically for you. 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. Keep that in mind. Okay, let’s say you’ve decided you need to create your own app ID, how do you actually do that? 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 the description so you remember what this app ID is actually for, and you also type in your bundle ID search string. In this case, 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. 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 an app purchase in your application. In this case, I’ve enabled iCloud. That’s all there is to know about app IDs, really. 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. 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 provision 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.

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 ID. 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 a thin 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. Let’s take a look at that.

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. 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 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 app and we’re trying to use iCloud. 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 check box in the target editor. That’s half of what I need to do and that was pretty easy. Now, the second half actually involves creating a provisioning profile. 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 slides. That’s all done, and it’s enabled for iCloud. The second one is a development certificate. Yevgeny created that in his demo so I already have that. The third one is a device ID. I need to register my device on the portal before I can create a profile. Let’s do that.

You can do that within Xcode’s organizer. I’ll click on the organizer button here on the corner, click over to the device’s tab, and select My Mac in the side bar, and all I have to do to register My Mac on the portal is click this at the portal button on the one with 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 profile’s item, and click New on the bottom of the window. Now, all I have to do to create a profile is fill out this sheet. 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 Mac ID. I’ll choose the one I created earlier which is already enabled for iCloud. Next, I need to choose the list of devices and certificates that I want to include in the profile. Now, if you’re in 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. In this case, I’m a one person team with one device, so I’ll just choose everything and click Finish. You’ll see that Xcode has created a profile for me on the portal, and download 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 on to my Mac in the sidebar, and now if I click on provisioning profiles under my Mac, you’ll see that it’s installed.

Great, now it’s ready to be used. Let’s go back to my project and configure it to use my profile. The way to do that is we had the code signing identity Build Setting that Rob showed you. 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 Recipes 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 the provisioning profiles that I’ve 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. An iCloud should be enabled. If I go look at the Debug Log again, you’ll see no scary error message this time, everything is working. Okay, 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. As Rob mentioned, one practice that we really recommend you to 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.

Let’s start off by validating, and I can do that by clicking the Validate button, selecting Mac App Store, and hitting next. In order to validate, Xcode needs to connect to iTunes Connect and download all of the application records that I’ve already set up. 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. You 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 code sign 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. 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. 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. 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. 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 P list so I need a new archive. Now I should be ready to submit to the App Store. To do that, all I do is click distribute, select submit to the Mac App Store, 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 code signed and uploaded to the store, and once this is done, I should see a very nice message that says my app has been submitted. Let’s just give it a few moments, and there we are. That’s how easy it is to submit an app from Xcode.

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 values so that my customers enjoy using my app even more and keep coming back. I can do that by creating In-App Purchase Content, and now with the new version of Xcode, I can do it very easily. 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. 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 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. 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 in to iTunes Connect and download any records that I’ve created because there’s a separate type of record for In-App Purchase Content. You can see here, my application record is listed, and the record I created for my In-App Purchase Content is available.

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 a thin Xcode and we’re done. 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 Marini back on to the stage to show you some iOS Application Best Practices.

Rob: Thanks, Itai. 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 the 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 and which ones to give to your customers based on what version 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’s 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 the directory, the entire directory’s contents would be included in the delta and would take that much longer for your customers to download the update, and if you were to change your application’s name on disc, all of the application’s contents would end up in the delta, which will probably lead to some unhappy customers.

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.

As a bonus, it lets you … before your app actually goes live on the store, identify what’s the weak points and strong points of it are so you can start planning your next update. 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. 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 customer’s hands easily and quickly. Specifically, we have some goals. The first is we want our application to co-exist on our customer’s devices alongside the version chipping in the store, and to do that, we’re going to take advantage of the app’s bundle ID.

As it turns out, iOS device’s unique installed applications on the home screen via the bundle ID. We’re going 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. 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. 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 sure to look something like this, and for those of you who like to do their 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 through it in Safari, and your device is listed in the provisioning profile for you application, your device will offer to install it. It’s great.

Now, I think I’m going to show you how to do that. I’m going ahead and close this because I’m working on an iOS app, and I’m hoping Yevgeny hasn’t touched it. I have a copy of it here and I’m going ahead and open it, and since I know that you really don’t want to see me type, I’ve done 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 from 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 building for the beta configuration, I want to take certain things into account, and those things are Build System Settings. I’ve defined those in my target, and if I go to the Build Settings editor, I’m going to 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.

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 pre-process, replace it with .beta, and similarly, I specified one from 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. Where we’re going to use these Build Settings is in our applications in [inaudible 00:51:20] list. For the bundle identifier, I’ve actually … at the end of this string, up ended Recipe bundle ID suffix, and for our icon, I specified Recipe icon name suffix.

Now, when I build my application as normal 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. I’m going to go ahead and actually build my application for this simulator in its normal configuration to show you what it looks like, to 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. What I like to do now is to actually provide the iPhone simulator the beta configuration of it.

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 what I’m building is the beta configuration, and similarly, I want to provide this to my customers. When I’m archiving, use the beta configuration, 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, hit the Home button, you can see, there it is alongside a regular version has the new icon. Great. Now I want to provide it to my customers. I’m going to archive this application, but before I do that, I want to actually provide them with the 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 is will be right on, typing on stage is a lot harder than it might seem. Interesting fact about WWDC, and then I’ll give it a title.

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. 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. I’ll open that next code for a second, and you could just see what its contents are, and if I put this property list on a web server as I said, and browsed it with a device, it will prompt me to install. I’m going to go ahead and close that. Now we’ll switch back to slides. 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-released 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 Jurewitz, 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 would 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.

Apple, Inc. AAPL
1 Infinite Loop Cupertino CA 95014 US