Good afternoon everyone. Welcome to Session 301, Mastering Xcode for iPhone OS, I mean iOS development. I'm Todd Fernandez and I manage the Xcode iPhone tools and Dash Code teams, and I am very happy to be here with you today to tell you about all the great new features in the tools in the new SDK.

But I'd like to start the session by posing a question. Why are you all here? I'll even hazard an answer. I believe you're here to learn how to get the most out of your development tools, so you can create and app that earns a Five-Star review. Am I close? All right.

But let's be honest, what are those five stars, what are they really all about?

But how do you get there? Well, I think you've made a great start by coming to WWDC10, the center of the app universe. And for the next hour, I'd like to be your guide on a journey through the iPhone development experience, iPhone development universe, where I will orient those of you new to the platform, as well as tell all of you all about the great new features that we've added and the new tools. Now, as an aside before we really get going here, for those of you Star Trek fans, I confess that I was much happier about this journey to the stars metaphor before I knew I was going to be wearing a red shirt on stage.

I'm just really hoping that the stage represents the bridge of the Enterprise and not an exotic planet where I've been sent as part of an away team. And then I've got this weird earphone, I feel like I'm part of the Borg to, that's the end of my Star Trek. Let's get started.

So, in fact, this is the first of a two-part series of sessions. Again, this afternoon I'm going to give you a tour of the complete development cycle, and then tomorrow morning, we're going to go deeper in several critical areas, which I'll identify as I go through the content this afternoon.

Again, today we're going to start with a tour of the complete cycle. I also want to make clear at that outset that I'm not going to talk about Xcode 4 this afternoon. While we're very excited about Xcode 4 and we hope all of you are as well, today we want to help you get ready to get your app into the App Store as quickly as possible, and for that, you're going to be using the new iPhone, iPhone SDK 4 and Xcode 3.

All right, well, how does one get started on this journey? We're going to start by talking about developing your app. And, what's the first thing you need to develop a great app? A great idea. Now, I can't help you much with that, but once you have your great idea, that's where the tools come in. And, Xcode provides a number of different templates to get you started to turn that great idea into a great app.

There are number of different template types, depending upon what kind of application you're building. You can also decide whether you want to create an iPhone version of that template, iPad, or we hope universal, which will then run on all of the iPhone OS devices. All of our templates create working apps right out of the box, so it's very easy for you to get something working immediately and start experimenting as you start learning the frameworks, and add new to functionality that your particular idea needs. For those of you with existing iPhone projects, we also make it very easy to upgrade that project to also build a version of it for iPad.

Simply select the Upgrade Current Target for iPad menu item from the project menu, and you're ready to start customizing it for iPad. There are a number of important build settings that control, first, what API's your app uses, and we'd really encourage you to always use the latest SDK. And a couple of other settings that control which devices and which OS versions your app supports, and were going to talk a lot more about this tomorrow.

Finally, this is where your expertise comes in. Where you actually use the tools to start creating the user interface, the behavior of your application, and there's a variety of great tools to do so. For an Xcode source editor and all the productivity features to help you write that code from, and learn the frameworks and new API's, Interface Builder to build your user interface, Xcode's build system and especially the Static Analyzer, which you can use to find complicated bugs in your code and then walk, have Xcode explain how, in fact, the bug occurs so that you can understand and fix it.

And finally, the integrated documentation, especially Quick Help, which is great as you're learning UIKit and the other frameworks you need to create great iPhone apps. It's very easy to access that information right from the Source Editor. But instead of talking more about this, I thought it would be better to have Jacob Xaio come up and give you a demo. Take it away Jacob.

Thanks Todd.

Okay, let's get started by creating our new iPhone app project. So, we use one of these templates, and as you can see, they're quite a few here. Some of them are iPhone only, and some of them are iPad only, for a few of them, you can pick between either an iPad or an iPhone version, but I'm going to use the Window based application template, because I want to create a universal application.

Ok and here's our new app project. And one of the great things about these templates is that they're ready to go right out of the box, so I can just hit the Build and Run button and it will launch into simulator. And you can see this is using our new iPhone 4 simulator, so it looks great, but it's a little blank now, so that's where your great idea comes in.

Ok, let's see what this template has set up for us We have a shared group, where you can put your code and resources that you want to share between the iPhone and the iPad version of the app, then you have an iPhone group where you can put your iPhone specific code, and you can see we already have an app delegate and an interface that will be used for the iPhone version. And similarly, we have the iPad group where we have the iPad's app delegate and its own interface. Okay, let's get started with the iPhone version.

I'd like for my application to have a translucent status bar, so let's set that up here at launch. Okay, I'll send a message to application, and you can see that Xcode does auto-completing the Xcode application of the application variable name. And the same thing happens when I set the, with the Set Status Bar style method.

In fact, even this enumerated type, I can just hit Option-Escape and I see all the possible completions for that, and this is really great for going through an enumerated type like this. I can just see which one I want, which is black translucent. Okay, next let's add a method here to show some information about our application.

And I'm going to use a UIAlertView to show information about the iPhone app. Oh, I forgot to add the first bracket here, but Xcode can do that for me too if I just add the completed, the end bracket here. It'll just insert that for me. And now, I have this init method, and you can see it has these placeholders for me to put my content, and I can hit Control-Slash to quickly jump between those, and it makes it easy to fill out this long method.

Okay, now let me show the alert. And another great feature that Xcode has is Build and Analyze. I can just choose that and it will build my application and look for any potential problems, which it looks like it's found one. Says we may be leaking an object here, and I can just click on that and it will show me the flow of the application and where the potential problem is. So it looks like we're creating this alert view here, but then when we're done with it, we're not releasing it, so let me just add the release method here, and we'll build and analyze again, great and the problem's gone.

Now I'd like to trigger this method from Interface Builder in a button, so to get it to show up in Interface Builder, I just use the IBAction return value, and copy this method into my header. Now I can open up the interface file in Interface Builder, add a button and when I control drag it to my app delegate, you can see the method I added right here.

Ok, now let's build and run this new version of the application. Great, here's our translucent menu Status Bar and the Info button with our alert. Now I'll go Home and back to Xcode, but Xcode says that the applications still running, and that's because of the new multi-tasking in iOS 4, so the application really is still running suspended.

And, if I want to confirm that, I think one of these methods is related to that, I think it's this one, but if I want to find out more, I can Command double-click on the method to jump right to it in the header file, here in UIApplication.H. If I want to see more information, I can Option double-click and I get the Quick Help popup, tells me a little information here.

But if I really want to see all of the documentation, I can just click on the book, and that brings up the full documentation here. Yeah, this looks like the one I want, so I'll just go back and set a break point here, and now when I bring the application to the foreground again, yep, sure enough, it's stopping here at the break point.

Okay, now let's work on the iPad version. I'll just copy this method in, and of course, I need to change iPhone to iPad, and you know, on second thought, this iPhone alert is not the best variable name here, so I should probably change that to be more general, and for that I can use Edit All In Scope, by selecting this variable name and then just picking the Edit All In Scope menu item, and this, for this Xcode, we'll go through and find all occurrence of this variable in the current scope, and as you can see, its changing them all at the same time.

Ok, now let me go to the iPad interface, and add the button, and when I Control drag, it's not showing up here. That's because I didn't add it to the header file, that was my mistake. Let me just copy it, and use the Go to Counter Part button, which instantly just takes me to the header file. Ok, now I should be able to just Control drag in, and there it is.

Then I can use the Overview popup to switch from the iPhone simulator to the iPad simulator, and when I build and run again, the simulator will change to the iPad mode and here's the iPad version of my app with the popup, with the alert view. Ok, back to you Todd.

Thank you Jacob.

So just to recap, we've seen using a template to create a new universal app project, we've seen several of the important source code and interface editing workflows as Jacob built user interface for that app and wired it up to his source code, he used Quick Help and the Integrated Documentation Viewer to explore the delegate method that gets called when the app is unsuspended, as well as a little bit of building and debugging in the iPhone simulator. So, let's continue on our journey.

We've started developing our app and we've done a little bit of building, but let's talk a little bit more about building. So, the device versus simulator; Jacob used the Overview popup to switch between which simulator he was running in, but we've also just greatly simplified that choice between device and simulator. You just chose your destination device and then if you've got more than one device, you can choose a specific device right from the Overview popup.

And, in fact, depending on how you have those build settings I mentioned earlier, like deployment target, that will control which devices appear here, for example, if your app is configured to build, to have a deployment target of OS3.2 and you have a iPhone running 3.1.3, it would not appear in this list. Similarly, you can choose Simulator at the top and then if your deployment target is set appropriately, you'll see all the simulator versions that are compatible with that version.

Like Jacob built, the universal app, which is configured with a deployment target of OS3.2, which show both the iPad simulator and the iPhone simulator 4.0. There are few new things in the simulator in iOS 4. You can now build once and then simulate on multiple OS versions, just like Jacob just showed you. The reason this is possible now in the OS4 SDK is that it's the simulators now using the modern objective C run time.

You get many benefits from that, but one of the most noteworthy is you no longer have to declare your instance variable for properties. However, there is a cost for that benefit as well as again the ability to simulate on multiple OS versions with the same build, in that, this is an ABI change, so that any code that you have compiled for the simulator, libraries, other code that you're using will need to be recompiled with the new SDK. Moving back to the device, this was actually introduced in 3.2 SDK, where we now incrementally upload your app to the device as you make changes.

Only the change bits are uploaded. For those of you who have large resources, whether its audio, video, photos, what have you in your app, this can save you a lot of time and give you much faster turnaround as your Edit, Build and Bug cycles. Course, since the simulators running right on your development system, it's still going to offer you faster turnaround then uploading it to the device.

But you really need to test your app on every model you support. Although you can save a little bit of time, I don't think you need to test both the iPhone for white, and the iPhone for black. To further motivate you to test on devices, let's talk about why it's important to do so. Well, some of this may seem obvious, but let's talk about it.

The Mac, of course, where the simulator's running, is a far more powerful and less resource-constrained device than any mobile device. And what that means is that performance analysis you do on, in the simulator, which can absolutely help you find and fix serious bugs in your application, is still not going to accurately represent the behavior of app running on devices.

Further, a lot of the hardware capabilities that the device has, whether it's a compass, the GPS system, the camera, or now on iPhone 4, the gyroscope, those just aren't available in the iPhone simulator, so if your app uses those facilities, you'll need to do, you'll need to test them on the device. And finally, though the iPhone simulator does a good job of trying to allow you to simulate multi-touch gestures, there's really nothing to substitute for actually interacting with your app on a device to really understand how it's going to feel for your users.

Now again, it's your, you need to decide exactly which older OS versions and devices that your app is going to support. If you are supporting those older devices, you need to know how your app performs for all of your users. And what that means is that you need to keep devices running older OS versions, because it's not possible to rollback the OS version to an earlier version on a device.

So I think this, I'll just let you gaze on this for a while as a public service, you may not have seen this before, but this is the device line-up as well as the OS versions that are supported on each one, including the new iPhone 4 there next to the iPad. Just kind of, drink it in. There will be a pop quiz later.

All right, well we talked about building on the iPhone simulator and a little bit on the device, but, of course, to build for the device, you need to have your device provision. So, let's continue on our journey. So provisioning profile you need on your development system in order of Xcode to sign your apps so that it can run on a device, and you also need that same provisioning profile on our device so that it will authenticate that app and allow it to be run. Now, I want to ask a question.

How many of you wish the provisioning was as simple as that animation? I have some good news for you. Hopefully some of you saw my demo yesterday, but we've added automatic device provisioning in the new SDK. We've worked really hard to make those simple cases simple and allow you to get started developing on a device as quickly as possible. You joined the developer program and everything else is on the iPhone provisioning portal, and everything else is done in Xcode.

Use that same login information from joining the program, you enter it into Xcode, and, in fact, Xcode will prompt you for this when you add a new device and you don't have provisioning information. Once you've entered that login information, Xcode will communicate with the portal, determine that yes in fact you are a member of the program, and then check to see if you already have provisioning information.

If you don't, Xcode will ask if you'd like to get started creating the code sign in request that you'll need to get your development certificate and it will create it for you, upload that request, as well as your device information from the device you've connected, up to the portal, which will create the certificate, create a provisioning profile containing that device and certificate and download it to your Mac.

Now for those of you who are working in teams, this same process works for multiple certificates, multiple engineers, and multiple devices. And the way it works is it adds a wildcard app ID so that this particular provisioning profile can be used to develop any application, and all of that gets wrapped up into a single profile, which is then downloaded and installed by Xcode on your Mac.

Now, once you're making some changes, whether it's your team's growing, you're adding a new engineer, or you're buying now iPhone 4, so you can test on those and you need to add new devices, Xcode will automatically update that, upload that information to the portal, where a new provisioning profile will be generated and downloaded back to your system.

And at any time, any of your team members can simply click the refresh button in the provisioning profiles source in the organizer to get the latest profile or profiles for your team. Now I say profiles, because once you get past the simple cases, there are actually some reasons where you still need to create a custom profile on the iPhone provisioning portal. In certain, for certain iOS features, such as Push Notifications, they actually aren't supported with a wildcard app ID, so you'll need to create a custom profile containing and app ID for your application.

Another reason is distribution-provisioning profiles. Once you're getting ready to distribute your app, you'll need one of those, and that needs to be created on the portal. But there's still more good news, because Xcode will still manage those for you once you've created them on the portal, it will download them automatically for you, and as changes are made to them, they will be kept in sync with your development systems.

Developer Profiles are a great new feature we added in the previous SDK release, 3.2. And what Developer Profiles are is all of the Code Signed Certificates and Provisioning Profiles on your development system. You can export that into a single file, which you then take to another system, so that if you get, you've been working on a desktop and now you've got a new laptop, you can just export your provisioning, your Developer Profile from your working development system, move it over to the other system, and you're immediately provisioned and ready to go develop there.

Finally, I want to give a brief commercial for some more sessions coming this week. There's some great debugging features in Xcode, especially targeting some unique features about iPhone OS, such as Push Notifications. The Xcode Debugger allows you to configure your apps so that when you launch it, it actually doesn't launch until it receives a Push Notification, at which time the debugger will attach and allow you to debug.

Instruments is an extremely powerful tool that makes it really easy to gather a huge amount of data about your apps behavior, running it in the iPhone simulator or on the device, and then also help you analyze and make sense of it, to find and fix performance problems in your code.

There's also something new in iPhone OS 4, a new UI automation feature that is part of Instruments as well. There's a new Instrument supporting that that allows you to run a script against the application running on the device so that you can automate your user interface testing. And we think that's a great addition to Instruments, especially in combination with the other Instruments that can gather information about memory usage and performance while those tests are being run. And with that, I would like to ask Chris Skogen to come up and give you a demo of these last two sections about provisioning and building.

So I'm going to give you guys a quick demo of debugging and using Instruments on the app that Jacob started in his previous demo. So we're going to bring up Xcode, here's Jacob's demo. We're going to start by running the simulator and looking for issues that we might have found or might see in the process of running it.

Here's Jacob's app, oh my goodness, that's a horrible typo. All right, so let's go fix that. Now, I'm sure somebody will see where the bug is right away, but I'm a bit of an idiot, so I'm going to put a breakpoint here. I'm going to go up and enable breakpoints and I'm going to hit Build And Run on the simulator, and I will stop when I get to that spot. Wow, what could be wrong here? Oh look, I'm going to change this to app, perfect. All right let's remove this breakpoint. We'll stop it, and we'll run it again on the simulator.

Great, pretty straight forward. I know you guys write much more sophisticated code than I do, so , you'll have to bear with me. Now we're going to go up to the Overview popup, now that we see that its working right on the device. We're going to go up to the Overview popup and we're going to switch over to an actual device and see what this thing looks like. So I just choose Device, make sure my breakpoints are enabled, hit Build And Debug. Wow, look at all those fingerprints.

Now we're waiting for it to run, oh, something happened, doesn't look like it's actually run, yep, bad access, where is it? I was accessing my mutable data here and I was setting zeros in every 10, 24th position, don't ask me why, and it seems to have crashed, so I'm going to roll back up and, holy cow, I activated the, I allocated way too much data for a device.

This is actually a good point, back to what a good reference back to the point Todd was making about always build and run on device. This app ran fine in the simulator, the minute I put it on the device, the device cannot stand that big of an allocation, it just doesn't run.

So, I'm going to go ahead and fix that, stop it, I'm going to build and run on the device again, here it comes, or there it is, and now I can go ahead and hit Show Info, this is my iPhone app, perfect. My app seems to run fine on the device now.

So let's go ahead, stop that and let's take a look at Instruments and let's try to profile this app. We've actually gone ahead and pre-set up a template for Instruments that's going to use the UI Automation tools, and the new Time Profiler, so I've got that here in Automated Time Profile. I went up here, go back here, we'll start over.

See it's an automations script, so you want to run it multiple times.

Chris:Exactly. So I just went up to Run with Performance Tool, choose Automated Time Profile. Now it's going to launch Instruments, it's going to set Instruments up with a UI Automation tool and also the new Time Profiler. Down here you can the Java script that we wrote to actually put the app through its paces.

It's basically just going to go ahead and tap the button for us, and take a screen shot before and after tapping the button and record the results. So right now it is actually already running and you see down here, here's the Tap Show Info button, before the tap, there's the screenshot that we took after the tap, there's the screenshot and the Show Info button tapped test actually passed. Script is completed so we can go ahead and stop that.

And if you guys want to see the automation on the device, I'm going to run the same process again, and we should see the device automatically push the button, show that, close it and we're done. So what is in this Time Profiler that we can see now? Well, we can actually see, if I go over here on the left and I click, Hide Missing Symbols, and Hide System Libraries, I'll just see all of the entries for the code in my project as they were running on the device.

So here, we can see most of the time, 72% was in Show Info, so if I double-click on that, it will actually show me the code in my Xcode project that I was using at the time. So, that's it, that's a pretty quick tour of the new Instruments features and also debugging on both the simulator and the device, back to you Todd.

Thank you Chris. Thank you. So just again to recap, Chris built the device and debugged and device in simulator, and gave you a brief peek at Instruments. I hope, again, you'll be encouraged to go check that out in sessions later this week and also in the labs.

And the combination with your new UI Automation Instrument and all the existing Instruments as well as the Time Profiler Instrument that's new in iPhone OS SDK4, just make Instruments even more powerful and that time line there you can add multiple Instruments and be able to correlate all that information with individual events that you're sending with your UI Automation script, it's very powerful.

All right, well we've developed our app, we've built it on devices that have been provisioned, now our app is clearly ready to go. You remember that great idea I said you were going to come up with? Well clearly we don't have it. Now it's time to distribute our app.

So one of the great new things that we added in iPhone SDK 3.2, is that instead of previously when Xcode was pretty much done helping you once it built your dot app, we now have first class support for a variety of powerful distribution options in Xcode and the latest SDK's. It all starts with allowing you to create archives of your application. You can think of this as kind of a frozen build of your app.

One of the things that you have hopefully known to do, that we documented, is that, in order to be able to symbolicate crash reports that are generated by that particular release of your application, you need to preserve the descend that was created from that specific build of your application.

Without it, you can't get it back and you can't symbolicate those crash reports, so you've probably been doing that manually. Well archives do that automatically for you in Xcode. Another huge advantage of using archives, is that previously it was only possible to prepare your app for distribution by building it and signing it in one-step in Xcode, which meant that you couldn't actually test that final release build of your app that you were going to submit to the store or distribute.

Archives separate those two steps so that you can freeze that build of your app, test it thoroughly and make sure that those bits are good, and once you're sure they are, then you can use that frozen build of your app as the source for a distribution without having to rebuild.

Steve made clear that one of the most common reasons that your apps aren't approved within that first seven days is because the app actually crashes, and with archives we've made it really easy for you to avoid that. You simply choose the Build and Archive menu item from the Build menu, and it creates your archive.

So what actually is an archive? It's your app, your dot app bundle, and that unique descend that was built when that app bundle was build, and the Xcode creates a POS with metadata, so that it appears correctly in the organizer, so you can look that and find it, that's what it is today.

You may be wondering what's the difference between this new archive and a snapshot or a tag of my source that build that app in my repository. Well, even if you have the exact source code that was used to build that released version of your app, each build is unique, and if you rebuild that same source, you will not get an equivalent descend that would allow you to symbolicate crash reports, so that your source code cannot replace an archive. Once you have your archive, you can use the new validation features in Xcode.

Validation performs many of the same tests that will be run on your app once you submit it for app store review. It detects many common problems, and often suggests fixes for them. We really encourage you to take advantage of this functionality and validate early and often in your development cycle. We have several different ways to do so, you can actually, there's a way to run validation always on build, and we'll talk about that more tomorrow. And then there's when your preparing to distribute, when you can run a validation on an archive.

Before you can run the validation on an archive from the organizer, you will need to have configured your app in iTunes Connect, which I'm sure you're all familiar with, but the manager application areas where you would set your application, its bundle identifier and all that information before you can actually validate your app.

I just want to briefly mention another important organizer functionality, the ability to take screenshot of your device, which can be used for many purposes, including setting up your marketing information on iTunes Connect. You can also use it as the source or literally the launch image for you application. It's often useful for debugging, we saw taking screenshots as part of our automation testing, and, of course, very useful for documentation. And, Xcode organizer makes it very easy for you to take screenshots of your device.

Returning to validation, in the new archived application source, you'll see all of your archives at the top, organized by bundle identifier, and at the bottom, there are three different buttons for different sharing options; first being Validate Application. When I click that button, Xcode will ask you for your iTunes Connect login information, then ask you for which distribution provisioning profile you want to re-sign your app for this particular validation and which application you want to validate. It will then re-sign your app with that distribution provisioning profile, package it up, upload it to iTunes Connect, the test will be run there, and it will be reported back to you right here in Xcode.

There are many different types of errors that can be found an reported this way, and we'll talk more in detail about all of them tomorrow, but in fact this one, I just am missing that iPad sized icon and where I need to fix that in my info plist. So once, once I validated my application, there are many different options for sharing. You can use your Ad Hoc distribution provisioning profiles for these to do your beta testing or distribute your app to a limited audience.

Xcode will re-sign your app, package it up again, and attach it to an email, if that's how you want to send it out, or alternatively you can just have it save that package to discs so that you can post it on a website or distribute it however you choose, sneaker net if you must. When you go to a larger audience, you may want to take advantage of the new Enterprise Distribution feature that was introduced in iOS 4.

Xcode will actually help you create those files, and again, we'll go into more detail about that tomorrow. This scales much better that Ad Hoc Distribution and can support, you know, larger enterprises with getting your app directly wirelessly to your employee's devices. And , in fact, there's a session immediately following this session where Chris will be performing another demo, immediately following in Nob Hill about managing mobile devices, where they will also discuss this feature. They also have a lab coming up later this week.

Finally, once you've insured that this application is good, it's the one you want to send out to your users, you can use the final option, Submit Your App to iTunes Connect. We'll, again, perform the same test that validate application does, and then forward your app for App Store review. So that it can get to its ultimate destination, the App Store.

So with that, I would like to ask Clark to come up and show you a demo of the demonstration features, as well as a little bit more about the organizer features that are very useful to you in developing your apps.

So I'm going to start by opening this app you may have seen before in Todd's demos yesterday, it's just the Picture Viewer App. Now, say I'm ready to start distributing this app to a group of beta testers or just some friends, whatever, I can start by choosing the Build an Archive command.

Because I didn't have the appropriate provisioning profiles on here, I can go, just hit Refresh, and because I've already logged into the portal, it downloads them all for me, and now, I can come back to Picture Viewer, that builds fine. So, I go to Build An Archive, you see it added another archive to this list, I made a few earlier today, and say for instance I wanted to go validate it, so I enter my iTunes Connect info, hit Validate, it defaults to choosing a distribution certificate, which is what I want in this case and Picture Viewer is the name of app on iTunes Connect, so I hit Validate. And, just as in Todd's example, this app doesn't have an iPad-sized icon, and to fix that I would, of course, go add one and add it to the plist. Now, say for instance I wanted to, as I said before, share this with a group of beta testers.

I went to Share Application, again, you'll see that it has this selected by default, if it didn't select the right one by default, I could just explicitly choose my Ad Hoc profile, and in this case, I'll chose save to disc, I want to put it on the desktop, give it a name, and its created all I need to send out, it's the IPA file, I can just email that, put it on a webpage, whatever, get it to my audience.

Additionally, there are other options, email would have created the same file and just opened up mail with it as an attachment ready for, ready to be sent out. I also have the Enterprise Distribution option, which will query me for all the information that I need in the manifest.plist file, of course there will be more about this in the, in the managing devices session later.

Now also, submit to iTunes Connect is basically identical to validate in every way, except that after validation passes, it actually goes and does the final step of submitting it to the App Store for review. That's generally what's involved now with distribution. There's a lot fewer steps than before, and they are a lot more simple and straightforward.

Now I'm going to show you some other things in the organizer that we've added in 3.2 and 4.0. One is the Developer Profile, which Todd mentioned before. These are all of the signed certificates and provisioning profiles I have on my system. If I were to export this, give it a password, because this does contain private keys so it's important that it's protected.

Now I could take this file, import it on any other machine, even that had never been set up for iPhone development yet, and I would get this same set of profiles and signed certificates, and I'd be up and running. Additionally, as you saw before, if I say deleted one of these accidentally, I could still refresh and get it right back. And with that, I'll give it back to Todd.

Thank you Clark. Just to recap again, we've seen the various distribution features, including validation and sharing through Enterprise Distribution as well as simply packaging up for Ad Hoc Distribution. There are a number of other features in the organizer; taking screenshots, symbolicating your crash logs, which you can simply drag into the Organizer Crash Logs tab, that's where you restore your devices, and of course you've accessed the device console for debugging message or seeing what going on in your device while you're working with it.

Of course, all of this works with Xcode 4 as well, and we're really looking forward to your feedback on how Xcode 4 works for you for your iPhone development, but again, you still need to use Xcode 3 for your work to actually submit your apps to the Store.

I also want to emphasize that we made it very easy for you to experiment with Xcode 4 because its completely compatible with the Xcode 3 project format, so it's very easy for you to work on your same project with Xcode 4 to see how it works for you and give us feedback and then to go back and build your app in Xcode 3 when you're ready to submit, and ultimately get your app in the Store and earn that Five-Star review.

So with that, I will conclude and point out some of the references. The Dev Center, which has lots of great resources for you as iPhone developers. The developer forums, which I definitely encourage you to go and check out and help each other out and we will certainly help you there as well. Michael Jerkewitz is our developer tools evangelist, and you can submit questions and comments to him as well.

We've got a number of great sessions later this week, and I wanted to kind of give you a commercial for many different features that we've just touched on in this session, whether it's Instruments, Interface Builder, Xcode 4, the user interface testing and of course the second half of the session tomorrow morning.