Welcome to Introduction to Xcode. My name's Najla and I'm a member of the Xcode team. Along with my colleague Rick Ballard, we'll be taking you through the essential components of Xcode. So Xcode is a development platform for creating apps for iOS, watchOS, tvOS, and OS X, macOS. It gives you the tools to create a complete app, from designing your user interface and implementing code, to testing and debugging your application, to provisioning your app for distribution on the App Store.

So today we're going to take you through the most important components of Xcode by creating an app. You'll learn how to create a new application and run it in the simulator, how to test and debug your application, how to review your changes and commit them to source control, and how to configure your project for distribution.

Now, we want this session to be more about learning how to use Xcode and less about app development, so the app that we're going to be using today is going to be very simple, but don't let the simplicity of the demo app fool you. There's information in this session for everyone, whether you're brand new to Xcode or an experienced developer.

So the best way to learn about Xcode is by using it, so let's get started at our machine. So what you see here is Xcode's welcome window. On the right, you can open existing projects, and on the left, you can create new ones. Let's create a new project.

And when you create a new project in Xcode, you have a number of templates to choose from, and there are basically just starting points for your application. You can have, there are templates available for all four platforms -- iOS, watchOS, tvOS, and macOS. Now, I'm going to choose the simplest template available, which is a single view application for the iOS platform. It's, it provides the code for, to support an iOS app with one view.

So let's name our project Hello, and if you have a developer account, you can add it here and select your team. Now, your organization name is just the company you work for and your bundle identifier is a combination of your organization name and your product name. It's a string that uniquely identifies your application. Now, when you create a new application in Xcode, you can choose between using Swift and Objective-C as your programming language. We're going to be using Swift and our app is going to be universal, meaning that it can run on and support both iPhone and iPad.

So when you create a new template, there are different options to configuring your project. We're going to choose unit and UI pass. Now, let's save our project in our Documents folder, and I'm going to click Create Git Repository so that our project will be under version control from the start.

Awesome, so here's our project. I'm going to resize the window by double-tapping at the top. Now, this is called Xcode's main window. On the left is the navigator area with all of your files and resources. In the middle is the editor area where you can open files that you've, that you click on in the navigator. And on the right is the utility area, which contains useful, contextual information based on what you have selected in the navigator or in the editor.

Now, if you're brand new to Xcode, you're probably wondering, what does this app look like on a device? You can run your application by clicking the Run button at the top of the main window. But before we do that, let's talk a little bit more about what actually happens when you click Run. So when you click Run, you specify what you want to run here and where you want to run it here.

Now, in your project, you can have multiple applications or even multiple configurations of the same application. A scheme is how you specify what you want to run and it also contains information about how you want to run it. For example, I could have a project with an iOS app and a Watch app, and in that case, I would have one scheme to run my iOS app and one scheme to run my Watch app. Currently, we only have one scheme in our project. It's called Hello, and it's already selected.

Now, your run destination is where you specify where you want your application to run, and in Xcode, you have two options. You can run your application in the simulator or you can run it on a device. A simulator simulates what your application will look like on a device, and this is really great for doing quick, iterative development and when you want feedback on how your app is looking and functioning.

Currently we have the iPhone SE simulator selected, so let's click the Run button, and it's going to run our scheme Hello on the iPhone SE simulator. So our application is launching, and here it is. I said that we were going to choose the simplest template available, and there's nothing here, so let's add a feature to make it a little more interesting. I'm going to stop the simulator by clicking the Stop button next to the Run button. So in Xcode, you can lay out the user interface of your application in what's called a storyboard.

Now, since we created our project from a template, we have a couple storyboards available. We have a launch screen storyboard and a main storyboard. Your launch screen storyboard contains the user interface for your launch screen, which is that screen that first appears when you launch an application for the first time. And your main.storyboard contains a user interface for the rest of your application. So let's open main.storyboard.

In the storyboard, you have what's called the canvas, which is this white background, and there's a scene inside of your canvas, which contains your view and it represents one view of your application. Now, for a feature, I want it to be really simple, but I also want to be able to interact with it in code, so I'm going to implement a button that when tapped says Hello in a label.

So at the bottom of the utility area, are Xcode's libraries, such as the file library and the code snippet library. Now, third icon from the left takes you to the object library, which contains all of the UI elements that you can add to your scene. You can view them as a list, which is great when you don't exactly know what you're looking for and you want more information, or you can view them as a grid. Now, I already know that I need a button and a label in my scene, so I can use the filter bar at the bottom of the utility area to search for a button.

Let's drag it into our scene, and guides appear to help us center it. Now, earlier I mentioned the utility panel, so let's take a closer look at the inspectors at the top of it. Now, the first two, the file and quick help inspectors, they're available throughout your project, no matter what you have selected in the navigator or the editor, but since I have the buttons selected in our scene, the rest of the inspectors contain information about the button.

For example, I can click on the attributes inspector here to get information about the text properties of the button, such as the size, the font, the color. I can click on the size inspector next to it to see information about the size of the button and the position in the scene.

I'm going to change this button's title to say Say Hello, and I can do this in the attributes inspector, but an easier way of doing this is by double-clicking on the button and just typing the title that I want. Great, so now we have our button in our scene. Let's go back to the filter bar and search for a label.

I'm going to drag it so that it's above the button but still centered. And once again, I can go back to the attributes inspector or the size inspector to configure its properties, but I like it the way it is, so let's just leave it. One thing to note about our user interface currently is that we haven't specified how the view should scale based on the device that it's on.

Currently, we're viewing our scene with the dimensions of the iPhone 6s simulator or device, but if I click on this, I can change it to other devices, such as the iPhone SE device. And here we can see that our label and our button actually aren't centered the way that we thought. So let's go back to the iPhone 6s, and we need to add some constraints with auto-layout to set some rules for how the user interface should scale.

We can do this using the auto-layout icons at the bottom of the canvas here. So for our button, I want it to be horizontally and vertically centered in the view, so I'm going to click on the Align icon and set it so that it's horizontally and vertically in container.

Now we can see our constraints in the scene. Now for my label, I also want it to be horizontally aligned in the view, so I'm going to go back to the Align icon and check Horizontally in Container. Now, when we did that, the constraints showed up as red, meaning that something went wrong.

And at the top of the documents outline, there's actually an arrow that will take us to a useful error about what went wrong. And here we can see that we never specified a y position for the label. Now, I don't actually care what the specific y position of this label is. I just always want it to be above the button. So what I can do is I can click on the Pin icon.

Oops, we didn't select the label in the scene. So once your label is selected, you can click the Pin icon and pin the bottom of the label to the top of the button. It's at our constraint, and now it's blue. I'm going to rerun it in the simulator to see if we have the behavior that we want.

So here's our user interface. Looks pretty great. What were to happen if I rotated our device? Well, with the simulator, you can simulate rotation by clicking on Hardware and Rotate Left or Rotate Right. Let's rotate left, and it's still centered. Now, the great thing about the simulator is that you can simulate a lot of different kinds of things, such as rotation, shaking, even specific locations. I'd recommend checking out the simulator and playing around with it because it comes in handy when you want to do some quick testing and you don't want to pull out your device.

So now that our user interface is laid out, we need to add some code so that tapping the button actually changes the label to say Hello. Let's stop our simulator and talk a little bit more about scenes and view controllers. So every scene in a storyboard references some view controller class, which contains code to manipulate the view.

I only have one scene in our app and I only have one view controller file in our navigator, so I can infer that this scene is referencing the class in view controller's Swift. But what if I had multiple scenes in our application and multiple view controller files? How would I know which scene is referencing which view controller file? Well, when you select a scene in the storyboard, you can click on the identity inspector, which is next to the attributes inspector. It actually lists which class it's referencing. So now we know for sure where we need to put our code.

So I want to display our storyboard file and our view controller files side by side, and I can do this by clicking on the Assistant Editor button at the top of the main window. It's looking a little cramped, so I'm going to create a little bit of room by hiding the documents outline using this button here and also by hiding the utility area by clicking on this panel.

Now, one thing to note is that this bar at the top of our editor, it's called the jump bar, and it contains a lot of useful information about the functions in your file and even about the files themselves. Now, the great thing about the assistant editor is that it actually knows which file is related, which files are related to the file that I have open in the primary editor and will open it up for me in the assistant editor. For example, if we opened our view controller's Swift file in the primary editor, it would open up the generated interface file for it.

Now, another cool thing about the assistant editor is that it actually, you can actually change the relationship that it's using by selecting the relationship at the top of the jump bar and changing it to whatever you want. For example, you can change it to Siblings, which will open up all of the files that inherit from the same superclass.

So let's go back to our main.storyboard by using the back arrow in the jump bar. So we have our view controller class and we have our storyboard. We need to create references for our button and our label in our class. Now, I can do this by selecting the UI element that I want, so I have it selected. I'm going to Control drag from the scene and into our class.

Now, I want this to be an action, which means that I want it to perform something when I tap the button. And let's name it Say Hello. Let's do the same thing for our label. I actually want this to be an outlet, which means that it's a reference that I can manipulate, and let's name it Hello Label.

So now we have references for our elements. We need to add some code to our action that actually manipulates our label. Now, I think a label has a property that we can use, but I'm not exactly sure, so here's when using Option Click and Command Click in Xcode comes in handy. So we, when we created our reference for our label, it declared it as an instance of the UI label class. I can Option Click on this label on the class name to get a quick help description of what this class does and also its availability.

I can also Command Click on UI label, which will take me to the, to where it's declared. And if I just want to look up documentation for this, I can navigate to Help Documentation and API Reference and search for the class. So I'll search for UI label, and here we have a description, overview, and all of the properties of that class listed. So here it says that a label has a text property, so that's what we can use to actually display Hello.

Let's close documentation and navigate back to our view controller file by clicking on the back arrow in the jump bar and add some code. So I want to manipulate Hello Label, so I'll start typing that, and as I start typing, Xcode will provide suggestions for things to autocomplete. This is Xcode's code completion.

I can autocomplete it by hitting Tab, and I want to access the text property. I can also autocomplete that. And let's set it equal to the string Hello. So now we have some code. We have our references. Let's see if this actually worked by rerunning it in the simulator. So our app is launching. Here's our button, and it changed. Very exciting, right?

Yes [laughter]. So now you know how to create a new project in Xcode, how to add a simple feature, and how to run it in the simulator. But it's very likely that you'll be learning how to use Xcode on an existing project that's way more complicated than our button and label, so let's fast-forward a little bit. Now that Rick and I know the basics, we've been implementing some more features, so I'd like to invite Rick up on stage to take you through the rest of Xcode's development workflow.

Thanks, Najla. So for the past week, we've been building our own little app. We decided to write an earthquake tracker so we could see what earthquakes have happened recently. We're nearly done, and of course, we wrote unit tests so that we could make sure that our code works, and I think we still have a couple problems left to fix. Let's take a look and dive into Xcode's debugger and unit testing.

So to start out with, we need to check our project our of source control. Xcode supports the Git and Subversion source control systems. To check out our project, I can go to Xcode's source control menu and choose the Check Out command. This gives me Xcode's check out UI, and I can enter in the repository path, so mine is at example.com/repos, and our project is called Quakenator.

I'll hit Next. Xcode will give me a chance to put in my authentication credentials for this repository. Whoops. And now Xcode will ask me where I would like to check it out, so our Documents folder is fine. I'll say Download, and Xcode's checked your project out of source control and we're ready to work with it. Now that we have a project checked out, you'll notice that the source control menu gives us a lot more options. We'll come back to one of these later.

So to start out with, let's take a look at our unit tests. We could browse through our project structure on the left and try to manually find our test files, but there are some better ways. At the top of the navigator area, there are a number of different navigators. These each give you different views onto the content in your project.

One of these views is the find navigator, and using this, I can search textually through all the content in my project. So for example, we know that all our test methods begin with the word Test, so I can find text starting with the word Test. Just hit Return. And here Xcode has found every word that begins with Test in my project, including both my test methods and some comments and other hits.

So that's great, but let's do something a little smarter. If I want to find just my test methods, I can find definitions. These are where my symbols, like my test methods, are defined. Again, starting with the word Test, and here it's found just my test methods. So the find navigator is a great way to search through the content in your project, but since we're specifically trying to look for our unit tests here, Xcode gives us an even better way, and that's the test navigator.

In the test navigator, Xcode automatically lists every unit test and UI test and performance test that Xcode has found in your project. Some of these are grayed out like my UI tests, and that's because those tests aren't configured to run in my current scheme. I have a separate scheme for when I want to run my UI tests. The rest of the tests are shown in black, and that means that when I perform the test action, these tests will run, so let's go ahead and try that.

From the product menu, I have the test action as well as the other four scheme actions. Run will run my app in the debugger. Test will run my tests. Profile will run my app in instruments so I can measure its performance. Analyze will run Xcode's static analyzer and help catch problems I might otherwise have missed.

And finally, the Archive action will build my app for release and put it in the archive that I can then use to distribute to my testers or to the App Store or to save for future crash log desymbolication, or symbolication. This command will become enabled in this menu once I select a device as my run destination.

I'm going to go ahead and select a test action, and when I do, I want you to watch the activity area up at the top of the window because it'll tell you what Xcode is doing. So I'll select Test, and you can see Xcode is now building my app and then it's going to build my test code, and it would run it, but it looks like we have a compiler error.

When a compiler error occurred, a badge showed up at the right-hand side of the activity area, showing that there was an issue, and Xcode automatically switched me to the issue navigator on the left. This behavior, like automatically switching to the navigator that shows issues when an issue occurs, is something you can actually configure in Xcode, and as you learn to make it work the way you want, you might want to dive in and configure these sorts of behaviors.

You can do that in Xcode's behaviors preferences. If you choose to edit behaviors, Xcode will give you a preference sheet that lets you configure all these sorts of behaviors. So when a build generates issues, we show the issue navigator. When a test generates issues like a test failure, we show the test navigator, and so forth. As you start to get comfortable in Xcode and want to start to make it work the way you want with your workflow, I recommend checking out behaviors.

So let's take a look at what our actual compiler error is here. I'm going to go ahead and just click on my issue in the issue navigator, and this will jump right to our source code where the compiler error has occurred. Xcode lists the error right on the line of code where it's occurred, and it looks like here my data source object doesn't have a method or a property named Assorted Quakes. You know, I think we had Assorted Quakes property, and just yesterday we renamed it in our code, and I guess we forgot to rename it in our unit tests, so let's figure out how to find what the new name of this method is.

To start tracking that down, I'm going to hold the Command key down and click on Data Source, and that will jump to right where this variable is defined. So I can see that I'm initializing it as a quake data source right here. I'm then going to hold the Command key down again and click on Quake Data Source, and this will jump right to the file where quake data source is defined. I could start scrolling through this file looking for my property, but there's a better way.

The jump bar at the top of the source editor lists every method that Xcode has found in this file in the order in which they appear. There are a couple extra ways to get around this. If I hold the Command key when I pop it down, Xcode will bring it down in alphabetical order instead of in an order of appearance.

Or I can simply type with this up, and Xcode will filter on the list. So it used to be called Sorted Quakes. Probably still has Quakes in the name. I'll type Quakes, and here are just the properties and methods that include the word Quakes. One of these is orderedQuakes. I think that's the new name of our property.

This is actually a nice, fuzzy search, so you can find things even easier than this. If I simply type OQ, Xcode is able to find orderedQuakes because the letters O and Q appear in this property name in that order. One last thing I want to show you here.

You'll notice that I have a couple headers. Here's a to-do item reminding me to add more performance tests, and I have a header dividing my properties from my methods. You can actually configure these yourself with special comments in your source code like to-do: and mark with a header name, and that will let you organize the jump bar pop-up just the way you want to make it easy to navigate your source code.

All right, so let's find our property. I'll type OQ again and select orderedQuakes. It's found it for me right here, so let's go ahead and copy this method name. I'm going to use the back arrow in order to jump back to my test file, and I'm going to go ahead and paste the new method name in here.

When I do that, I want you to notice the error badge on the left-hand side of the source editor and the error in my issue navigator pasted in the right name, and both of those badges disappeared. And that's because the issue navigator is tracking what you're doing in real time, so we can show the state of your code as you edit it without having to wait until you hit Build to see whether things are right.

Okay, so we fixed our compiler error. Let's go ahead and run our tests again. When I do this, Xcode's going to compile my changes to my code, and it's now preparing to run my tests in the simulator, as you can see from the activity area at the top.

Looks like our tests are running, so let's switch to the test navigator to see what's going on, and I can see from the spinner here that this test is running. It looks like one of my performance tests, and this might take a while, so let's actually hit the Stop button and take a step back.

Performance tests are great to have, but what I'm trying to iterate on fixing my unit tests I might not want to have to wait for my performance tests every time. So we can do that by configuring a different scheme that doesn't run my performance tests. To configure my scheme, I'm going to go to the Scheme pop-up and choose Edit Scheme.

Here Xcode will bring down the scheme editing sheet. You can see that there's a tab on the left corresponding to each of the five scheme actions as well as a Build tab at the top that lets me configure which targets this scheme will build in order to perform the actions on the products of those targets.

For an action like Run, I have options like what executable I want to run. In this case, it's my app. What command line arguments and environment variables I might want to pass. Even special diagnostics like Xcode's powerful address sanitizer that will help you track down problems. Since these diagnostics are options just on the Run action, they won't have any effect on the actual app later archived for distribution, so you don't have to worry about these diagnostics interfering with what you submit to the App Store.

I'm going to go to the Test action, and here you can see where I've configured what tests this scheme will run. Before I start changing that, I'm going to do something that I often do when editing schemes, and that's to make a copy of my scheme and make the edits in the copy. That's because I still want to keep a scheme around that knows how to run my performance tests because I do want to run my performance tests. I just want a different scheme that lets me run only the unit tests.

So to do that, I'm going to select the Duplicate Scheme button. Xcode will give me a chance to give this new scheme a name, so we'll call it QuakenatorNoPerf. And now I can go to the Test action, find my performance tests, and uncheck the checkbox to disable them. From here, you can actually disable tests on a per-test basis if, for example, you have a test that's failing that you're not going to any time soon.

All right, I think we're done with configuring our new scheme, but before I go back to running our tests, I want to show you one more useful thing here, and that's how to manage your schemes. The Manage Schemes button at the bottom of this sheet will bring you to Xcode's scheme management sheet, and here we show you every scheme that Xcode has found in your project.

I'd like to especially call your attention to the shared checkbox column on the right. If a scheme is shared, assuming that you also checked that scheme into source control, all your coworkers will also get that same scheme when they work with this project, and any edits they or you make, assuming that you check those edits into source control, will be shared with your coworkers, so this makes it really easy to configure a particular scheme that you want everyone to use and share it with your coworkers. Since my coworkers might want to be able to run the unit tests without the performance tests too, I'm going to go ahead and share my new scheme. Okay, I think we're done here, so let's go back and run our tests one more time.

It's preparing to run my tests in the simulator, attaching to my tests, and now it's running the tests. And you can see from the test navigator on the left that most of my tests have passed, but I have one test failure. If I want a closer look at what just happened, I can find that in Xcode's reports navigator.

The reports navigator shows the log for every action that I performed grouped by the scheme which was used to perform that action. So here I just perform a Build automatically when I went to test and then the tests that I requested. If I select the Build log and adjust the filters to show me everything, I can see every command that Xcode ran to build both my application and my unit tests. If I select the Test log, Xcode shows me every test that it ran, its status, and I can even turn this down to find the test failure message. In this case, one of my test assertions failed because an earthquake magnitude was out of bounds.

I'm going to hover over one of my tests, and I'll get a little jump arrow here. So if I select that, Xcode will jump me right to the failing test. Here you can see where I declare my test, and there's a badge to the left of the test method indicating that that test is currently failing.

If I scroll down, I can find the actual test failure. Here I have a test assertion that's checking the range of my test data or earthquake data magnitude, and it looks like this range check is failing. Actually, this looks pretty simple. I think I just have a less than when I should have a greater than because I'm trying to check the interior of this range, so I think that should fix my test.

Let's go ahead and run this test again and see if that fixes, but since I'm trying to iterate on just this one failing test, there's a faster way than running all my tests every time. I can run just this test. To do that, I can go to the test navigator and mouse over my test.

You'll see that the badge turns into a little Play button when I do that that would let me run just this test or I can run just an entire suite of tests, or if I don't want to switch back to the test navigator, I can even run my test right from the source editor simply by mousing over the failure badge to the left of the test method and clicking the Play button that appears. So let's click that now. It's building my change to my tests, and it's going to run my tests again.

So it's ran my tests again, and it looks like my test is still failing, so I must have another problem. I'm going to scroll down, and here I see each of my earthquakes has a visual badge that graphically indicates its magnitude, and for my test earthquake data, I'm just making sure that every earthquake has a graphical badge, but one of them has a nil badge, so it's missing its badge.

This doesn't look like a problem with my test code. It's probably a problem with a code that sets up these earthquakes, so I'm going to jump to that code and take a closer look at what's going on. We're showing you a number of ways to navigate around your code in Xcode today, but I'm about to show you the single most useful navigational gesture that we have.

In Xcode's file menu, we have a command -- whoop -- called Open Quickly. This is one keyboard shortcut you will definitely want to memorize, Command Shift O, as you'll want to use this all the time. If I select Open Quickly, I get a textbox in the middle of my window, and I can type in this to search all the symbols, like my method names, in my own project as well as all the symbols in Apple's API, so it makes it really easy to find whatever I'm looking for, whether it's in my own code or in the system frameworks.

This also is a nice, fuzzy search, so I don't have to know exactly the name of what I'm looking for. In this case, I think my earthquakes are set up in some method that fetches quakes, so let's try typing Fetch Quakes, and you can see it's found my Fetch Latest Quakes method, even though I didn't have the name exactly right because it's a fuzzy match, and there are three instances where this method shows up in my project, but the first one that's selected is where I set up my test data, so that's the right one. So I'm just going to hit Return to jump right to that code.

Okay, so here I'm setting up my test earthquakes. I don't see anything obviously wrong with this, so it's time to take a closer look at what's going on. And to do that, I'm going to use Xcode's debugger. Xcode's debugger is available whenever you perform the Run or Test action in Xcode. And you can get it to stop on a line of code or break by setting a break point on that line.

I can set a break point by clicking on the left-hand side of the editor, and you'll see that a break point badge appears. I can click on that again to gray it out and temporarily disable it if I want to skip past it or I could just drag it out when I'm done with it and let go to delete my break point.

In this case, I do want my break point, so I'm going to click again to create it, and let's go ahead and run our test again. I'm going to show you one last quick way to run the same tests. There's a command in Xcode called Test Again, and Test Again will run whatever test or tests I ran last, so it makes it really easy to repeatedly run the same tests as you work on them.

I can get at Test Again from Xcode's product menu under the Perform Action submenu. There's actually a number of useful commands in here, but here's Test Again, so I'll go ahead and select it. Xcode's going to run just this one test. It's attaching to my test in the simulator, starting to run my test, and you can see that Xcode has now stopped in the debugger on this line of code.

When the debugger stopped, a few things happened. First, at the bottom, the Debug bar appeared, giving me a number of different controls to allow me to control the debugger, such as Continue, Step Over, and Step Into. Below that is a variable area showing me each of the variables that are visible in my current scope.

Here I declare three different earthquake objects, but I haven't assigned their values yet, so it shows no value. On the right-hand side is a console area that shows all the output my program has printed to standard out or standard error, and we'll come back to that in a minute.

Finally, you'll notice because Xcode is stopped in the debugger, one of those behaviors kicked in, and Xcode automatically switched me to the debug navigator. Here Xcode shows where I'm stopped in my code in every thread. This code is actually running on a background thread right now, Thread 6, and all of my stack frames that I have source code for are shown in black, whereas all of the stack frames that contain system code that I don't have source code for and can't look at are shown in gray.

You'll notice that there's actually a dashed line here aligning some of these frames. It's because I don't really need to see 10 frames of system code that I don't have source code for, but of course, if I do want to see exactly what's happening, I can adjust the filter controls at the bottom of the debug navigator.

All right, let's try stepping over this line of code where we initialized this first earthquake and see what happens. I'm going to use the Step Over button to do that. When I do that, Xcode continues to the next line of code, and you'll see that my first earthquake object has been initialized in the variables view. I can actually twist this open to inspect all the properties of this new earthquake, and here's my visual badge.

Since this is an image and I might want to take a close look at what this is, Xcode gives me the ability to quick look objects like this, and when I quick look it, Xcode will read the image right out of my program's memory and display it graphically here so you can inspect exactly what the value of that image is.

Well, this badge obviously isn't the program since this one isn't nil, so let's check out the next earthquake. And to do that, I'm actually going to step into the creation of this next earthquake and see what happens. I use the Step Into button here to step right into this initializer, and here's where we initialize our earthquake. So I can just start stepping through each line of code.

Here's the switch statement where we choose which magnitude badge to use. And here's the badge we're initializing. I don't think this is quite right. I don't think IIII is a valid Roman numeral. So that's probably the problem, and I could try fixing my code, stopping it, running my test again, but Xcode makes it possible to try things out without having to stop and start over every time. And to do that, I'm going to use a debugger expression.

In the console area, I'm going to use the PO command, which stands for Print Object, and this command will take any valid Swift or Objective-C expression and execute it for me. So I can simply copy this image initializer and paste it right into my console area. So let's make this console area a little bigger and let's also clear out the existing text with the Clear button so I can see what I'm doing.

And now I'm going to hit Return to execute this expression in my application, and you can see that it's returned nil, so there is no image of that name. I'm going to press the up arrow to recall this expression, and let's try IV, which I think is the right Roman numeral for 4.

So I'll hit Return to execute that, and you can see the Xcode has returned in actual image instance, so it looks like that's the right name for this image. So at this point, I'm going to go ahead and stop the debugger and I'll change my image to IV, and let's run our test one more time with the Test Again action.

So Xcode is building the changes that I made to my code. It's preparing to run my tests. Let's switch to the test navigator so I can see how it goes. And, oh, it looks like I still have a break point set. So I want it to run my tests and not stop in the debugger, so let's take a look at how to manage our break points.

Xcode's break points navigator shows me all the break points that I have set in my project, which I can disclose here, and I can disable them individually here as well or select them and delete them if I'm done with them. I can add special kinds of break points in the break point navigator like breaking on any Swift error that's thrown, any unit test that fails, or on any symbolic method name that I want.

If I find that there's a certain break point that I always want to have, like, say, a test failure break point, I can make it available in every project that I work with simply by selecting the break point after I add it, bringing up the contextual menu, and choosing Move Break Point to User. This moves that break point to my user break points and makes it available for me no matter what project I'm working with.

All right. In this case, I'm not quite ready to delete all my break points yet in case this doesn't work, so let's temporarily disable break points so that we don't stop at them. I can temporarily disable my break points with the Break Points button in the debug bar.

I'll now press the Continue button to finish running my test. Let's go back to the test navigator, and you can see that all my tests are passing, so it looks like we're done. Let's review what we've done here. To review my changes, I'm going to go back to Xcode's project navigator and I'm going to use a filter at the bottom called the source control status filter.

This will make the project navigator show me only those files that have a special source control status, such as Modified. This both lets me see what changes I've made and is really useful if I want a sort of working set, a set of files I'm all working on that I want to jump between quickly. If I modified those files, I can use this filter to narrow it down to just those files I'm working on.

If I want to see the actual changes I've made to one of these files, I can select it and use Xcode's third editor mode. So we've already shown you the basic editor and the assistant editor. Xcode's third editor mode is the version editor, and it has three variants.

The comparison editor lets you compare changes between two revisions or your uncommitted changes against the last committed changes. The blame mode lets you see who has changed each line of code in your file and at what revision, and the log mode will show you the source control log for your file. In this case, I want the comparison mode.

When I select this, Xcode shows me two versions of my file. On the left is my local revision, so these are the changes that I've made, and on the right is the last revision I've committed to source control, so this is showing me the differences between what I've done and what I've last committed.

In the bottom middle are some arrows that let me jump between my changes, and when I'm looking at a change, Xcode will visually show me what line the change happened on and even highlight exactly where the change happened in that line. If I want to compare against an older revision, I can actually pop this up and choose whatever revision to the file I want to compare against or I can even compare two revision, older revisions against each other by selecting a different revision on the left.

I think these changes are great, so it looks like it's time to go ahead and commit our changes. To commit, I'm going to go to Xcode's source control menu and choose the Commit item, and this will bring down Xcode's commit sheet. On the left, I can see all the files I've changed, including some settings files, and if I select one, I'll get the comparison editor right here in the commit sheet to give me one last chance to review all my changes.

From here, I can even discard specific changes by clicking on the change marker and choosing Don't Commit if I only want to commit some of the changes that I've made. In this case, I want to commit everything, so let's give it a Commit message. I'll say Fixed Tests, and I want to push my changes right to my coworkers when I commit, so I'll click the Push checkbox.

And let's go ahead and commit our changes. So Xcode's committing. It's pushed our changes off to my coworkers, and we're done. When you're ready to go ahead and distribute your app to your testers or to the App Store and want to learn how to do that or if there's anything else we didn't cover today that you want to learn more about, I recommend checking out Xcode's Help Book.

You can get at the Help Book from the Help menu by choosing Xcode Help, and from here, you can either search for whatever you want more information about or browse through a list of topics. For example, Archive and Output Products, Create an Archive. Here Xcode tells me how to create an archive for distributing my app.

All right, well, we've taken you through a pretty complete workflow here today, but there's one more key piece of knowledge we'd like to leave you with before we finish, and that's how to customize your source code and your projects -- sorry, how to customize your projects -- and configure them for your own needs. To take you through Xcode's core configuration concepts, I'd like to invite Najla back up on stage to take you through it.

Thanks, Rick. So now you know the basic development workflow in Xcode, and when you're just getting started, that's probably all you'll need, but as you start working on more complex projects, you'll need to know how to configure your projects and settings. So let's take a quick tour of Xcode's core configuration concepts so that you'll understand what you're working with. So there are five concepts that we want to talk about today -- Xcode projects and the targets that they contain, the Build settings and capabilities that configure how Xcode behaves, and workspaces for organizing your project.

So let's begin by talking about projects. A project is a document that you use to organize your code an resources in Xcode. You have references to source code files and resource files on disc, targets which actually build those files into products like your app, Build settings which configure how your targets build their products, and schemes which configure how you perform actions, such as Run, with your targets.

Now, to access your project settings, you select your project in the navigator, you select the popover at the top of the editor, and select your project there. Now, your project settings are distributed between two tabs, your Info and Build settings tab. And most common settings are available in Info.

There's one that I want to point out, which is the deployment target of your application. Your deployment target is the minimum OS version that your app can run on and support. Currently, our app only supports iOS 10, but if I wanted our app to support iOS 9, I could change it here in the project settings.

Let's move on to talking about targets. A target contains the instructions to build one thing like an app or a framework. The thing that your target produces is called its product. The set of steps that your target takes to build its product are called build phases. And lastly, a target has Build settings to configure how it builds its product.

Now, one thing to note is that both projects and targets have Build settings, and targets inherit the value set at the project level but can override them with a target-specific value. A target's build phases do things like cause dependencies to build first, compile the source files in that target, and link the target against libraries and frameworks. You can also add what's called a run script build phase to configure other aspects of the build that you'd like.

You can access your target settings by selecting your project in the navigator, selecting the popover at the top of the editor, and picking the target of your choice. Now, your target settings are distributed between a few tabs, such as the Build Settings tab, the Capabilities tab, and the Build Phases tab. So let's talk a little bit more about those Build settings and capabilities.

A Build setting contains a name and a value of some aspect that controls some aspect of the build process. For example, there are Build settings for specifying which architectures you want to build, whether your code is optimized, what your product is named, and even how you deal with warnings. The Build settings are available at both the project and the target level in the Build Settings tab in a big table that contains all of the names and values.

Now, Build settings can also vary by what's called a build configuration, and by default, a project has a debug and a release configuration. For example, when you're building for debug, you probably don't want your code to be optimized, but when you're building for release, you do want your code to be optimized.

In addition to fine-grain Build settings, Xcode also offers capabilities, which allows you to easily turn on specific features. For example, for iOS, there are capabilities for enabling in-app purchases and Apple Maps integration, and if you want more information about what a capability does, you can twist it open in the Capabilities panel. You can also enable or disable a capability by using the On/Off switch on the right of the editor. Lastly, let's talk about workspaces.

So you may find over time that you like to work on a group of projects as a set. For example, you might have two projects that share the same framework and you like to work on them together. In this situation, you can create an Xcode workspace that references your projects. So when you open your workspace in Xcode, it'll contain all of the contents of the projects that you've referenced, which makes it easy to edit and navigate across them as related code.

So now you know more about Xcode's core configuration concepts. Armed with this knowledge in addition to Xcode's basic development workflow, and you have the tools to make some really awesome apps. So today we showed you the most important components of Xcode by building an application. You learned how to create a new application and run it in the simulator and how to test and debug it. We also talked about some of Xcode's invaluable tools, such as Command and Option Clicking and Open Quickly. We also showed you how to navigate in your project using the filter bar and the jump bar.

You learned how to review and commit your changes and also how to configure your project and settings once you're ready to submit it to the store. We hope that after this session you have a better understanding of all of the different kinds of things that you can do in Xcode, and we're really excited to see all of the apps that you create. If--

Yeah. So if you want more information about our session, you can navigate to developer.apple.com/wwdc16/413. And if you're interested in a specific component of Xcode, there are a few sessions that you can attend or watch online. For example, there was a session on Tuesday on Xcode app signing, which is really important when you're about to submit your app to the store. There was a session on testing and continuous integration and on debugging tips and tricks. Thanks for watching our session, and we hope that you have a great time at the conference.