I'm Stefan Lesser, Technology Evangelist at Apple. As a developer, you spend lots of time with our development tools. However, there's a chance that you are so focused on writing code that you haven't tried many of the advanced features we introduced to Xcode in the last few releases. And they can make app development so much easier.

In this presentation, I'm going to show you some of the latest techniques which make it easier for you to create state of the art apps for iOS. First, let's make sure your projects are ready for using the latest best practices. Then I'll cover Storyboarding, a major new technique to design your app's user interface, giving you a complete overview of your application's flow in one single place.

You will learn about behaviors, which is a great way to make Xcode adapt to your own personal workflow. And finally, I'm going to show you how Xcode helps you with setting up your test devices and how you can use archives to distribute your apps. So, let's get started.

Modernizing your project. What does that actually mean? So you've just downloaded and installed the latest tools and the latest SDK, so you're all set, right? Not quite. It's not enough to just install the latest version of the tools. You should also ask yourself some additional questions. Are your build settings up to date? What's your base SDK? What's your deployment target? And which compiler do you use? Let's see why these questions are important.

How can you make sure your build settings are up to date and you use the latest best practices? Well, how do you know what the latest best practices are? Xcode knows. So when you open a project, Xcode will automatically check your project and build settings and it will make you aware of anything that needs to be updated. If Xcode finds any settings that should be updated, this Project Modernization Workflow sheet comes up.

You just click Perform Changes and Xcode will change all these settings for you automatically. Also, you can deselect any changes you don't want it to make right now and then get back to this sheet later from the project navigator. But really, if Xcode brings up anything here, fix it. This way you make sure your project confirms to the latest SDKs and the latest best practices, which will save you lots of time later and make sure your project is future proof.

Then there's the base SDK. You should always use the latest SDK. Of course, this is the only way for you to leverage new APIs and frameworks introduced in that version of the SDK. But even if you don't use them today, you will also benefit from bug fixes and performance enhancements that we add to every operating system release. So make sure your base SDK setting always points to the latest SDK.

And then there's the deployment target. This is what you set to support any previous versions of iOS. Set this back to the earliest version of iOS you want to support. Every API which has been introduced as part of this version you're targeting, or APIs from the versions before that, you can use these without any special considerations. But when you move this setting down, you create a gap between the base SDK and the deployment target.

And new APIs introduced in the versions as part of this gap will be dynamically linked. Which means you can and you should use them. But whenever you do so, you must not forget to check for their availability at runtime. And you should also have a fallback in place so you can still deliver a great experience for all of your users running the latest and previous versions of iOS.

Finally, let's talk about the compiler. Since Xcode 4.2, GCC is no longer shipped as part of Xcode. The LLVM compiler is the new default compiler. We finished our compiler transition to LLVM for a couple of important reasons. LLVM is designed for speed, flexibility and modularity. It compiles about twice as fast as GCC. At the same time it generates better optimized code. And we are using LLVM technology as the basis for many features in Xcode, like Code Completion and Fixit.

And LLVM enables us to implement support for new language features, which allows us to do amazing things like automatic reference counting. Arc would not have been possible without LLVM because of the way Compiler and Runtime work together. Arc might very well be the feature that has the most impact on how you develop apps. And this is why we have a whole session about Arc. So make sure you check out the Arc session as well.

And back to your compiler settings. If you haven't yet done so, switch to LLVM and make sure your project builds with LLVM. Okay, so this is how you keep your project up to date. Update your build settings to the latest best practices. Make sure you always use the latest base SDK. Choose your deployment target wisely. And switch to LLVM so you can use great features like Arc.

Next, let's look at Storyboarding. At some point in your development process, preferably early at the beginning, you need to think about your app's design. And you need to figure out two things. What are the different screens you want to have in your app? And how do you navigate between them? So let's say you want to create a very simple app to keep track of a list of things you care about.

For example, all the great books you still want to read. A simple reading list app. So what are the different screens you want to design for this app? Well, first you need the list of things, in this case the reading list. This could be just a simple table view.

Then when you select a row in that list, you want to see the details of that item. For books, this would be something like the title, the author, maybe some notes, and maybe a picture of the cover. So you need a detail view. And then of course, you need a way to add new items to the list. So you put a little plus button on top of your list and when you tap that, you get to another screen where you can enter all the information about that new book.

Okay, so now you have a rough concept of your application's flow. And once you know which screens you need, UIKit makes it very easy for you to model these with ViewControllers. For each screen you create a view controller and then you configure the views in Interface Builder. And so you end up with three view controllers.

So the screens map nicely to view controllers, but what happens to the transitions? What happens to all the arrows on your UI sketch pointing from one screen to another? Well, they used to end up all over the place in your code. Whenever you transitioned to a new screen, you wrote code to instantiate the new view controller, prepare the necessary data, and then transition to it. But now with Storyboarding, we introduce a way for you to model these transitions in one single place, together with the rest of your user interface.

And that's the storyboard. This is what it looks like in Xcode. It gives you a much better view over your application's flow. And you can see all your app's view controllers on one big canvas. And you can now define the transitions between them right in Interface Builder as well. So let's take our reading list idea and see how easy it is to turn that into an app with Storyboarding.

The first thing you need to do is to create the storyboard. And this means you need to lay out the view controllers and in storyboards we call them scenes. And then you need to define the transitions and relationships between different scenes. And these are called segways. So let's do this. When you create a new project in Xcode, make sure "Use Storyboards" is selected. This will create a storyboard file in your project and it sets it as the main storyboard for your app.

And when you open that storyboard, you see this giant blank canvas where you can put all your scenes. To create a new scene in the storyboard, just drag any view controller from the library to the canvas. You can put scenes wherever you want on the canvas and you can rearrange them as you like.

Now, what are scenes? Scenes are just view controllers in a storyboard. And they work exactly like you are used to from working with Nib files in Interface Builder. Just drag views over from the object library. You can move them, resize them, edit them. Everything works just as it did before. And now that you can have multiple scenes in the same storyboard, one of these scenes will be the initial scene. And this will be the one that will be displayed right after app launch.

Below each view controller on the canvas, you will see the dock. The dock gives you access to any top level objects for this scene and you can use this to wire up outlets to the view controller, for example, and you can also put any other top level objects in here as well. And that's it. That's how you create a storyboard and layout your scenes. So now let's define the transitions between them. And for this we have Segways. A Segway represents a connection between two view controllers, a source view controller and a destination view controller.

The great thing about Segways is at runtime, they take care of a couple of things for you automatically. They instantiate the destination view controller for you and they initiate the transition. So you no longer have to write this code yourself. You just define a Segway in the Storyboard.

And segues come in different styles. There's a push segue if you want to use a push transition with navigation controllers or a modal segue for bringing up a modal view controller. Now, push and modal segues work for iPhone as well as iPad user interfaces. And if you're building an iPad UI, you can also have popover segues for use with popovers and a replace segue, for example, to switch the detail pane in a split view controller.

If you want to come up with your own visual transition style, you can also create custom segues and create your own transition. And finally, there's a relationship segue, which isn't really a transition. It just defines a relationship between two view controllers, like the relationship between the navigation controller and its root view controller. So let's build the storyboard for the Reading List app.

Let's say you already prepared the two scenes for the Reading List View Controller and the Book Details View Controller. A good way to navigate between them is by using a Navigation Controller. So whenever a user taps a table cell, the details for that book come up. And he can go back to the list by tapping the back button.

To model this, you first embed the Reading List View Controller in a Navigation View Controller. And there's an "Embed in Navigation Controller" action in the editor menu. And if you do that, two things will happen. First, the Navigation Controller shows up as a separate scene connected to the Reading List View Controller with a relationship segue. Because the Reading List View Controller is the Root View Controller. And second, the Reading List View Controller now also gets a navigation bar where you can set a title and add the plus button to bring up the Add View Controller later.

Now you create a transition from the Reading List View Controller to the Book Details View Controller by control dragging from the table view cell in the source scene to anywhere in the destination scene. And then you choose the type of Segway you want to create. In this case, you want to create a push Segway. And then you're almost done.

The push segway shows up as an arrow. And the Book Details View Controller now gets a navigation bar as well. There's one more thing you want to do now. Segways are selectable objects in Interface Builder and they have attributes. So if you select the push segue by just clicking on it, You can set an identifier for this Segway in the attribute inspector. And you want to give that Segway a name so you can refer to it later on in your code.

And that's all you need to do for the Book Details View Controller. And you repeat almost the same steps for the Add Book View Controller. Again, embed the Add Book View Controller in a Navigation Controller. Although you don't really need the Navigation Controller just yet, you probably want to add things like a genre selection menu later on. And for this, a Navigation Controller is quite useful. Also, this gives you an easy way to add the Done and Cancel buttons to the Navigation Bar.

And finally, wire up another Segway, this time from the Add button in the reading list to the navigation controller you just created. And this time you use a modal Segway to bring up the AdBook user interface modally on top of the reading list. And don't forget to give that Segway an identifier as well. And this is your application's flow, all in one place in just one storyboard.

So your user interface is all wired up and ready to go. The next step is to implement your data model. You can use simple data model objects or managed objects from a core data backend. But we won't look at these things in this video as this is out of scope for storyboarding and I'm pretty sure you already know how this works and it doesn't change for storyboarding.

So make sure you have your model objects in place, some sample data to test with, and you implemented the table view data source for the reading list view controller so that it actually displays some books. And then you're ready to look into how you can pass data from one scene to another and how to get results back. You need to pass data from the reading list to the Book Details view. Because the Book Details view controller needs to know which book details it should display. At this point, the view controller transition already works. You just need to prepare and send over the data.

To do this, we introduce a new API on UI View Controller, which is Prepare for Segway. This method gets called whenever a Segway is initiated. And this is the central place in your UI view controller subclass to prepare for the transition. All you need to do is to override prepare for Segway on the source view controller. First, you check for which Segway has been initiated, as you can easily have more than one Segway starting from the same source view controller.

To identify which Segway it is, check for the identifier you set up in Interface Builder. And you should always do this, even if you only have one Segway today, because this is just how you can future-proof your code. In this case, you check for the Show Details Segway.

And then you prepare the data for the Destination View Controller. You get access to the Destination View Controller through a property on the UIStoryboardSegway object. In this case, the Destination View Controller is the BookDetailsViewController. And now you can just set the Book property on the Book Details View Controller to the book that has been selected in the table view. And that's how you pass data over to another scene.

But how can you get results back? You might not need this for the book details, but you need this when you want to add a new book. If the user taps the plus button and the add book UI slides up modally, you want to know if the user taps done or cancel. And if he taps done, the data about the new book he just entered needs to get back somehow so it can be added to the list. And finally, the modal view controller can be dismissed. For this, we use a very common pattern in Cocoa, which is delegation.

Let's see what do you need to implement a proper delegation pattern. First of all, you need a host object, which provides a way for delegates to register. That's usually a simple delegate property. It also defines the delegation protocol, and it needs to make sure that it actually calls the methods on the delegate. And of course you also need a delegate object. The delegate registers itself with the host object and it implements the delegation protocol.

So to get data back, the source view controller will be the delegate here waiting for the destination view controller, which is the host object, to call back with the data. So let's implement that. So we start with the same prepare for segue method in the Reading List View Controller, because that's again the source view controller for the second segue. But this time, look for the other segue's identifier, @Book in this case.

The source view controller doesn't have to pass any data model object here, but it passes itself as delegate. This works pretty much the same by just setting a property on the destination view controller. However, there's one thing you need to be careful about. Remember, in the storyboard you embedded the @Book View Controller in a Navigation Controller. So the destination View Controller here is the Navigation Controller. What you really want is the top View Controller from that Navigation Controller, which is the @Book View Controller. And that's step one. The source view controller is now registered as a delegate with the destination view controller.

Of course, for this to work, the destination view controller needs to accept the delegate. So it needs to provide a property for that. Note that to avoid retain cycles, delegate properties are usually implemented as weak properties or assigned properties if you don't use Arc yet, which you should by the way.

Also, you need the delegation protocol, which can be very straightforward here. You just need to consider two cases. The user actually did create a new book, and which book that is, which is the key method to get the data back, or the user just canceled the action. And then you need to make sure that the host object actually calls the delegate.

When setting up your storyboard, you wired up actions to the Done and Cancel buttons in the Ad Book View Controller. The Done action creates the new book in the data model and calls the delegate, passing the new book back as a parameter. The Cancel action doesn't need to do anything other than just telling the delegate that the user cancelled.

Finally, the delegate needs to implement the protocol and react on the delegate methods. If the user wants to create a new book, so the @BookViewControllerDid@Book method gets called, the delegate adds it to the list in the data model, updates the table view, and dismisses the modal view controller. If the user canceled, it just needs to dismiss the modal view controller.

And that's how you pass data back and forth between scenes. Now, for this example, you created a new project from scratch. You probably want to know how you can use storyboards in your existing projects as well. If you want to migrate an existing app to storyboards, there are two strategies. The first strategy is wholesale conversion. To do this, you start with adding a storyboard file to your project.

And then you rebuild the whole user interface in that storyboard. Which isn't as crazy as it sounds, because this will also remove lots of code from your project. All the view controller instantiation code and all the code for transitioning to another scene can be removed once it's part of the storyboard. And the remaining code will be much cleaner as well as you have all the data passing between scenes in well-defined places like Prepare for Segway.

Once you've finished building your UI in the storyboard, you replace the main Nib file setting with the main storyboard file setting and you're done. Now, if you're looking for a more incremental approach, you can do this as well using new APIs. You can load any storyboard file on demand at runtime with the UIS Storyboard StoryboardWithName bundle API.

And with this you can migrate to storyboards step by step, or better, view controller by view controller. For example, if you implement a new feature which requires new UI, just create the new UI as a view controller in the storyboard and load them on demand. To instantiate the initial view controller of that storyboard, use the instantiate initial view controller API.

And you can also instantiate any other view controller from a storyboard by just using an identifier. And there's even more you can do with that API. Basically, the whole storyboard is available to you at runtime. So if your app has a very dynamic user interface, you might want to look into the UI Storyboard API in more detail.

And this is Storyboards. All your applications flow in one place. Now we've looked at your applications flow for quite some time now, so let's look at your own personal workflow now. Let's look at behaviors. With behaviors you can make Xcode adapt to your own personal workflow. Behaviors define how Xcode reacts to events. There are lots of different events Xcode can react to. For example, during building, testing, and running your app.

An Xcode can react with lots of different actions. It can just alert you with a sound or by displaying a bezel alert. Or it can reconfigure the user interface to show things that you need in that situation and hide things you don't need. And you can even run custom scripts. But the best way to understand the power of behaviors is to actually see that in action. So let's switch to the demo.

In this demo, let's focus on what happens when you debug your app. Before we change anything, let's look at what Xcode does by default. So I just run this application here. And notice how Xcode brings up the bezel alert that the build succeeded. And it also brings up the simulator. I've configured a breakpoint in this demo. So let's just hit this breakpoint.

And you can see Xcode changes the user interface. It switches from the project navigator to the debug navigator and it also brings up the debug area down below. and you can look at the local variables and also you have the console over here waiting for input so you can do whatever you want to do while debugging your application And once you've done with that, you can just continue. And Xcode will bring up the simulator again. And now when you stop running your application, you can see that Xcode brings up the project navigator again and it also dismisses the debug area.

Now, let's say you really like working in the console and you want to configure Xcode in a way that it brings up the console automatically whenever you debug your project. And you can do this with behaviors. For that, let's start with creating a new tab. Go to the File menu and choose New Tab and you can also hit Command T. And let's give that tab a name by just double clicking the tab. Let's call that tab Console.

And now let's configure this tab the way we want the console to look like. So we don't need any navigator, so let's get rid of that. We don't need any utilities here, so let's get rid of that as well. But we want to see the console and the console is part of the debug area. And we want that to be as large as possible, so let's make that larger. And let's focus on the console here.

That's a nice view to work in the console and we want to bring this up whenever the application runs. Now I can just close the tab here again because the great thing about Xcode is that it's remembering all the settings you made to the user interface in the tab. So whenever you bring up this tab again, it will look exactly like you left it.

And the way to bring up this tab automatically is by using Behaviors. So let's configure a behavior by going to the Edit Behaviors action. And let's look at the events happening when you run your application. So when the run starts, you want to bring up the Console tab.

When the run pauses, we don't want to bring up any navigators, so let's switch that off here. When the run generates output, that's okay. And when the run completes, we also don't want to bring up any navigator, and we also don't want Xcode to hide the debugger in that case. Okay, so let's see what happens now when we run the application.

As you can see, Xcode automatically brings up the console tab. And it's exactly like we configured it. And when I hit this breakpoint again, It takes us back to this console tab and the debugger is waiting for input. You can do your testing. When you're finished, you can continue and the simulator will come back up.

And now when you stop running your project, the console tab will still be on screen and you can use this to look at the output and use that output for any analysis you want to make. And when you're finished with that, you can just easily close the console tab. Xcode will take you back to the original tab, which will look exactly like you left it.

And that's how you can use behaviors to change the way Xcode reacts to events. There's lots more you can do with behaviors, so try this out yourself and configure Xcode the way you want it to work. So you've tested your app in the simulator. Everything works great, but now you want to put it on your testing device.

Or even better, you want to share it with others on your team so they can test it too. For many developers, this is the first time they learn about things like code signing, certificates and provisioning profiles. The reason is, every app running on an iOS device needs to be code signed. And this means before you can run the app on your device, you need to have two things in place on the test devices. your app, code signed, and a provisioning profile.

A provisioning profile authorizes certain apps to launch on certain devices. So you need to do some administrative work before you can start testing apps on devices. For testing during development, you need a development provisioning profile which authorizes members of your development team to build and code sign apps for devices configured for development. Which means these devices need to be registered as test devices in the provisioning portal and also you need to have app IDs in place and each team member needs a signing identity.

And a signing identity is a combination of a signing certificate and a private key. And if you don't have these yet, you need to request them in the provisioning portal. And for that, you need to generate your own unique private/public key pair. And that's all you need to get your app running on test devices.

Sounds complicated? Don't worry. Xcode makes it very easy for you with automatic device provisioning. You can also create provisioning profiles and renew expired provisioning profiles right from Xcode. So how difficult is it really to set yourself up for some on-device testing? Let's see how automatic device provisioning helps you with that.

Go to the Xcode Organizer, the Devices section, with your device attached to your development Mac. And if you've never used this device for development before, you'll see a button "Use for Development". So step one is: click that button. Step 2 is you will need to sign in with your developer account credentials. And that's it, you're done. Xcode does everything else automatically for you. Which means there is a lot happening behind the scenes.

If your device hasn't yet been registered with the portal, Xcode will do that for you. It also downloads a generic iOS team provisioning profile which enables all members of the team to sign apps for this profile. It uses a wildcard app ID so it authorizes all basic apps from this team to run on any device registered for this team.

And if this iOS team provisioning profile has not yet been created, it will create it and download it to your development machine. If you haven't downloaded your signing certificate from the portal, Xcode does that for you too. And if you haven't even requested it yet, it requests it for you as well.

And if you're an admin on the team, it will immediately create and download your certificate. If you're not an admin, it still works all automatically. You just need to wait for an admin on the team to approve your request. Once it has been approved, go to the Provisioning Profiles section in the organizer and hit refresh and Xcode downloads everything for you.

Now, what about apps where you need a specific provisioning profile? Let's see how Xcode can help you creating other provisioning profiles. There are some iOS technologies that require an explicit app ID and they don't work with the wildcard in the generic profile. These technologies include Game Center, Push Notifications and In-App Purchase.

To create a specific provisioning profile right from Xcode, go to the organizer, to Provisioning Profiles and click New. Again, you might have to sign in with your developer account. Once you've done that, you can configure all the details of the new profile. The profile name, the platform, in this case iOS, the app ID, and this one needs to be set up first in the provisioning portal. And you can select specific devices which will be authorized to run apps for this profile and certificates which will be the signing identities authorized to codesign apps for this profile. And as soon as you click Finish, the profile will be generated and downloaded to your development machine.

Finally, what about expired provisioning profiles? The organizer makes you aware of any profiles that already have expired or shortly will be. To renew them, simply click the Renew Profile button. Again, you might need to log in to your developer account to renew the profile. And that's how easy it is to set up your test devices with Xcode.

And that's it about provisioning profiles. Now let's look at how you can manage your app with Xcode. And this is about archiving. Archiving is how you distribute your apps. You use archives to share your apps with testers, to verify your apps before you submit them to the app store, and then you can submit them directly from Xcode. To create an archive, you go to the product menu in Xcode and choose Archive. This will create an archive for the currently active build configuration. So make sure you have a device configuration selected, as for the simulator, the archive action isn't available.

So what is an archive? An archive is a time stamped XC archive bundle. And this bundle includes an install style build of your application. and it also includes separate debug symbols. And that alone is a very good reason for you to keep archives for every version that you distribute to testers or to the App Store. Because with it, you can look at symbolicated crash logs for every version you have an archive of. The archive also includes verification and submission status for your app, and you can add your own commands too.

Let's look at how archives make it easier for you to share your apps with testers and how you submit apps to the App Store from Xcode. This is how you share apps with your testers. Go to the Archives tab in the Xcode Organizer and select the app and then the archive you want to share. And then click the Distribute button.

Xcode supports several distribution methods. For sharing the app with testers, you pick "Safe for Enterprise" or "Ad-Hoc Distribution", which will create an IPA file. You need to sign the app with an identity that allows ad hoc distribution and supports your testers devices. Then you choose a location where you want to store the IPA file.

And then you can send this file to your testers. Before you ship your app, you should always test your app using such an IPA file, even on your own test devices, because this package is as close as it can be to what users will be able to download from the App Store once your app is ready for sale. The recommended way to share an application with another team is through sharing the whole archive. And the workflow is the same as for sharing the IPA file with your testers. Again, you click Distribute, but this time you choose Export as Xcode Archive.

And you don't have to select an identity because the app in the archive will be codesigned for distribution later on by the other team. You can then just share this archive with your customer and they can sign it with their identity and upload it as their own app under their own account.

Submitting your app to the App Store is also very similar. First of all, make sure you've set up your app's metadata in iTunes Connect. Your app's status in iTunes Connect should be "Waiting for upload". Then select the archive of the app you want to submit and click the Distribute button.

This time choose Submit to the App Store. You need to log into iTunes Connect, choose the appropriate application record from iTunes Connect and the correct signing identity for App Store distribution. Then Xcode will run some checks and if everything is OK, it'll upload your app to iTunes Connect.

And that's how you upload your apps to the store. As simple as that. This was a quick tour of some of the modern techniques available to you through Xcode. You've seen how you set up your projects to use the latest SDK features and optimizations. How Storyboards simplify the way you design your app's user interface. How Xcode adapts to your own personal workflow with behaviors. How automatic device provisioning makes your iOS devices ready for testing. And how you distribute your apps using archives.

And there's even more Xcode can help you with. Have a look at the Xcode 4 User Guide to learn about all the techniques I covered here and lots of other helpful tips and tricks for using Xcode. And next time you download a major new upgrade to Xcode, make sure you read the release notes and take some time learning about the latest features and techniques. Because if you know how to use the tools effectively, this will pay off very quickly and you can focus on building great apps.