Good morning, everyone. How are you today? Welcome to session 417, Managing the iPhone Development Process. My name is Nitin Mishra and I work in the iPhone Developer Programs. And today, we're going to take a step back from the code and we're going to talk about the various processes, tools, and Web Portals that you're going to be interacting with during our iPhone development process. For those of you who are new to iPhone Development, we're going to walk you through the steps from taking your idea, getting it installed in the Simulator, and installing it on a device, and the very steps incorporated with that.

And then, building it for distribution to the App Store. For some of you who may already have some experience with that process, we're going to talk to you a little bit more about the different tools and processes that are available to you to help refine your applications and make more powerful updates.

And so, we'll be covering different processes that you can do. And lastly, for those of you who are savvy with the iPhone Development Process, we're going to talk to you about four new feature in iPhone OS 3.0 and the different processes you're going to have to engage in with the iPhone Developer Program Portal in order to get these features working on your device. So, a roadmap for today will be covering the following six steps.

The first, setting up your Development Team, then we'll go into building and installing your development applications and best practices for it. After that, we'll talk a little bit more about iPhone OS 3.0 features. And then, we'll step into refining you application and delivering powerful updates. And then lastly, we'll cover preparing your application for distribution in the App Store and then finally, submitting your application to the App Store.

So, the iPhone Developer universe or solar system, as I pointed out, is a, it all revolves around free iPhone SDK. And with that, you're able to develop your applications in the Simulator, really testing it, get a feel for the code and then when you're ready to take the next step, you'll be interacting with the iPhone Developer Program Portal and then iTunes Connect, which is what your interface is to the App Store. After you've gotten your application running on the Simulator and you're ready to take that next step in your development process and start debugging and testing your applications on a device, you're going to need to be in the iPhone Developer Program.

And, by enrolling in that program, you'll get access to the iPhone Developer Program Portal. This is what you'll use to obtain the various assets, certificates, provisions, that you'll need to get your application running on the device and then get your application uploaded to the App Store. So, a lot of you might be asking why do I need to enroll in a program? If I can get the SDK for free, why should I have to enroll in a program to get it running on my own device? And the simple answer to this is really about trust. All applications that run on the iPhone are signed by Apple and therefore, the device inherently trusts them.

In order to get your applications installed on a device, you're going to need a gateway into getting your application inherently signed by Apple as well. And, once you've done this, this verifies your identity to the world, that Apple trusts you as a developer. For example, you wouldn't want another company distributing their applications and installing them in devices under your name. So, going through this process ensures that our shared customers all know that this application is coming from you, it's been trusted by Apple and that the device happily accepts running it.

To get your application running on a device, you only need two things from Apple. The first is a Signing Certificate, which is ultimately approved by Apple and chained to the Apple Root and you use this to sign your application. The second piece you'll need then, is a Provisioning Profile. A Provisioning Profile is essentially a key, which unlocks your device and allows your application to run on it. The profile itself is also signed by Apple so these two pieces, in connection, allow you to build and install your applications.

Now, let's cover the iPhone Developer Program Portal. In it, there's 5 steps which you're going to be engaging in, which is setting up your iPhone Development Team, obtaining these code Signing Certificates, setting up an App ID or an identifier for your application, and then, assigning your devices, which you've targeted for development. And lastly, the Provisioning Profile, which you will use to ultimately build and install your application.

So let's start with Teams. For those of you enrolled in the iPhone Developer Program, as either a company or as, a company in the Standard or Enterprise Program, you can assign 3 different levels of team responsibility. The first level is the Team Member. A Team Member only has 2 functions in the Program Portal.

They can download a Code Signing Certificate and download a Provisioning Profile. Now, a Team Member is usually someone, you primary developer in your company and you want them focused on the coding, getting the device up, and running, or getting the application up and running, and really making sure it's great. So they only really need this level of responsibility.

They don't want to interact with the portal too much, they don't really need to. The second level of responsibility is the Team Admin. A Team Admin has the responsibilities of the Team Member, but in addition, they can approve certificate requests from anybody on the team as well as create and approve Provisioning Profiles.

So a Team Admin would essentially be a Team Lead, who's kind of managing a group and they can kind of handle the management of the certificates and the provisions. And the last level of responsibility is the Team Agent. The Team Agent is person who originally enrolled in the program. They're the primary contact for your team and they're the ones who were accepted and verified by Apple and who are the ultimate trusted authority.

In addition to the above responsibilities of the Team Admin and the Team Member, the Team Agent is the lone person on the Team who can create and download the Distribution Certificate, which is used to build your application when you're ready to upload it to the App Store, the Distribution Provisioning Profile, as well as Push Notification Certificates for those of you who are ready to start using the Apple Push Notification Service.

And lastly, the Team Agent is the person who's ultimately responsible for signing all the legal contracts, whether it be in iTunes or the different program license agreements for the iPhone Developer Program. So, from that, let's move on to Certificates. There are 4 different types of certificates which you can obtain in the iPhone Developer Program Portal and all of them are rooted to the Apple Root Certificate.

There are very few Root Certificates in the world for those of you who are familiar with it and the Apple Root Certificate is ultimately, what is trusted by the iPhone iPod Touch, Mac OS X and as was, the iPhone Developer Program Portal. Hanging off that Apple Root Certificate is the World Wide Developer Relations Intermediate Certificate.

This is issued by the Apple Root and this is actually, what issues all your iPhone Development Certificates, which include your iPhone Development Code Signing Certificate, which is what you use to sign Development Applications when you're in the testing, designing, debugging phase. It issues the iPhone Distribution Code Signing Certificate, which is very similar to the Development Certificate in functionality, but it's the only certificate that is accepted by the App Store when you're ready to upload your application. The last two certificates are for the Push Notification Service.

The World Wide Developer Relations Intermediate Certificate Authority issues your Development Client SSL Certificate, which is used to connect your Notification Server to the Apple Push Notification Sandbox Service. This is when you're just playing around with Push Notifications, trying to get it to run on your development devices. And lastly, the Push Notification Production SSL Certificate.

This is what you're going to install on your Production Notification Servers and what is ultimately going to send all the notifications to the millions of devices that are available on the App Store, applications on the App Store, pardon me. To request all of these certificates, there's only, it's the same process. You're going to utilize the Certificate Assistant, which comes with every Mac OS X system. So let's take a little closer look at how you go through requesting these certificates.

The first thing you're going to do is launch the Keychain Access application, which is found in your Utilities folder in Applications. On the new Mac, you'll see it's blank here and that there's no certificates requested. But, what you're going to do is in the New File Menu, you're going to request a certificate from a certificate authority, that being the World Wide Developer Relations Intermediate Certificate, the Certificate Authority we just discussed. From there, you'll be prompted to enter the name of your Private Key as well as specify how you want to send the certificate sign in request to Apple.

In this case, we're just going to save it to the disk and manually upload it via iPhone Developer Program Portal. You'll save the file to your desktop and then navigate to Safari, where you'll go to the Developer Program Portal. This is available in the iPhone Dev Center. It'll be a link on the right and for those of you enrolled in the program, you'll see a link to the program portal.

In the Certificate section of the portal is where you'll actually navigate to it and click the Request Certificate button. You'll go through the process of these instructions, which you just went through, and you'll upload the Certificate Signing Request file you just created to the portal. Once clicking Submit, it will be routed to the appropriate person to approve the Certificate Request.

In this particular case, the user is also an Admin on the Team, so can approve the Certificate Signing Request. If you're a Team Member uploading your Certificate Request, you'll need to wait for an Admin or the Team Agent to approve the certificate for you before it's available for download.

After approving the certificate, it's available within seconds to whoever, to all the users on the Team. Now, what happens after downloading the certificate? You'll get it from the portal as a .CER file and the next step you'll take is to double-click on the file, and it will open again, the Keychain Access application, which we were just talking about. Now, to reiterate what we were talking about before, about the chain of trust and how the application has to root back to the Apple Certificate, you'll see that in your System Root Keychain, you'll see the Apple Root CA, or Apple Root Certificate.

It comes with every Mac system. In your System Keychain now, you'll find the World Wide Developer Relations Intermediate Certificate. This is installed automatically whenever you install the iPhone SDK. And lastly, once you've double-clicked it, your iPhone Developer Certificate, you'll see this in your Keychain and your login Keychain. Now, you'll notice the difference here is that in this particular Keychain, I have both the public and private key for my certificate. Both of these are necessary in order to sign your code and your application.

The Apple Private Key as well as the World Wide Developer Relations Intermediate Private Key will not be available to you. But, the private key needs to be installed in order for you to sign your application. If you're on a different Mac than the one in which you've requested your certificate, you will be unable to sign your application. You can actually export the keys from Mac to Mac, but the private key is unique to you and it's used to identify your identity and you are the person who is actually signing the application.

So if you are interested in Code Signing and learning a little bit more about the private public key and the cryptology behind it, there was an Assigning Your Application an Identity with Code Signing session earlier this week. Obviously, you're not going to be able to attend it now, but when these sessions are available on video, it will be a good resource for you to go learn a little bit more about the science behind it. So, let's move on to devices.

Devices are needed to, you need to input your devices into the iPhone Developer Program Portal because it identifies to Apple that you, the developer, are using this specific device or set of devices for development purposes. Every iPhone and iPod Touch, as it rolls off the factory line, is assigned a unique Device Identifier, or UDID. It's a 40 character string and its unique to your specific device and there's no other one in the world.

The UDID is what actually needs to be input into the Program Portal in order to allow your device to be associated with the Provisioning Profiles and allow you to ultimately install your applications on these specific devices. You can find it in 3 different places, on 3 different applications. The first thing, iTunes, as you can see, the identifier string here is your device identifier and you can copy it straight from iTunes right into the portal. The second place you'll find it is the Xcode Organizer Window.

Again, it's the identifier string, and is unique across all devices and it's the same string that you would find in iTunes. And the third place is the iPhone Configuration Utility, which is a free application available from Apple, which is an intermediate between Xcode and iTunes and it's very helpful for iPhone Development and it's also obtained there.

So, let us move onto App IDs. App IDs are a unique string, which identifies your application or suite of applications to the world. It's similar to a UDID for a device, but this identifies your application. It consists of 2 parts; an App ID Prefix, which is a unique, 10 digit, random string generated by Apple, as well as a Bundle Identifier.

The Bundle Identifier can be anything you wish. It's defined by you, the developer, and it's most common to put the reverse DNS string in place of it. However, you can also put a Wildcard character in here, which allows you to use the same App ID to build all of your applications.

In this case, that Wildcard character would be an asterisk. So let's talk a little bit more about this Wildcard versus Explicit App IDs and why you would want to use one or the other. A Wildcard App ID again, consists of the 10 digit unique string generated by Apple, followed by an asterisk. What I'm able to do with this is use it and build one single Provisioning Profile. From there, I can use that same Provisioning Profile to build all 3 of my applications, or 3 to infinite applications of course.

This is very, very helpful when you're just getting started out. And for those of you brand new to the iPhone Developer Program, you'll notice that there's a Provisioning Assistant which guides you through all of these steps. And in it, it actually creates a Wildcard App ID. This way, you can use the same single item to build all your applications, you can build all of the sample code available in the Reference Library and you can really, just kind of play around and get a feel for how everything's working together. On the other hand, you could have Explicit App IDs.

Now, your Explicit App ID is again going to be that unique, 10-digit string, but then it's followed by the CF Bundle Identifier of your application. In this particular case, when using Explicit App IDs, you'll actually have to build a separate Provisioning Profile for each application that you're working on because each Provisioning Profile will contain a single App ID. From there, you would use those 3 Provisioning Profiles and you'd select between them in Xcode in order to build your 3 applications.

Now, why would you want to use a Explicit App ID? It seems much easier just to use a Wildcard App ID to use everything. And, there's 2 reasons for this. The first, security. For those of you who might be in-house developers, or using Provisioning to Beta test your application with Ad Hoc Distribution, an Explicit App ID uniquely ties this Single Provisioning Profile to a single application.

If you're developing a bunch of applications that you don't necessarily want to be getting spread around, you would use an Explicit App ID to tie, to make a one to one correlation between your 2, between your application and your Provision. It's primarily, a security measure, but it is very good for keep a tighter control over your applications and their distribution. The second reason you'd want to use an Explicit App ID though, is to utilize the features in iPhone OS 3.0.

We're going to talk a little bit more about that later, but keep that in mind and that's why you really want to identify your applications uniquely. So, the last step in this process in the iPhone Developer Program Portal is to create this Provisioning Profile. The Provisioning Profile which unlocks your device and allows you to install either your single or multiple applications on your device.

The Provisioning Profile itself is going to consist of a set iPhone Development Certificates. Now, this can be a single certificate for an individual user, as well as up to all the certificates for your Team Members. It allows you to pick and chose who can sign the applications and who do you want to be able to install the applications. The second piece of the Provisioning Profile is going to be the devices, which we entered earlier.

The devices themselves, this will limit, if the unique device identifier is not in the Provisioning Profile, Xcode will not allow the installation of the application on that device. And the third piece of these Provisioning Profiles is the App ID. Again, a Wildcard App ID for single use with multiple applications, an Explicit App ID for a one to one correlation between your Provision and your application.

All these 3 items go into the Single Provisioning Profile, which is then installed on both your Mac and your iPhone. So, let's move on. We've gotten the Provisioning Profile ready. We've gotten our certificates. So now, you're ready to build and go and get your applications installed on a device. To do this, we're going to go through a demo here, through the Portal and then into Xcode.

So let me switch over to the demo machine here. So, what I'm going to do is first log into the program portal and kind of go through these basic steps we went through just now. Show you how they work in action. So, I'll log into the iPhone Developer Center and here we go.

So as you can see I'm first logged into the Dev Center where I can obtain the free SDK, as well as read the countless amounts of documentation, getting started videos which walk you through the features, the APIs of frameworks as well as access to the 3.0 Beta and GM seed. On the right hand Nav I see a link here to the iPhone Developer Program Portal and here's the main Home screen that you'll be interacting with. Now, as you can see, as I discussed earlier, there is the iPhone Developer Provisioning Assistant.

This'll actually walk you through, step-by-step, all the steps that we just went through, including creating new certificate, assigning your device, creating an App ID and creating the provision. So this is very, very handy if you're just getting started right out of the box, trying to get some applications installed on your device. In the Team section, I'll see that I'm here logged in as the team agent and I've got one team member, Clark Cox, he's the ultimate coder, he's awesome and so, he's ready to get started.

So, I navigate to the Certificate section. Here I see Clark as a team member has submitted a certificate signing request to me. So, I will approve Clark's signing request and that way it will be available to him to download so he can really get started coding here. So, as it's pending, pending issue it takes a few seconds and now his certificate is now approved and available to him.

Under devices, you'll see that I already entered Clark's device, he found it in Xcode, e-mailed it to me and I input it in the portal already for him. I'll go to the App ID section, and again you'll see I have three here. One development wild card which is the simple asterisk character and then a few explicit App IDs.

As you can see on the right, which we'll discuss later, you can see that the development wild card App ID is unavailable for Push Notification and In App purchase. We'll discuss that in more detail later. So lastly, I'm going to create a provisioning profile for Clark so he can get started on his development and start testing our great application on his device. Creating the profile is fairly simple. I just name the profile whatever I want, name it Clark's profile.

I can select his certificate. I can also select my own as team agent, however, my code is horrible, so I'm going to leave it to Clark to do that, and I'll select an App ID. So, here I'm going to select the development wild card App ID so that Clark can just hammer away on multiple applications.

And lastly, I'll select Clark's device. So, I've got my 3 pieces, my certificate, my App ID and my UDIDs and I see that Clark now has a provisioning profile available to him. So from that, I'm going to turn you over to Clark, who's actually going to show you how it's done.

Alright, thanks a lot.

Thank you.

Okay to start off I've got a simple project here and I'm ready to take it from the Simulator onto the device. As you can see here, I'll launch it, it runs in the Simulator and isn't that cool? Alright, so I'm ready to take that to an actual device. I can do that in 4 steps. The first thing I need to do is install the developer's certificate that Nitin created for me. I've already downloaded these ahead of time, so I'll just double-click this and go into the Keychain.

As you can see, I've got my certificate and my private key here. The private key was already installed on this machine ahead of time because this is what I used to request the certificate. If it weren't here, I would have to go to that machine, export from the Keychain, and import it here. It's a essential that you have the private key otherwise you will not be able to sign.

The next thing I need to install is the provisioning profile. Again, I'll double-click that and in this case, it opened iPhone Configuration Utility but that's fine because the end result is the same. It installed it on my Mac. Now I'm going to go into Xcode and bring up the Provisioning Profiles. I'm also going to attach my device.

You can see that Xcode knows that this Provisioning Profile can be used with this particular device because it contains a unique identifier. To install the profile on my device, all I need to do is drag from here to my device. As you can see now, it's installed. Had my device been plugged in when I initially added the provisioning profile, Xcode would have done this automatically.

But I did it manually just to show you what you need to do if you actually have to do this later. As you can see the app identifier's a wild card, so I can use any bundle identifier that starts with com. Now I'm ready to actually build my application.

First thing I need to do is verify a few settings. I'm going to open my target build settings and find the code signing identity. I don't need to change this because Xcode knows and can match the beginning part of the string with my certificate name. So since my certificate name starts with iPhone developer, it automatically knows to go ahead and match it with that. This allows me to keep the same setting in the build settings without causing source code control conflicts with different developers changing it and then checking it in. So that setting I've verified.

Now the next thing I need to verify is my App ID. So, again, I'll go into the target info and go to Properties. Now because I had that wild card app identifier, I don't really have to change anything here, because it starts with com. anything after that is gravy. I can put whatever I want there. So now, I make sure I'm building for the device SDK, and I'm ready to go.

Xcode builds my project, installs it on my phone, it will wake up here in just a second... and there's my really cool application, running on the phone.

Thank you Clark. So as you can see, building and installing can be very, very simple, right out of the box. There's no problem and another great feature which is available now, is that for those of you who may be on multiple teams, you can now have multiple certificates. They're, now you don't need to set your different certificates in different Keychains or different logins.

So, that's a great new feature available now so it makes the hassle definitely much less, if you're developing on multiple different teams. So, let's move on to using iPhone US 3.0 features and what you're going to need in the Program portal to enable these. So the 4 features I want to talk a little bit more about today, is the Apple Push Notification Service, In Out purchases, sharing Keychain data between applications and then lastly hardware accessory integration with your iPhone application. What do these all have in common? Again, it's the App ID.

The App ID is identifying your application to the world. It is saying that this application is being used explicitly for this use and nobody else in the world can have it, it's yours. So let's start with Apple Push Notification Service. As many of you are familiar with it, the Apple Push Notification Service is essentially a remote tap on the shoulder from your notification server to your application, notifying the user that something great is waiting for them in your application.

Now, what do you need in the portal to get these done? As we mentioned earlier, there's 2 items you're going to need. The first is a client SSL certificate that's installed on your notification server and allows you to connect your notification server to the Apple Push Notification Service.

Now this is slightly different from the certificates we were using earlier for code signing and its purpose is different. These certificates are SSL certificates which are essentially just creating a handshake between your notification server and the service. They're not being used for code signing or to authenticate your identity, and that's why these SSL certificates do actually, they don't contain your name, but instead contain the App ID for the application which is receiving notifications.

So in this case, the certificate is for com., com.domain.appname. Only the person who owns that App ID can ever send notifications to an application with that bundle identifier. So, you're ensured that nobody else in the world can obtain a certificate for your application and send notifications to your app.

So, now that you've gotten your certificate to connect to the service, you're going to need a provisioning profile. Now this is going to be slightly different than the profiles we created earlier in that it's going to have one additional item inside of it and this is going to be an Apple Push Notification Service Entitlement.

The very act of creating a certificate actually puts this entitlement in the list, into your provisioning profile. So after you've enabled an App ID for push notifications, you'll recreate your Provisioning Profile, it will detect that you have enabled this for push and that it will put these bits inside your application. This is what actually allows the device to look for these notifications as they're coming in, since they're being sent to a specific application with a specific bundle identifier.

Now, there was a session earlier this week, again on Apple Push Notification Service, so if you're interested in getting a little more in depth on how it works, how to set up your servers and your application itself, you can view the video for this session when it's available. Now the second 3.0 feature that you're going to need to interact with the iPhone Developer Program Portal is In App Purchases.

In App Purchases or Micro Purchases, are the ability for you to offer additional add-ons to your application to users, such as new game levels or ammunition or some sort of monetary In App funds. Now in the Program portal, again in the App ID section, what you're going to do is navigate to the application which you're building, which you want to use In App Purchases for. You'll see two check boxes here in the App ID section.

The first being to enable the application for push notification and the second being to enable the application for In App Purchase. Clicking on the In App Purchase check box then will send this data over to iTunes Connect and we haven't talked about iTunes Connect in detail yet, but iTunes Connect is where you'll be managing the items and the parts and the SKUs that you'll be offering to your customers. In iTunes Connect, you'll navigate to the Manage In App Purchases module and from there you'll create a new In App purchase.

Now if you have an existing application on the App Store, you'll be able to do this right away and you can go start testing In App Purchases. However if you're just getting started, you have a brand new App and you want to test it with the In App Purchase Sandbox, what you'll get is a drop-down menu of the specific bundle identifiers or App IDs which you've registered for In App Purchase.

So you'll select which application you're working on and what you want to set up for and from there iTunes will set up the various metadata for your purchases, including the SKUs, the pricing tiers and the localization. To complete the process you'll go back to Xcode and that's where you'll be working with the StoreKit APIs to build your application and test it with the In App Purchase Sandbox service and then when you're ready to push your application live to the world, then all your In App Purchases will be tested and available to your application. So there was an In App Purchase session yesterday which I hope you did catch. Again, we'll check it out on video if you were unable to attend it.

So the next, the third iPhone OS 3.0 feature that's available, is Keychain Access Sharing. Now the Keychain Access we talked about a little earlier with certificates, but the Keychain is actually an area on the device as well, which allows you to read and write data from. In iPhone OS 2.0, every application shared a specific slice of the Keychain in that it could only read and write data from there. But in iPhone OS 3.0, you have the ability to share this data across multiple applications.

So if you are doing a single sign-on perhaps, you can share this log in information across the applications. So if you had a mail application, your user could log in, put in their username and password, and then when they're ready to go to their calendar application, they don't have to log in. That data is being shared. So it's a really great feature, very helpful for enterprise users, if you're sharing game scores, it's very scalable and can be used in a variety of different ways.

Again, the common input in this is going to be your App ID. In this case, it's going to be that ten digit random string that Apple generates. So this App ID prefix is unique to you the developer and it is your slice of the Keychain Again, nobody else in the world will have it, so you don't have to worry about other developers mining data from your application or accessing the data you are storing, is yours and yours alone to share amongst your applications.

Now how do you actually do this? That's a different question. So the first thing you're going to do is create a provisioning profile with the App ID prefix of your choice, whichever one you want to use if you have multiple ones, you can use that slice. All of the applications which you want to share data between, have to have this same App ID prefix. So that's the one requirement in order to share this, because they're all accessing the same area of the Keychain. The second thing you're going to do is add this Keychain Access group entitlement to your Xcode project.

Now Xcode is great and handles all of these entitles seamlessly and invisibly to the user, but since not everybody wants to actually write or share data between applications, this is the one step you're going to have to do manually. In Xcode you'll go to the New File menu and add a code signing entitlements plist to your project. You can name the plist whatever you want, but best practice is just to name it entitlements.plist. From there you'll actually see that there's a default entitlement inside of that file, which is the get task allow or debug prefix.

It allows you to access the debugger on the application. So what you're going to do is you're going to actually add a new entitlement for these applications that are sharing data and this is going to be an array which is called, Keychain-access-groups. And this is then the next step is that you'll specify the first item of your array. This is going to be your ten digit App ID prefix that we talked about earlier.

Now this is actually going to be the only time you'll ever have to input this ten digit prefix anywhere. Xcode seamlessly handles the handling of the prefix in all other cases but in this particular one, this is the only time you'll actually enter this ten digit string in.

So you'll enter your ten digit string and then you'll, followed by a period, followed by any string of your choice. You can name the access group whatever you want. In this case I think it's your access group. It's completely up to you and the only thing important is that all of your applications share the same access group name.

From there you'll actually navigate to the target build settings and you'll see that there's a code signing entitlement field and there, since we're actually adding an entitlement that we want to write into your App bundle, you're going to enter the entitlements.plist file we just created. From there you can build and go and your entitlements will be written into your application.

The last step in this Keychain Access sharing is going to be to actually specify your access group in the code itself and this is done using the KSecAttrAccess group symbol in the security framework and you'll see that I've defined my access group here, which is my ten digit prefix, followed by the access group name and as long as I use this in all of my projects, I'll be able to share, read and write data between my multiple applications.

So there's a great example of this in Action and in Practice in the In House App Development session for iPhone and if you're a little more curious about the security behind the iPhone and how this Keychain works, you can view the Creating Secure iPhone and MacOS X Application session. So the last feature I want to talk to you about today in 3.0 is integrating your applications with hardware accessory.

And there's you know, multiple protocols which you'll be sending between your application to actually talk to the accessory but the one I want to focus on today is programming your App ID prefix into your hardware application. What this allows, if you set this ten digit prefix as a property in your file, what happens is that whenever your customers actually plug in the device to your hardware accessory, it'll bring up any applicable applications in the App Store. So it's a really great feature.

It just detects this is an application that works with this device. It allows your user to download the application immediately from the App Store and then start running it. So all that's needed in there is to input your ten digit prefix into the accessory itself. So again there was a Creating iPhone Apps that Communicate with Accessories session, which really talks about this in more detail. So if you're really interested in doing that, you should check that session out.

So, let's move on to refining your applications. For this session I'd like to introduce Christian who's going to talk to you a little bit more about this. Christian.

Thanks. So I have a question for you all. How many of you would like to have glowing reviews for your applications in the App Store? No complaints about crashes or something not working right away. Can I see a show of hands? Yeah, that's what I thought. Well my name's Christian and I'm here to talk to you today about setting up a Beta program for your testers for your application.

So, setting up a Beta program has five steps. The first one is collecting some information about the Beta testers you've recruited in your Beta program, specifically the App IDs that Nitin mentioned before. Then we'll be taking that information and going to the program portal and generating an Ad Hoc provisioning profile. This lets you take your application and give it out to the folks that you've just entered and recruited into your program.

Once you have that provisioning profile and the additional cert that goes with it, we're going to go over to Xcode and we're going to put that in and build the application with the Ad Hoc provisioning profile and then we're going to ship it out, give it to our testers and have them install it and finally we're going to get some feedback if something were to go wrong, back from our users. To show you all this I'm going to go to demo. All right, so for this demo I'm going to be doing, I'm going to kind of have a split personality.

I'm going to spend part of it as kind of your average Beta tester and go through the steps that they need to go to to get into your Beta program. Then I'm going to switch over to an admin user and show what the administrator needs to do and then finally at the end I'm going to switch back to the Beta tester user and show you what they're going to do to install the device and get feedback back to you.

So to start off here I'm logged in as my Beta tester user and you'll see that I've got this iPod Touch right here in my hand and I'm just going to plug it in and you'll see that after a minute or two you're going to see a pop-up here in iTunes and so my administrator for my Beta program said, I need to get him the UDID for my device. So if I select the device here and I click on serial number, I can get the UDID for that and then I've got to copy and paste it into an email and send it off to them.

So that's one way you can do this. Another way that Nitin mentioned earlier is you can use Xcode, but you don't really want to tell a Beta tester to download the Xcode package. If they're not a developer, they're never going to need all of that stuff. So we have a third product called the iPhone Configuration Utility that kind of fills the void there.

OK and what the iPhone Configuration Utility does is it lets you manage devices, applications, provisioning profiles and also configuration profiles, something we won't be going over in this demo. So if you go here under Devices, you'll see that the iPod Touch that I just plugged in, is now here. You'll see that the device identifier is listed there as well.

So again, I can just copy and paste this into an email or I can click the Share button here in the toolbar and this is really handy. Because what this is going to do is IPCU will generate a device info file which has the name of the device, the UDID, and other little bits of information and just drop them into an email that I can send off to anybody. So I'll just click the Share/Tell and then send this over to my administrator and then just hit Send -- and then just hit Send -- and it's all just going to go off. OK, so that's it.

As a Beta tester, that's all you need to do. So let's switch over now to our administrator and see what things are like on their side. Oops, that shouldn't be open and that shouldn't be there either. OK. So on this side of things you'll see I now have an email from my Beta tester with that device info file in there. I'm just going to double-click on it.

I'm going to go ahead and add this to the library. Now you'll see as the administrator, I also have IPCU installed here. IPCU is handy here because it lets me aggregate all of the devices that I'm going to be putting into my Beta program, into one spot. So I'm going to go ahead and click, oh I accidentally left the device plugged in. Sneaky. So there we go. Now we've added it and we've got this and a couple of other devices that we already have collected from other Beta testers.

So the next step in this process is going over to the iPhone Developer Portal and uploading all these UDID's. As you can imagine, I could copy and paste all of these things into the portal or I could use a simpler way. IPCU lets me select all of these devices and export them in one file that has all of the devices in it. So I'm just going to export this file and call it my Beta testers, just put it on my desktop.

And then I'm going to leave IPCU for now. And then at this point I'm going to go over to the iPhone Developer Portal and add the devices and generate the certificate and do all the things you need to do on the portal. So we'll go here and log in.

So the first thing I need to do here in the portal is I need to input the devices I just exported from IPCU. So just select Devices, now normally you're probably used to adding devices here one by one by clicking the Add Device button, you've probably noticed this Upload Device button next to it and always wondered, what's that about. Well we're going to show you. I'm going to click Upload Device and I'm just going to choose that Beta tester file from IPCU.

Then I'm going to submit them and once this loads here, you're going to see that all the devices from IPCU are now here lickity-split, no problem. No manual text entry, this is much easier. So now that we have the devices in, the next thing that we need to do in order to generate an Ad Hoc profile is we need to make sure we have a distribution certificate ready for us to use. So I'm going to visit the Certificates portion of the portal and normally by default it shows you the development certificates.

We're going to move over to the side one and choose Distribution and you'll see that I've already generated a distribution certificate here. All apps that are signed for Ad Hoc and App Store Distribution need to use a distribution certificate. So I'm just going to download this and stash it in my Downloads folder for the time being. So that's there. So now we've got devices and a certificate, the next thing that my provisioning profile is going to need is an App ID.

So I visit the App ID section here and I've already put one in for my amazing application I'm going to Beta test, right there. So I'm just going to copy and paste that. I'm going to need that in Xcode later. But the long and short of it is, I'm just going to use this App ID and just hold it in my head for now.

So now I've got devices, certificate, App ID, we're ready to make a provisioning profile. Let's go over to Provision. And again, normally by default it shows you the development provisions, but this is different, I'm distributing. So I'm going to click on the Distribution Certificates and I'm going to go ahead and select a new profile.

I'm doing Ad Hoc distribution here again, it lets me just give it to a set number of folks. Going to put that in here and then I'm going to call this the My App Beta provisioning profile, already there for me and then I'm going to choose the My App App ID.

For all of the devices that I want in my Beta program here, I'm just going to Select All and remove Clark. I don't want Clark in my Beta program. You can choose who goes in, this allows you to do as many combinations of people as you want for as many different target audiences as you like.

And then submit. So now this is going to go and generate the profile for me and if we take a look at the details here, you'll see that we've got My App, that's the App ID that I put in before, the distribution certificate that I showed you and we have the five devices that we pulled out of IPCU. So I'm going to download this provisioning profile, all right that's local here. All right. So now I've got the two things I need on my computer in order to prepare this application for Ad Hoc distribution. A certificate and a mobile provision.

Let's go here to my Downloads folder. I'm going to take the certificate and I'm just going to drag it on top of Keychain Access and you'll see here in Keychain Access now, I've got an iPhone distribution certificate. So we're good there and I now have a mobile provision.

I'm going to go here and just drop that on top of Xcode and if we go to the Xcode Organizer, you'll see in the provisioning profiles, I now have the My App Beta Provisioning profile. So now I've got those two things installed. Now here's my app, here's the project here in Xcode.

I'm going to need to do some things in order to prepare this for Ad Hoc distribution. First of them is quite simply I want to switch this over to the device SDK and I want it to build for release. In addition to building for release, I also want to switch it here in the settings over to using the distribution profile.

You'll see that it currently matches the certificate that I found, so this is going to work no problem. The next thing I need to do is go here on my target, bring up the Info window for that and I'm going to need to provide the App ID that I set up in the portal earlier. So I'm just going to paste that in. OK so now we've got that set and the final thing that I need to do is I need to add an entitlement to this project. Nitin mentioned earlier this idea of Get/Task/Allow.

Basically this is an entitlement that tells the device if it should allow a debugger to attach to a running process. Since this is Ad Hoc, this is something that you're giving out to users, you want to turn that off. So I'm going to just go here and say new file and create an entitlements file, oops and we're going to call it entitlements.plist.

You can name it anything you like, I'm just keeping it simple. And then you'll see by default, Get/Task/Allow is listed here and it's on, so I'm going to turn it off. So now I've added the .plist, I'm going to save it and then I'm also going to go back to my target and here when it says, for the code signing entitlements item, I'm just going to put in the name of the .plist, entitlements, typing on stage, never fun.

entitlements.plist. All right, so there we go. All right so to recap what we've done here in Xcode. We've chosen the distribution provisioning profile, we've added the entitlements, and we specified the App ID that I used in the portal. So we should be good. I'm going to go here and I'm going to select Build.

The build succeeded and I'm going to go to the Products folder here and I'm going to reveal the product in the Finder. So this is the application that I want to give out to my Beta testers. All I'm going to do is I'm going to just package this up, going to zip it up and then I'm going to write a new email with that and I'm also going to take the provisioning profile that I downloaded from the portal and add that right there. So these are the two things that my Beta tester is going to need in order to run the App on their device.

So let me send this off to them. All right, my App Beta. Going to send it. All right and now we're done with the admin side of things. Let's switch back over to our Beta tester. All right, so for our Beta tester, we're going to check our email here and we have the provisioning profile and the application in our email.

So what I'm going to do is, I'm going to take the provisioning profile and again, the user can just drag and drop this on top of the iTunes icon, but iTunes doesn't have any facility for managing provisioning profiles. So if you wind up having a tester that winds up doing a lot of Beta tests for you, it's hard for them to know how many provisioning profiles they have and manage all that.

IPCU makes this a lot easier for Beta testers. So we're just going to take this icon, drop it on top of IPCU and we're going to go ahead and add it to our library. So you'll see now here in the provisioning profile library we have the Beta provisioning profile.

And then I'm going to take the application that the administrator sent to me, bring it to the Desktop and unzip it and do the same thing. Just drag it on top of IPCU, yes I want to open it, go ahead and add it to the library and now you'll see my applications library I've got my app.

So at this point I'm going to just take my device over here and plug it in and again you'll see it pop up in IPCU very shortly and all I need to do to install the provisioning profile in the App on here is just select the device here in the source list, choose provisioning profiles and install the My App Beta provisioning profile and install the application.

It's going to take a moment to copy over and we're successfully on there. So let's go over to the device real quick and let's pretend we're the Beta tester. So I'm going to unlock my device and sure enough, here is my app. So I went one above Clark with my application and I have two buttons. Put a lot of work into this.

I'm the PM a project manager, so bear with. This does two things, it writes to the console, so we're going to write to the console a little bit and you'll see why in a second and then my favorite button in any app, the Crash button. So now we've crashed.

So can still do that good. So we're going to switch back over to the demo machine here. Now let's pretend that I'm a user and I've just found a crasher on my device and I want to provide information back to the administrator for my Beta program, like hey like you know your App crashed. So normally I would just write an email and put the steps to reproduce in there. But then the App administrator would also probably want some diagnostic information from the device.

Well since I have the device plugged in here in IPCU, I can look at the device console and specifically once I show the console, I can filter based on the application that's logged to console. So my app's name is My App and sure enough, here are all the different console messages that are from my application. So I can simply select them and save that selection as a text file. So I can easily pop that in an email.

Also crash logs are usually pretty handy. Let's hide this and go over to console, so all of the crash logs from a device are usually copied over to a machine and the path is a little bit long. It's in the user'sLibrary Logs folder, but when you drill down here you'll find this .crash file for the application and you can just drag that into an email, along with the device log, send that back to the administrator, along with the steps to reproduce and you've provided some valuable feedback. When it comes to dealing with crash logs, there's a great Tech Note, 2151, look that up. It gives you all sort of information about dealing with crash logs. So at this point I'd like to go back to slides.

Thanks. All right, so now we found out how to effectively administer a Beta program. The five steps again, just to make sure we're clear is, you need to collect the device information from your Beta testers after you've recruited them. Afterwards you're going to need to go over to the iPhone Developer Portal and put in those UDID's, get the right certificate, and the right App ID and generate an Ad Hoc provisioning profile.

In Xcode you're going to need to set up that provisioning profile, as well as the certificate and sign your application using that. Then you've got to send that all out and solicit feedback from users and let them know how to do that. So at this point I'd like to bring Nitin back on stage to talk about preparing your application for distribution.

All right, thank you very much Christian. The Beta testing is fantastic. I mean it's much better to identify these crashes early than read it in the review section of the App Store. All right? So it's a great technique and it's very simple to kind of manage it and administer.

So let's move on to preparing for distribution. At this point your App is, it's refined, it's honed, it's a well oiled machine. You want to get it out in the world and start seeing a little return on all this investment that you've been making. So preparing for distribution, there's three types.

The first obviously, App Store Distribution. The second, Ad Hoc Distribution which allows you to install your applications on up to 100 devices. As Christian just navigated through those waters. And the third, Enterprise or In House Distribution and this is for those developers who are developing proprietary in house applications that aren't really fit for, suitable for other people in the App Store obtaining it. The Enterprise Distribution model, distribution mechanism is identical to the Ad Hoc distribution that Christian just went over, where you'll be distributing your compiled App bundle and the provisioning profile used to build it to all of your users.

But let's get back to the App Store, that's what we're really interested in. You'll be managing your applications for distribution, in iTunes Connect, which is another web portal. This is going to be where you manage all the aspects of distribution. We've got the Development portal for your development aspects and then iTunes Connect for when you're ready to really manage this. So iTunes Connect consists of several modules, but the one that you really want to pay attention to immediately, before you even start coding is the Contracts module. You'll actually have two different kinds of contracts. The first is for free applications.

That you're going to have by default when you first log in to iTunes. You'll need to submit it, but the turnaround time for that is very, very quick and you want to get into the iTunes Connect as soon as possible if you're developing free or commercial applications, you want to log in and get these contracts prepared so that you're not waiting for them to get approved and set up when you're ready to distribute your application.

So in parallel with your coding, get up in there and really take some time to fill out these applications and contracts because you may need to review them with a legal person in your company or send them around for review. So it's important just to get in there, get a head start on it so it's not hamstringing you later down the process.

The second thing you want to do in parallel with your development is to take some time to set your application apart by creating some really compelling artwork and metadata. The App Store presents you with a window that you can invite your users to really kind of grab the application and increase their kind of desire for it.

So it is your store front to the world. So it's important that you don't just cobble together some screen shots at the very last minute, but spend some time to really think about how you want to present this application to the world, whether it be just the screen shots and icon, but also with the description of your application and perhaps you want to incorporate reviews of some people, some esteemed colleagues or some journalists by Ad Hoc distribution who have tested it before. So there's a lot of metadata that you can provide including the artwork but also links to your support site, links to some other, your website which may have other applications that you're distributing.

So get in there and start really thinking about your metadata beforehand because you want to present the best product to the world to really skyrocket it to the top. Now iTunes Connect consists of several modules. The first we talked about which was your contracts, which you want to manage and get in early.

But you can also manage iTunes Connect to users. So if you have a legal representative or a technical person who really works on providing the metadata and if you have perhaps a business analyst who needs access to some sales and financial reports, you can add them in the Manage Users modules in iTunes Connect.

Another module available is your Sales and Training Reports and this is kind of the most exciting when your App starts taking off. You can see your geographic breakdown by territory of where your sales are coming from and you can really garner some really great business intelligence from these reports that are available.

In addition there is the Financial module which is probably pretty important to most people, where you can track where all your money is coming from and how much your App is making. And this is available by version as well. There's the Manage Your Applications module, which is where you'll be uploading your application as well as associated metadata and lastly there's an area for promo codes. So you can actually create up to 50 promo codes for each version of your application and these are redeemable for 4 weeks. So this is a great way to really get the word out about your application once you've uploaded it.

So let's move on to submitting to the App Store. You got your contracts in place, you're set up, your metadata is really great, really compelling, the artwork just fascinating, you're going to need to build your application for distribution. Now as Christian showed earlier, you're going to need two items to build this distribution-ready application. The first is your distribution code signing certificate.

Again this is similar to your development code signing certificate but it has an extension in it which the App Store requires in order to accept your application for upload. This signifies that this build was by the team agent or authorized by the team agent who is the primary legal contact and makes sure that nobody else on is distributing or sorry, uploading some development build which might not be ready for distribution.

So really it's a check to ensure that this is really the one you want uploaded to the App Store. And the second piece is your distribution provisioning profile which contains that distribution certificate, your application ID and for the App Store it actually contains no devices since all you'll be doing is uploading the application.

You'll head to the Managing Your Application module which is where you'll be uploading the zipped file which you've, you'll build your project in Xcode, compress your product and then upload that zip file to your Managing Your Application. So with that I'm going to bring up Clark again who's going to show you some best practices for setting up your project for distribution.

Clark.

Thanks Nitin. OK we're back on my machine and this time I'm going to do something quite similar to what I did the first time, except now I'm building for distribution. Again I've downloaded the certificate and the provisioning profile, install the certificate. I double-click it. If I look in Keychain Access, you'll see that now I have the distribution certificate as well, with the Admin's private key. You have to get the admin key separately because you're not likely on the same machine that initially requested it. So I've got those two pieces there.

Next what I need to do is just as before, install the Provisioning Profile. I can do that like, by double-clicking as before, I can drag it to Xcode's icon or I can just drag it here. They all have the same end result. OK so I've installed that. You can see a couple differences from before. This has an explicit application ID. I did that so I can show you later what that entails and it does not include any devices. That's because this profile is not going to be used for installing directly on a device, it's just used for building for distribution.

OK I've got that set up. I'm going to go back to my project. Now I could, just as Christian did, just switch to release and change the settings and so on, but that can cause conflicts in source control management if someone just wants to build a release version for their personal device. So what I'm going to do is go to my project, go to Configurations and create another configuration.

These are basically buckets of build settings that are kept separate. I want to start with my release configuration and then duplicate it. I'll name it App Store. Now this configuration at this point is identical to my release configuration. But I can change its settings without affecting my release configuration.

So now I'm going to go to my target's build settings and I'm going to switch my code signing identity to iPhone Distribution as opposed to iPhone Developer. Now again, I just need the iPhone Distribution part, not the whole name, because Xcode knows automatically to match based on that initial sub-string. You'll also notice here that what I expected to match would be this profile, however it doesn't match because of the application identifier.

So that's the next thing I'm going to set. I'm going to go to Properties and this is where I would set the identifier. I'd get it from the profile. It just this part without the ten digit prefix. I'll copy that, close that and just paste it there. Now I've got the provisioning profile installed, I've got the certificate installed, I've got my build settings set up and I've got my App ID set appropriately.

Now I just need to make sure I'm using the device SDK and I'm building my App Store configuration. So I'll choose that. This time I'm just going to build, not build and run because the Provisioning Profile won't allow it to be installed on my particular device. Running wouldn't mean anything. So I build it, the build succeeded and now I'm going to go into the Finder and show my built product. Here's the actual binary and next to it you're see the dsym [assumed spelling] file.

This contains descriptions of the various symbols in my applications, line numbers, variable names, function names, etcetera. I need to keep this around. Because it's tied directly to this particular build of my application. There's a unique identifier in both and they need to match up. Even if I were to rebuild this project with no changes, it would have a different unique identifier and it would not match up with that particular symbol file.

This is important later when you get crash reports back, if you want a symbol rich crash log, as opposed to just numeric offsets. So I'm going to want to keep that. What I need for actually uploading to the store, I just need to take my application, compress it, now this file is what I'll end up uploading to iTunes Connect.

It's a good idea to use the Finder to do this compression because it preserves all the appropriate metadata. There are command line options to do the same but by default the zip command line tool does not preserve the appropriate metadata. So I've got this which is what I would upload, now I would need to save this somewhere on my hard disk where Spotlight, the system search and indexing tool, can find it for later, in case heaven forbid, I get any crash reports back.

So preparing for distribution, all I needed was the distribution certificate, the distribution profile, I need to make sure that I set the appropriate App ID in my info.plist, make sure I'm using the appropriate signing identity in my build settings. When I build I need to make sure to save this file and zip up this file and there's my product, ready for upload.

Thanks and with that I'll go back to Christian

All right so thank you very much Clark. Clark's now taken our application, put it up in the store and it's a rousing success. We're very happy with how it's turned out. So once the release is out there, there's a couple of just little tips we like to pass on to folks. Keep in mind once you're out there in the wild.

The first one is, promotional codes. Nitin mentioned this earlier. Be sure to use the promotional codes. You get 50 per version. Send them out there, give them to your friends, bloggers, get the word out about your application. So don't forget to use promotional codes. Next up, don't forget to review your reviews on the App Store. Sometimes good issues come up here and be responsive to what folks have to say about your application.

Make sure you take a look and respond to the commentary there. And then the final thing is that iTunes Connect offers you a list of crashes that are most common for your application. Make sure you visit iTunes Connect, download these and then just drag them into the crash logs portion of the Xcode Organizer. Clark mentioned earlier to keep the dsym file for your application around. What this does here in the Organizer is actually going to find that dsym file and match the crash log to it so it can symbolicate it.

Give you useful information out of that crash log. So for more on this, tomorrow there's one session still in the future, it's called Publishing on the App Store. That's at 2 o'clock on the Presidio tomorrow, make sure you go and take a look at that for more information about getting your App on the Store. So in conclusion, today we've talked about what it takes to set up your development environment.

The different profiles and certificates, App IDs, the different players and the website you need to go to. We also walked you through what it takes to install an application on a device versus running it in the Simulator. We've talked about taking the four great new features in iPhone OS 3.0 and setting up your application to use them. We've talked about setting up of Beta programs, so that you can get good testing feedback from users, get your App out there and make sure that it's rock solid for release.

We've talked about steps you need to do to get your App ready to go out and finally we've talked about getting your App onto the App Store and the steps involved with that. We have a lab today at 3:30 in iPhone Lab A. We won't have time for Q and A today, we're out of time unfortunately, but please come there, ask us your questions and let us know if you've been having any issues. For questions please email Mike Jurewitz, his information's here on the slide. For documentation, the iPhone OS reference library has a ton of information involving all of this. Also I mentioned specifically, Tech Note 2151, that's for dealing with crash logs from iPhone OS applications.