WWDC2016 Session 413

Transcript

[ Music ]
[ Applause ]
>> 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,
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.
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.
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.
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,
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.
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
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
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
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
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
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.
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?
[ Applause ]
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.
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.
[ Applause ]
>> 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.
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
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,
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
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
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
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.
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
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
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
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
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,
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,
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
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
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,
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
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
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
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
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.
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.
[ Applause ]
>> 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.
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
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
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,
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 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--
[ Applause ]
Yeah. So if you want more
information about our session,
you can navigate to
developer.apple.com/wwdc16/413.
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.
[ Applause ]