So good morning Moscone. It is my pleasure to welcome you here this morning and to take you through the second part of our journey that we started yesterday with Todd. We want to take you to a way to master iPhone development with Xcode. It will be a journey that will be in three parts.

That's interesting, I like that slide, but, okay and so yesterday you went through developing, building, provisioning and distributing. Today you will go through project structure. It is very important to start with the right foundation on your project. Then you will learn how to target older devices while still benefiting from the features of newer versions.

You will then go through device provisioning, I know it's a very easy thing, but we can revisit it once in awhile. And then you will be taken to application life cycle. So I will first introduce Jacob who will drive you through project structure. Thank you.

Thanks Marc. I'd like to talk to you today about how to set up your iPhone Apps project. I'm going to be talking about two things. One is, some important project setting that you like to set up, that you should set up in your app project and the other is how to bring your app to the iPhone and iPad.

There's a lot of settings in Xcode and I know it can seem kind of intimidating at first, but really there's only a few that you actually need to care about and I'm going to show you how to set those up today so you can get down to the real programming work.

First off is the Base SDK. The Base SDK determines which version of the OS is used to build your application. And this is not the same as which version of the OS your app can run on. I'll talk about that in just a minute. You should always set this to the latest version of the SDK, so currently that's 4.0. Now the Deployment Target is the setting that determines which versions of the OS your app can run on. So you just set this to the oldest OS version that you want to support.

So, if you like to run on 3.1 and later, you just set it to 3.1. And this determines whether symbols that you use in frameworks are strongly or weakly linked. And we'll talk in a little bit about how to safely use those new features while still being able to support older OS versions.

The Architecture setting is another important, another important setting in your project, but this one's really easy. You can just set it to Standard and you'll be able to run optimally on all devices. And this will go for armv6 and armv7 and it's the default for newly created projects.

Finally, there's the Targeted Device Family setting. And this determines which types of devices your app can run on. You can set it to iPhone, iPad or both. And what you set this to is totally up to you. So let's have an example. Let's say you're setting up your app and you want to set the Base SDK first. Since the latest version of the OS is 4.0, what should you set the Base SDK to? Anyone?

4.0.

4.0, that's right. Then you should set the Deployment Target to 3.1 if you want to support OS 3.1 and forward. The Architectures, you should set to standard in all cases and if you want a universal app, you can just set it, the Targeted Device Family to iPhone/iPad. Then you'll be able to use all of the new features up to OS 4.0 and support all the way back to OS 3.1.

And it's important to make sure you always test on all of the OS versions that you support. Next, I'd like to talk about how to bring your app to the iPhone and iPad. Universal apps are one way to do this and with this method, you have a single application that runs on both device types.

The alternative to this is multiple apps. Here you have two applications, one for the iPhone and one for iPad. And when you're done, if you have an older iPhone only project, you can actually use Xcode to automatically upgrade your project to run for iPad. Just click on, just select the iPhone App Target in the Groups and Files table and then select the Upgrade Current Target for iPad menu item. And this will give you the option of either upgrading to a single Universal App or to Multiple separate apps.

So what's the difference between these two approaches? With the single universal app you have 1 target that builds 1 application that runs on both devices. Where as with multiple apps you have 2 targets that create 2 applications, one for iPhone, one for iPad. And which one you choose is really more of a marketing decision about how you want to deliver your product to your customers.

So now I'd like to show you some of that. Okay, now let's get started. I'm going to open up this older project that I created and for iPh, an iPhone application. Now, first off I'm going to build and run to see how it looks, but unfortunately I'm getting an error now.

It's not finding the SDK that's set as the Base SDK, the iPhone 3.13 and this is probably a common error that you'll run into as you're updating to newer SDK versions. The problem is, the Base SDK that's set is no longer included in this version of the tools. Luckily, this is easy to fix. I'll just open up the project and go here to the Base SDK and we'll set it to 4.0, the latest version.

While I'm here, I'm also going to go down to the Deployment section and change the Deployment Target to be 3.1 and now I'll be able to run on anything back to OS 3.1. Okay, now let's try to Build and Run again in the simulator.

Great. Now it's building and here's our application. I'm also going to see how it looks on the iPad simulator.

Since this project hasn't been upgraded to run for iPad yet, it's just going to run in the iPhone compatibility mode and that's not a great user experience. So let's go back, find our iPhone App Target and then once that's selected, choose the Upgrade Current Target for iPad menu item. As you can see we get the option for a Universal app or 2 separate apps. I'm going to go with the Universal app, though.

And now you can see, it's created this resources group which contains an iPad version of one of my original iPhone resources. It's also made some changes to the target, the most important one is setting the targeted device version to iPhone/iPad, so that now it's a Universal app. And you can also see that the Architectures is set to standard.

Okay, let's run again for the iPad simulator. Great, now we have the full iPad experience. Okay, now to summarize what we just saw, you should always use the latest Base SDK, you should set the Deployment Target to the earliest OS version that you want to support and you should test on all of those versions that you are supporting.

You should use the Standard Option for Architectures and you should choose whether to bring your app to the iPhone and iPad either with Universal apps, a Universal app or Multiple apps and you can do that with the Targeted Device Family setting. Now I would like to hand it over to Clark Cox to talk about targeting multiple iPhone OS versions.

Thank you Jacob. Now Jacob's already shown you how to structure a project to take advantage of the ability to run on earlier device versions. Well, there's one thing left, your code. Every last major update we've provided has added new functionality and new APIs, new classes, functions, symbols, to take advantage of that.

Say for instance I wanted to use a class that was newly introduced in 4.0. If I were only writing for 4.0 this is what I would do. I would just use the class directly as you would any other. However, this class doesn't exist before 4.0, so I need to test that first.

I do that by calling NSClassFromString passing in the class name, this will either return the class object that exists or it will return nil if it doesn't. If it's not nil, I can go ahead and use that variable as I would, I would've used the class to begin with. Here, allocating and initializing an instance.

Functionality is also added by, by adding new methods to already existing classes. For instance, if you want to support multitasking it's good, it's a good idea to test if the device you're on actually supports it. However, prior to 4.0, this method didn't exist. That's easy enough to remedy.

We can test whether or not a particular object implements a method by using the responds to selector method, passing in the selector of the method we want to call. In this case, is multitasking supported? If that returns yes, we can go ahead and call it as we were before.

Slightly less often, but it still happens, functionality is added by adding a new function. In this case, this is a function that was added in OS 3.2 for writing graphics directly to a PDF file. Now again, if I want to run on something prior to 3.2, this function won't exist at run time. To get around that, I can just test that the function's address is not equal to NULL. If it's not NULL, the function exists and I can call it.

Similarly, there are also constant objects such as string constants that are often used as notification names, keys in the dictionaries and other uses. Again, just like with functions, I can test that the address of this symbol is not null, if it's not null, I can use it just as before. It's very important, even though the simulator on the device have gotten much closer in the, in these respects, to always test your code on an actual device. Now to do that we'll have to talk about device provisioning.

There were new features added in in 4.0 for Automatic Device Provisioning. I'm going to tell you about how, how you can use that, when it's appropriate to use that, when you can't use that. These include situations such as Custom Provisioning Profiles that require custom app IDs and distribution profiles. I'll also talk to you about the Developer Profile which was introduced in 3.2.

The Automatic Provisioning feature added in 4.0, quite simply, when you add a new device or you tell Xcode to synchronize with the portal, it will check if you, if you have a Development Certificate, if you don't, it will submit the CSR for you. You don't have to go to Keychain Access, you don't have to go to the portal, it does it all from within Xcode. Additionally, if you are an agent or an admin or a single person on an individual team, it will go ahead and approve that CSR for you immediately. So, the certificate is ready for downloading.

Additionally, when you add a device, we will create what we call a Team Provisioning Profile. This is a profile that includes all of the devices on your team, all of the signing certificates on your team and has a wild card app ID, so it can be used by anyone on your team, for any of the devices with any bundle identifier.

Finally, we download all of the provision profiles for which you have a certificate, including the uni, the team provisioning profile. This automatic provision this automatic provisioning, despite the fact that Xcode will download all of these profiles, cannot be used to create custom profiles, for this you'll still need to go to the Program Portal. These include situations such as in app purchase, post notifications, Game Center and keychain data sharing. All things where you need a specific, explicit app ID, however, after they are created, they will still be downloaded automatically by Xcode.

In 3.2, we introduced a new feature we're calling the Developer Profile. This is a single file that includes all of your certificates, all of your provision profiles, packaged up by Xcode in a single file. You can then, after exporting this from one working machine, you can then take it and import it on another machine to get set up immediately.

This will copy all of your certificates, including the private keys, all of your profiles and get you up and running. Now I'm going to show you a little of what's involved in the Automatic Profile feature.

Okay, I'm going to start by going to the Organizer, you see I've got a device here, it's got no Provisioning profiles, got no profiles on my Mac and I have no certificates. I'm going to start by right clicking on this device or Ctrl clicking on this device and I'm going to add the device to my Provisioning Portal. It's going to ask me for login

Okay, it's fetching information.

It's found that I don't have a Signing Certificate yet. So I'm going to tell it Yes, submit the request. Since this is an individual team and I'm automatically an admin or agent on it, it approved the request immediately and downloaded the certificates to my keychain as well as downloading and installing the Team Profile as well as other profiles that had already been created. There's nothing else to do. That sets you up for building and running on a device.

And with that, I'll hand it off to Chris Skogen to talk to you about Application Life Cycle.

Thanks Clark. I'm going to talk to you guys about the last piece of development for the iPhone and iPad. Typically in the past Xcode has kind of left you out to dry after you've built your product. Once you've tested it, built it, debug it, you're left to handle what to do with the product that you built.

How do I submit it to the store? Well you would go to the Portal and submit it. How do I Beta test with it? Well you would have to maintain a directory of all the different builds that you have and you'd have to make sure that you knew which ones were going out for Beta testing. Well, we're going to talk about some of the new things that Xcode and the SDK can do to helps you manage building and distributing your product. The first one of these features is Build Time Validation.

We've built in Xcode the capability to do offline validation of your app before you even submit it to the store. You can actually do this as a Build setting so you go into the project, click a check box, turn it on as a Build setting and every time you build, your app will be checked for things that can be checked offline. This includes icons and proper Plists and things like that.

The second feature we're going to discuss will be Build and Archive. Build and Archive is a facility to save all of your projects off to a little archive format where you can have the application that you've built and the DSIM that was created when the application was built. It will maintain that going forward in time. Whenever you hit Build and Archive it will add another archived application to that list and you can continue to distribute those and you have a history going back.

The third thing that we're going to discuss will be Online Validation. Instead of just submitting to the store to see what will happen with your application on the store, you can actually submit for Validation from Xcode. Xcode will take your app, sign it, send it to the store. The store will do all of the automated validation that the store will do, but your app will not be submitted.

That way you can get regular feedback on you know, the likelihood of success for your app by getting validation. Last, the fourth thing we're going to talk about is submitting to the store. Xcode can now submit directly to the store, so you don't have to do that through iTunes Connect. And we're going to discuss using Crash Logs after you've distributed your app to your customers.

Let's start with Build Time Validation. Like I said earlier, it is a Build setting. You can see it here, Validate Build Product. You turn it on and every time you build for a device in Xcode, your app will be validated offline. It's not all of the tests that the store does but it's everything that can be done on your machine. We recommend that you do this often, early, as much as you can. Turn on the Build setting every time you build, catch errors before you try to submit to the store.

Build Time Validation will check icons, it will check your plist structure and it will also check bundle ID amongst other things. Archived applications is a great feature that we're pretty happy to have done. It will actually, like I said earlier, will save all of the builds that you make, that you might want to distribute either to Beta test or to the store. So, if you have a process of doing builds for Beta testing or builds for your, your employees to try out, this is a great way to save them and you can have an archive going back.

This actually beats, beats just having the SCM version or just the source code, because again, built products are always different. If you build the product, you get the DSIM with it, you archive it, it's saved. You can always go back to that exact build and that exact DSIM and that will be very important later when we get to Crash Logs. It's a simple menu item. It's next to Build, it's Build and Archive. It preserves the out build exactly like it was, puts it in a library so you can find it and you can keep it forever.

Online Validation, the third piece of this puzzle. Online Validation is similar to submitting to the store, it just does not actually submit to the store. When you choose Online Validation, you will need your application to be already registered with iTunes Connect, the distribution profile will be required, you'll have to choose that and it will run all the automated app store review validation tests.

Online Validation can detect some other errors. The Bundle version needs to be increased, missing icon sizes, code signing and entitlements and we will suggest those fixes after the process is complete. So when it comes back and says your code signing is wrong or you're missing an icon, it will tell you, point you in the direction of how to fix it.

Once you've done all that and you're getting ready to actually upload it to the store, that submission in Xcode is almost exactly the same as actually submitting for online validation. You just choose a bun, an archived application from Xcode and you press Submit To Store. All of your marketing materials will still have to be submitted via iTunes Connect but at least Xcode can handle the actual application and everything that's needed for that.

So now you've got your application in the store, people are using it, you're starting to get reports that you have crashes. We actually are gathering crash reports from your customer if they've opted in, in iTunes to have that done. Those crash reports will go up to the store and they'll be available on your iTune Connect account so you can go get customers crash reports.

It's not all of them but it is kind of an aggregation of everything that will come in. You can also get crash reports directly from your users. The crash reports are captured by iTunes and put on their local drive. Many of you probably have seen them, the user can get those and mail them to you and you can use them.

Now if you did build and archive and have the built application with the DSIMs and you have a crash report in Xcode, you can symbolicate your, that crash to the built version that the customer had. So ultimately the crash will come up and you can see exactly in your source where it went down. So let's take a look at some of these things and see how they look.

I'm going to start up Xcode here. I've got my Picture Viewer application that I've been working on.

And we're going to be actually building it for a device. Now, first thing I want to do is I want to do the Build Time Validation on this project. So, let's go into the Project Settings, I'm going to type Validate, filter it down so I don't have to look for it, Validate Built Product. Great. Save that, I'm going to clean this project and go ahead and build.

We'll see it going through its Build process and when it's done, you'll see a couple of quick signs, like code signing and Validate Built Product there at the end. Now what I see is I see a warning. icon PNG, icon dimensions 57 x 57 don't meet the size requirements. Well, that's an easy fix, I still have the icon here. Let's check the plist, no entry for that icon on the plist, well, alright, let's go ahead and fix that.

Done. We'll save, now we'll go ahead and build.

Complete, the warning's gone. That will find other things, but again that's the Offline Validation. Does not contact the store and we want you to do that early and often. So now we've gotten that far, so let's go ahead and get ready for a Beta test run. I'm going to go ahead and hit Build and Archive.

And it already built so at this point it takes the built product in the DSIM and it creates an archive and you'll see in the organizer, there's a source item for Archived Applications and I will see My Application Photo view. I can expand that and I can see the one I did right now.

Let's go take a look at what this thing actually looks like while we're here. I can reveal the archived application in Finder and you'll see what is being done. Archived applications, we've got a little unique identifier, followed by the Built application, the DSIM for that application and this plist is just information for Xcode to identify the archives and display them for you in the organizer. So now we have our built product. I want to send that out to Beta testers, great.

So I choose the Built Product, I go down to the bottom here, we have three buttons for the things we've been talking about. One of them is Share Application. I'll push Share Application and at that point I'm prompted to choose a Distribution Certificate signing identity. Like we said, I'm going to do this for Beta testers. So I'm going to choose my Ad Hoc Distribution Certificate.

Once I've got that I can go ahead an email the application. Now Xcode will take my archived application and re-sign it for the distribution certificate I just chose and in this case I hit Share Via Email so it's going to put it in an email. Now, my Beta testers are also going to need the provisioning profile for that so I'm just going to go ahead and drag that in there too and sign this out to Beta testers. Now when your Beta tester gets that, they install the Provisioning Profile and the app and they are up and running.

So now we've sent that out to our Beta testers and we got some feedback, oops, we got some feedback that there was some bugs in it. And let's imagine for the moment that in the process of fixing the bugs, I also broke this icon again. SCM error, I screwed up a merge, I lost that change, whatever happened. So I fixed my other bug in Xcode that the Beta testers had found. And let's say I just went ahead and did Build An Archive and I ignored this warning.

I do have another archive here because it built successfully, it was just a validation warning. 4345 that's the one I just did, okay, so now I'm gong to submit this application for Online Validation at the store. We're getting closer, we're done with our Beta test, the bugs have been fixed, now let's see what the store says.

So I'll put in my password, user name, again, it's similar to what we saw for exporting or sharing an application with Beta testers. I'm prompted for a certificate to use, now when I'm doing the store, either submitting or validating, I'm going to need to choose my iPhone distribution profile.

And this application is the application that's on the store. The one that you registered with iTunes Connect, so I'm going to tell it that I'm submitting an application for validation that is Picture Viewer and I'll validate it. And it's done and it comes back and Xcode tells me that Photo View has failed the validation because of the following issue. You're missing the icon again. Okay, well that's an easy fix, we know how to fix it, we'll go back through our process, add it to our info Plist and get it done.

So let's do this one more time. Now we're going to take a look at another new feature in sharing which is Enterprise App Deployment. Let me add this back in.

Alright. So we've built our app successfully, let's build an archive once again. So now you can see the value in this organizer as we're going through builds that we're going to do things with. I'm actually saving them out and I can keep them for a long time and go back and see which build I sent to the store, which build I sent out for Beta test.

So let's choose the latest one and I'm going to share the application and I'm going to do, I'm going to do my AdHoc distribution and I'm going to distribute it for the Enterprise. Now, what it's going to ask me for is a bunch of information that's needed for the manifest file to put on the web server. So this is the URL where it's going to, where's it's going to be downloaded from and a title

It's an awesome app.

Then also the URL to the large image for the app and a URL for the small image. And it's going to ask me where to put this and I'm going to say put it on my desktop. Now this is everything you need for Enterprise App Deployment. At this point, it builds it, it takes your built application, again, signs it, puts it in a IPA and builds the Plist or the manifest file that's used for Enterprise App Deployment. We can get rid of that.

So that's kind of it for our quick tour of the features. I hope you guys all appreciate and see the value in some of the Build and Archive features that we've put into the end of Xcode and we hope it helps you guys manage your builds as you prepare them for the store and help you do good Beta testing and in the end, get a fine selling product. So that's it for me, I'm going to give it back to Mark. Thanks a lot.

Thank you Chris. So, I hope it's much clearer now and you are all ready to ship and you know how to take advantage of Xcode to structure your project, to test your app and to manage your life cycle. We do welcome your feedback so we intend to have a Q & A session right now.

Before we go to that I want to provide you with a little bit more information, if you have any questions, contact Michael, who is right there. You can go to the iPhone Dev Center, we have Developer Forum that are very active and we do monitor all of them. Please go there.

Apple developer forum, also of course, we have a lot of really neat sessions. One is already done of course, it's the part 1 of this thing. You can also attend sometime this afternoon, How to Automate Your User Interface. I do encourage you to look into that. It's very important, it's very interesting, it's a great feature to do automatic testing of your apps. You can also learn how to better use Interface builder, great tool and of course the Introduction to Xcode 4 before you go to Acquisition With iTunes Connect.