Xcode enables you to create great apps for Apple platforms. This session will introduce you to the basics of creating a project with Xcode, and more. You'll learn how to comfortably navigate your project and gain insights into working with workspaces, targets, and schemes. We'll introduce you to version control workflows, and walk through using Xcode's source editors and design tools. Join us if you're new to Apple platforms or want to learn more about using 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?
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.
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,
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
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
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.
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.
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.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.