Transcript
>> Good morning, and welcome to
Debugging with Xcode 9.
I'm Chris Miles and I work on
Xcode.
We've got a lot of great new
debugging features to talk about
today, so let's dive straight
into it.
I'd like to start by talking
about developing and debugging
with devices.
Let's take a look at our typical
development configuration.
We've got our Mac running Xcode
and nearby we have the device
that we're developing with.
Connecting the two we have the
familiar white cable.
Now, this configuration has
suited us very well for almost
ten years now, but more and more
developers are finding needs to
be more mobile while debugging
with their devices, and to make
this easier, I'm proud to
announce that with Xcode 9 that
white cable is no longer needed.
[ Applause ]
It is now possible to develop
and debug on your device over
Wi-Fi, and we call this wireless
development.
So who can take advantage of
wireless development?
Well, we think many developers
are going to love it, but here
are some obvious examples.
With the introduction of ARKit
this week, I'm sure many of you
are eager to sit down and build
an augmented reality app.
While debugging your app you're
going to need to be moving
around more than you might be
used to, holding your phone,
doing this kind of thing, and
being able to get away from the
computer to do this will make
that much easier than it
otherwise would have been.
For those of you building
fitness apps, you probably know
that the best way to test and
debug your fitness app is for
the athlete to wear the device
on them while they work out.
Being untethered from the Mac
will make this much easier as
well.
For those of you building apps
for accessories, I'm happy to
tell you that you are finally
able to debug your app on the
device
while the accessory's plugged in
to the Lightning port.
[ Applause ]
We think accessory makers are
going to love wireless
development.
And for the rest of us
convenience will be a big factor
in choosing when to go wireless.
We don't always remember to
bring our cables with us or
sometimes the Lightning port is
in use for some other purpose.
But now, just having the option
to jump on a Wi-Fi network to
continue developing and
debugging on our device, will be
a huge convenience.
Now, it's not only iOS
developers who can enjoy this
convenience.
Wirelessly connected Apple TVs
are also supported.
[ Applause ]
So now Apple TV developers can
develop and debug on their Apple
TVs over Wi-Fi.
Apple TV developers, your living
room is now your development
studio.
Sit back and relax on your couch
while you build the next great
Apple TV game
[ Applause ]
.
There's no need to stretch
cables across the room, to trip
over your kids or roommates or
dogs or cats.
We think Apple TV developers are
going to love wireless
development, and we can't wait
to see the next great Apple TV
game that you build while
relaxing in your living room.
So what do you need to be able
to take advantage of wireless
development?
Well, you just need an iPhone,
iPad or iPod touch, running iOS
11 or an Apple TV running tvOS
11.
And on the Mac you just need to
be running macOS 10.12.4 or
later.
What about tools support?
Well, Xcode has extensive
support for wirelessly connected
devices.
In fact, Xcode treats a
wirelessly connected device in
exactly the same way as a USB
connected device, so all of the
device actions will just work,
installing and running your app
on the device, of course, as
well as debugging your app, and
this includes all of the
advanced debugging features,
such as V debugging, Memory
Graph debugging and GP Frame
debugging.
Profiling in instruments works
great as well, and other tools
that also support wirelessly
connected devices, include
Accessibility Inspector, Console
and Configurator.
For tvOS developers, Safari Web
Inspector supports wirelessly
connected Apple TVs.
So this is great news for
TVMLKit developers.
And QuickTime screen recording
also supports wirelessly
connected Apple TVs.
Now, while we're calling this
wireless development, strictly
speaking, you're not limited to
only connecting your devices
over Wi-Fi.
While Wi-Fi will be a popular
choice, for those of us that
support it, Ethernet will work
great as well.
Really, any combination of Wi-Fi
and Ethernet to connect your
device and your Mac over the
network works great, provided
that your Mac and your device
can connect to each other over
that network.
And just to be clear, the option
to connect your devices over USB
remains as it always has been.
So these are now all your
options for connecting your
devices with your development
tools.
So that's just been a brief
introduction to wireless
development.
And now, to give you details on
how to pair your devices and to
talk about the workflow, I'd
like to invite up Breckin.
[ Applause ]
>> Thanks, Chris.
All right.
Well, we've been working really
hard on wireless development for
Xcode 9, and I can't wait to
talk about it with you, so let's
get started.
How do you set up your device
for wireless development?
Well, it's really easy.
Just go to the Devices and
Simulators window and connect
your device to your Mac with
your Lightning or USB cable.
The device will show up, as it
always has, but you'll notice
there's a new option.
Connect via network.
Just enable this option and if
the device and the Mac are on
the same network, after a few
moments you'll see a globe icon
appear to the right of the
device.
Once this globe icon appears,
you know you can unplug your
cable and continue developing
your app completely wirelessly.
Now, this works identically for
iPhone, iPad, iPod touch and
Apple TV, but for Apple TV
there's something else.
So as Chris mentioned, a lot of
our Apple TVs, they're not
sitting on our desks, they're in
our entertainment center and,
you know, you've got your cables
set up just the way you want
them, all of that.
The last thing you want to do is
reach back there and unplug
everything and connect a USB-C
cable, so luckily for Apple TV,
you don't have to do that.
We support wireless pairing in
Discovery, so to do that all you
have to do is go to the Remote
App and Devices screen on your
Apple TV.
Once you go there, go back to
the Devices and Simulators
window in Xcode.
That Apple TV will appear as a
discovered device automatically.
Once you select that device, a
pin code will appear on your
Apple TV.
Just put that pin code in and
click Connect.
After you connect it will be the
same as if you had paired with
it via USB-C cable.
We think this is great for Apple
TV development.
All right.
So that's getting paired, but I
know some of you are wondering,
you know, is it really that easy
to connect, and the answer for
almost everyone is absolutely.
So for most home and small
business networks no
configuration is necessary.
Just make sure that your Mac and
your devices are on the same
network and everything just
works.
Now, we know some of you work on
more complex networks, say
corporate, large institutional
networks, and if your system
administrator has set up certain
restrictions, it may be a little
more difficult, but not by much
because we now support
connecting directly by IP
address to your device.
This is really easy.
Not quite as easy as doing
nothing, but all you have to do
is Control click on the device
in the Devices and Simulators
window and you'll see a Connect
via IP address option.
Just click that and then go to
your settings on your device,
get your IP address, enter it in
and you can connect.
So adds a little bit of a
technical aside.
If you can ping the device from
the Mac, you're probably good to
go.
Now, if you want any of the
deeper details as far as ports,
maybe to pass to your system
administrator, please check out
the wireless development
documentation.
It's got all of that detail.
But, you know, to reiterate, for
almost everyone almost all of
the time you won't need to do
any of this.
Okay. So now that we have
connectivity and pairing out of
the way, it's time to actually
work on your app.
So to do that, well, nothing's
really changed.
Just select your device in the
Devices list, only now, when
it's connected, you'll see a
globe to the right of the device
just like you see in the Devices
window.
Now, if you don't see a globe,
that means that it's not
connected right now.
Maybe it's asleep in your
pocket.
Don't worry.
Build and run to it anyway.
We'll connect to it
automatically.
All right.
So that's a little bit about how
to get started with wireless
development.
But enough talking about it.
I'd love to show it to you.
Okay. Here I am with my Mac.
I've got a phone.
We've put it on a camera here to
show you the cable.
And I would like to make this
iPhone enabled for wireless
development.
I'm going to select Xcode, go to
the Devices and Simulators
window.
And you'll see here's our new
option.
Once I check that the device and
Xcode will communicate,
establish a connection.
As long as you're on the same
network, you'll see the globe
icon appear.
So what's next after this?
It's time to pull the plug.
Okay. So we see the phone is
still connected, it's still got
the globe icon, and that lets
you know that you're ready to do
development.
So I'm going to open an app that
my colleagues and I have been
working on.
It's called SolarSystem, and you
can read about it a little bit
in the README.
For now I'm going to click the
Play button.
This will build the app.
It will run, it will install and
will launch the app and attach
the debugger, and it will do all
of that completely wirelessly.
So the SolarSystem app provides
a way for users to explore the
solar system in a fun and
interactive way.
So as soon as it comes up, we'll
take a quick look at it.
All right.
So here are our planets orbiting
around.
And I've been working on a fun
feature called Moon Jumper.
I'm going to tap this little
weight icon on the bottom.
So this is really fun.
It lets kids take their iPhone,
jump up and down and see how
high they would jump if they
were on the moon.
So really fun to watch people
play around with it.
So we've got our little
astronaut and our astronaut's on
the moon, and now, we've gotten
some reports that it's a little
too easy to jump.
So we've set this bar to 180
feet.
That should take a little bit of
effort, but people are finding
that they can get there pretty
easily.
I'd like to test this out.
So let's think about how would
you test this out before
wireless development.
Right. Well, you got it plugged
in, right, so you're going to
pick it up and you're going to
try and get the accelerometer to
do what you want to do, and all
of that kind of stuff.
Well, you know, this is a
jumping app and if I need to put
a breakpoint right here, which I
happen to know is the place that
should stop when I've jumped
high enough, if I want to see
what that feels like, because
I've had people tell me it
doesn't feel right, I need to
actually jump, so that's pretty
much what I'm going to do.
Okay. Someone put me up to this
[laughter].
All right.
So you can't see the screen, so
I'm going to describe what's
going on.
I'm going to jump a little bit.
Okay. Now, the astronaut jumped
quite a bit, but not high enough
to reach.
Let's see if I can actually jump
to 180 feet.
Let's see.
Did I get it?
[ Laughter ]
Come on. Oh, there we go.
All right.
[ Applause ]
All right.
So we're paused in the app.
Gravity is the value that you
got to, required acceleration is
the amount that is required, and
it looks like what's probably
happening is that this value
here needs to be a little lower
so that it takes longer to jump.
So I don't have time at the
moment to demonstrate that or to
fix it, so I'm going to go ahead
and clear this breakpoint, click
Continue.
All right.
Looks like we lost the
connection.
That's no problem.
Let's see, actually, if we can
attach back to it.
So you'll notice in Xcode 9 we
now auto complete the process
name, we tokenize it, and you
get completion in this entry,
which is really nice.
All right.
We're back.
[ Applause ]
All right.
So there's one more thing that
I'd like to take a look at, and
that's a performance problem
that my colleague was pointing
out.
We were tapping around with the
SolarSystem and they noticed
when they tapped on Jupiter,
there's a bit of a lag.
The camera doesn't show it
really well, but you can kind of
see a pause and, you know,
that's impacting battery life
and we just kind of want to take
a look and see if we can figure
out what's going on.
So I'm going to go to the Energy
Impact Gauge.
Sure enough it's high.
You'll notice that this has been
redesigned in Xcode 9 to give
you a much better look at
exactly where your energy is
being consumed by your app.
So in this case we've got the
CPU, which I think is probably
taking a little bit more than it
should for a GPU-oriented app,
and it goes up every time I
touch that.
So what do we do when we need to
dig deeper into performance
problems?
Well, we go into Instruments.
Now, some of you may not know
this, but there's a really cool
feature in Xcode.
If you've ever had to like --
you know, you're debugging a bug
and you're like, oh, man,
there's a performance problem,
all right, let me, you know, go
to Instruments and start it
again, you don't have to do
that.
I'm going to click the Time
Profile button and this is going
to transfer the debug session to
Instruments and keep the app
going.
This is great if you've got an
app in state and you need to
jump over to Instruments and see
what's going on.
So we've started Instruments.
I'm going to move the window
over, give us a little bit of a
better view.
And we see that we are in the
Instruments default strategy,
which just says the CPU Usage
and the Life Cycle, but new in
Instruments for Xcode 9 is this
All strategy.
So this is the time profile
instrument, but if I click All,
I see all of the threads and the
cores and I get the big picture
of the app.
Really, really useful.
So let's see if we can reproduce
the problem.
[ Applause ]
Here we go.
All right.
So we've clearly seen that
there's an issue.
We've got this spike here.
Now, sometimes you want to just
dig directly into that and look
at the call stacks, but
sometimes what you want to do is
correlate that spike to what CPU
it's on, other threads, and you
know how to do that, right, you
just scroll, back it up, and you
look and you see, oh, is there
another one, well, I'm not sure.
Well, for Instruments in Xcode 9
there is a much better way.
I'm going to pin this track,
right, and pinning the track
actually puts a copy of that
track at the bottom and it's
fixed.
So now I can scroll up and down
and I can correlate what other
tracks are sharing that
performance characteristic
[ Applause ]
.
Yeah, it's really, really cool.
And not only can you just see
the spikes, but I think it's
also important to know what's
not happening.
So being able to see that all of
these are not correlated
obviously gives you information
as well.
Okay. So what we've just seen
are a few things that you can do
with wireless development in
Xcode 9.
Don't need that.
So this just scratches the
surface because, as Chris said,
there's lots of times,
especially today, when the apps
we're developing, they are not
you sitting down and consuming
content while you're on the bus.
Those apps still exist, of
course, but more and more of our
apps are physical, they're
interacting in the real world,
and sometimes you get reports
and you want to reproduce
problems that you can only
reproduce in the real world.
Sometimes you have performance
problems where you need a tool
like Instruments to really dig
deep into your performance and
you want to do that in the real
world.
And with wireless development
you can.
And with that, I'd like to hand
it back to Chris.
[ Applause ]
>> Thanks, Breckin.
What a fun demo.
All right.
I'd like to move on to talking
about enhancements we've made in
Xcode for working with
breakpoints.
Some of you may not know, but in
Xcode breakpoints have a lot of
flexibility.
There are options that you can
set to customize the way that
they behave.
To do this just double click on
a breakpoint and you'll see the
Breakpoint Editor popover.
From here you can set options
such as defining a condition so
the breakpoint will only trigger
if that condition evaluates
true; and you can define
breakpoint actions, such as
logging variables, executing
debugger commands for you and
playing sounds.
Now, these options have been in
Xcode for some time, but over
the past year the team have been
making some enhancements to the
UI to make them easier to work
with.
The first of these, we've added
code completion to all the
Breakpoint Editor text fields.
[ Applause ]
So now in the Breakpoint Editor,
when editing expressions in the
condition field and the
breakpoint action fields, you
get full code completion, the
same as you'd expect from the
Source Editor and the Debugger
Console.
The next thing we wanted to do
was make finding breakpoints
with options set on them much
easier, so in Xcode 9, for any
breakpoints that have options
set on them, you'll see this
alternate indicator with a
triangle at the end.
[ Applause ]
So this indicates that that
breakpoint has one or more
options set on it.
This makes it really easy to see
at a glance, when looking at
either the Breakpoint Navigator
or the Source Editor, which of
those breakpoints have options
set on them.
Furthermore, just mouse over the
breakpoint and a tooltip will
show you a summary of the
options that have been set on
the breakpoint.
This should make finding the
breakpoint you're looking for
much easier.
And speaking of finding
breakpoints, we've also enhanced
the Breakpoint Navigator filter
field by adding deep filtering.
This means that it now searches
your query across all of the
text fields in the Breakpoint
Editor.
So you can match on condition
fields and any of the action
fields and expressions that
you've set in those.
This makes finding breakpoints
much more powerful and much
easier in the Breakpoint
Navigator.
So if you haven't been using
breakpoint options, give them a
try.
They can add a lot of
flexibility and customization to
your debugging workflow, and now
they're easier to use.
I'd like to move on to talking
about user interface debugging.
Now, when building UI, View
Controller is playing an
important role in how you
structure your code and your
storyboards.
View controllers manage and lay
out portions of the view tree
and are responsible for handling
transitions between screens.
So when debugging your UI,
wouldn't it be great to be able
to navigate that view hierarchy
by focusing on the View
Controller structure and to also
be able to find view controllers
that are responsible for parts
of the view tree.
We thought so, too, so in Xcode
9 view controllers are now
included as part of the view
hierarchy when debugging.
[ Applause ]
Inspect your view hierarchy like
you always have been, but now
you can expect to find View
controllers in the Debug
Navigator inserted as parents of
the views that they manage.
This makes it really easy to
navigate the view hierarchy by
first focusing on the high-level
View Controller structure to
find the area of the view tree
that you're looking to debug and
then focusing in on individual
views.
View controllers are represented
visually in the Canvas as well.
Xcode renders banners for View
controllers above the views that
they manage.
This is great for visualizing
the View Controller boundaries
in that view tree and makes it
much easier to find the view
controllers responsible for a
particular view.
Select a View Controller and
you'll see its properties in the
Inspectors, and this helps you
when you're debugging View
Controller specific issues.
It includes the View Controller
parent and child relationships,
which is great for debugging
View Controller containment
issues.
So now that view controllers are
included as part of the view
hierarchy when debugging, it
makes it much easier to navigate
that hierarchy and to help you
to solve View Controller-related
issues.
Now, not all user interfaces are
built using UIKit and AppKit.
Some designs may require custom
UI with rich interactions and
custom layouts.
One option to do this is using
SpriteKit.
SpriteKit is a 2D graphics
framework and it's available
across all of Apple's platforms.
It's great for building games,
of course.
It's also great for building
this kind of custom UI.
So we wanted to provide the same
kind of visual debugging tool
for SpriteKit developers that we
provide for developers using
UIKit and AppKit.
So I'm pleased to announce that
in Xcode 9 SpriteKit is now a
first-class citizen in the View
Debugger.
When inspecting your view
hierarchy and Xcode finds a
SpriteKit view, it will
automatically snapshot the
SpriteKit scene hosted by that
view and bring that into the
debugger.
So now you'll see Sprites
rendered in the exploded 3D
visualization, along with all
the views in the hierarchy.
This is great for debugging
Sprite layout.
Also really handy for debugging
Sprite layout alongside View
layout for those projects where
you'd like to mix and match
Sprites and views for custom UI.
In the Debug Navigator you'll
see an entry for the SpriteKit
scene as a child of the view
that hosts it, and below that
scene you'll see all of the
SpriteKit nodes that are in that
scene at runtime.
Select a SpriteKit node and you
can debug that by looking at the
Inspectors.
So now SpriteKit developers have
a visual tool for debugging
their SpriteKit scenes at
runtime.
[ Applause ]
But we didn't want to stop at
Sprites. SceneKit is a 3D
graphics framework.
It's great for building rich 3D
worlds and 3D games, as well as
custom 3D UI, so we wanted to
also provide a visual tool for
SceneKit developers, and so we
did.
SceneKit is now included as part
of the View Debugging Workflow.
When Xcode is inspecting a View
hierarchy that contains a
SceneKit view, it will snapshot
the SceneKit scene hosted by
that view and bring that in to
the debugger.
In the Debug Navigator you'll
see an entry for the SceneKit
scene as a child of the view
that hosts it.
But you may notice a difference
here, compared to the SpriteKit
example I just showed.
That SceneKit scene has no child
elements.
Where are all the SceneKit scene
nodes.
Also notice that in the Canvas
the 3D scene is just being
represented by a flattened
snapshot.
So why is this?
Well, to make 2D views in
Sprites explorable, Xcode
explodes them out in 3D.
But what should it do with 3D
content?
Well, we explored the latest
advances in 4D debugging
technology, but after some
accidents in the lab we thought
there must be an easier way, and
there was.
We already have a really
powerful 3D editor built right
into Xcode so we integrated the
SceneKit Editor with the View
Debugging Workflow.
Now just select a SceneKit scene
in the Debug Navigator and Xcode
will open the SceneKit Editor in
runtime debugging mode,
containing a snapshot of your 3D
scene from the runtime.
Now -- [applause] it's pretty
good.
[ Applause ]
So now you can use all the same
tools you're already familiar
with when creating a 3D scene to
inspect and debug that 3D scene.
You can move cameras around or
select alternate cameras.
You can zoom right out to get a
big picture view of that entire
scene, and you can visualize
objects in the scene that aren't
normally visible, like cameras
and view frustums and lights and
the light position and
direction.
You can explore the entire scene
graph in the outline view on the
left and you can select objects
in that 3D scene so you can hide
them or move them around to get
at objects that may be behind
them.
In fact, you can make any
modifications to that scene
using either the Canvas or the
Inspectors, which are all fully
operational, safe in the
knowledge that you won't be
affecting your runtime.
You'll just been modifying an
in-memory snapshot.
And if you'd like to save a copy
of that snapshot, that's easy,
too.
You can just export that out to
a SceneKit or a .dae file to
access at a later time.
So now SceneKit developers have
a visual debugging tool for
debugging their SceneKit scenes
at runtime.
[ Applause ]
So these are the enhancements
we've made for View debugging in
Xcode 9.
We've added View Controller
debugging, SpriteKit and
SceneKit debugging.
To take advantage of these
features your project just needs
to be running on one of the OS
releases from this week; iOS 11,
tvOS 11 or macOS High Sierra.
Now, I had mentioned that
graphics frameworks like
SpriteKit and SceneKit are great
for building custom UI.
They're not just for building
games.
As an example, on the Xcode Team
we use these frameworks to build
our visual debuggers.
This is an example of the Memory
Graph Debugger that we
introduced last year.
It's showing a memory graph for
an app running on an iPhone.
Now, that visual memory graph,
we built that using SpriteKit.
So now we're really excited that
we can use our new SpriteKit
Debugger to debug our Memory
Graph Debugger.
Let me show you how that would
work.
Let's bring in another Xcode to
debug this first Xcode
[laughter].
It's taken a snapshot of that
view hierarchy and it now
includes all of the Sprites that
were shown as part of the Memory
Graph Debugger.
We can select an option to show
all the clip's content.
So now we can see all the
Sprites that are outside the
visible region.
And we can continue to zoom out
to get a big picture view of
that entire scene, a SpriteKit
scene.
So that's an example.
And this is actually what we do
on the Xcode Team.
We use our debuggers to debug
other debuggers.
[ Laughter ]
Now, to make these view
hierarchies exploded out in this
custom 3D visualization we used
SceneKit.
And so now we're doubly excited
that we can use our new SceneKit
Debugger to debug our View
Debugger.
Who wants to see that?
Let's bring in another Xcode to
debug the previous Xcode.
[ Laughter ]
[ Applause ]
So it's taken a snapshot of the
view hierarchy and exploded it
out in 3D, but now, because it's
Xcode 9, we have access to that
SceneKit scene.
So we can select that and we can
view that 3D custom
visualization in the SceneKit
Editor.
We can change cameras, change
perspectives to find the 3D
object in the scene that we're
looking to debug.
So that's the kind of fun we
have in Xcode.
So that's an example, what I've
shown you is an example of using
the new -- Xcode's new SceneKit
Debugger to debug the Xcode View
Debugger visualization, which
itself was SpriteKit debugging
the Memory Graph Debugger, which
itself was Memory Graph
debugging an app on the iPhone.
If you can follow along with all
that, then maybe you've got a
future on the Xcode Team
[ Laughter ]
.
[ Applause ]
Now, to give you a demonstration
of these new view debugging
enhancements, I'd like to invite
up Sebastian.
Thank you.
[ Applause ]
>> Thanks, Chris.
That's awesome.
I'm excited to show you some of
the new enhancements we made to
debugging in Xcode 9, but I'll
be using a slightly less complex
example than Chris just showed
you.
I'll actually be using the same
iOS app that Breckin used
earlier for his application, for
his demonstration, and it's
showing the solar system when
you launch the app, and it's
starting off with a 3D
visualization.
Now, using the button in the top
right corner the user can get
additional details about the
planets, and I've been working
on a very cool feature here.
My idea was to let the user
experience the gravity on the
different planets, so I built a
gravitySimulator using
SpriteKit.
Let me show you what that looks
like.
The gravitySimulator starts off
in zero gravity and the three
objects hover around in space.
Now, when the user swipes down
on the device's display, gravity
is activated and the three
objects begin to fall and
eventually hit the bottom of the
screen and bounce around.
Unfortunately, I got a bug
report that it's not behaving
quite right.
So let me swipe down and let's
observe what is going on.
Oh, now I understand what the
user was talking about.
So it looks like the gravity is
activated correctly, but the
objects don't actually hit the
bottom of the screen and bounce
around, they just go off screen.
Let's see if we can use the View
Debugger to better understand
what is going on here and try to
address the problem.
I'll invoke the View Debugger
using the button in the Debug
bar, and Xcode now fetches the
entire view hierarchy, including
the content of all SpriteKit
scenes that are part of the view
hierarchy.
On the left-hand side you get an
outline representation of that
hierarchy; whereas, in the
center you get a visual
representation.
Now, as you can see, the View
Debugger matches exactly what
you see on the device's display,
and you may be wondering how is
that particularly useful in this
case.
Now, if we recap what happened,
the three objects, they went off
screen, and by default the View
Debugger only shows you objects
that are visible.
Now, we can use this button here
in the bottom left corner to
also show content that is
currently being clipped.
So we can see that there's
actually a lot more going on
here than we can see on the
device's display.
Let me zoom out a little bit so
we can get a better overview.
And we actually found our three
objects down here.
So it looks like what's going on
is that the SpriteKit scene is
just too tall for the device's
display and by the time they hit
the bottom of the scene and
bounce around, they're already
off screen.
So let's see if we can address
this problem.
I'll select the SpriteKit scene
in the Debug Navigator on the
left-hand side and let's take a
look at its properties and see
if we can find one that we can
act on.
So you can see that we can get
additional details about the
SpriteKit scene's size, it's
anchor point and it's scaleMode.
Now, the scaleMode is currently
set to Aspect Fill and that
looks a little bit suspicious.
I think there is a better aspect
fill to achieve what we're
trying to -- what we want the
scene to behave.
We want it to resize to actually
fit the device's display.
Now, I'm setting up the entire
SpriteKit scene in the hosting
View Controller, and since the
view controllers are now
presented right along the view
hierarchy, it's very easy to get
to them.
I can simply select the
gravitySimulator View Controller
and the Debug Navigator on the
left-hand side, and using the
Inspector on the right-hand side
it's very easy to jump right to
the implementation.
I can use this button here that
is right next to the Class Name,
and we're here in the
implementation of this class.
And I'm setting up a couple of
things in viewDidLoad, so we're
here in viewDidLoad.
I'm first assigning the
planetName to the planetLabel at
the top, and here I'm setting up
the scaleMode.
Now, let me change the scaleMode
to something that will better
achieve what we're trying to do
here.
We want the scene to resize.
So resizeFill sounds like a much
better option here.
I'll now rerun and let's verify
if this actually addressed our
problem.
Now, we saw how easy it was to
visually inspect our application
that was using UIKit and
SpriteKit right along each
other.
We were able to get a good
understanding of where our three
objects went.
We were then able to select the
scene, find the property that we
wanted to act on, and use the
view controllers to jump right
to the implementation and make
that code change.
Let's verify we actually
addressed our problem here.
I'll go back to the planet
details and bring up the
gravitySimulator and now I'll
swipe down to activate gravity.
And here we go.
That looks a lot better.
The three objects bit the bottom
and you get a good understanding
of how strong the gravity really
is on this planet.
Now, there's one more thing.
I don't know if you already
noticed.
There's something going wrong in
the solar system in the front,
in the beginning of that.
There's something missing here.
There's a planet missing here,
and I'm not talking about Pluto.
I'm talking about Saturn, and
I'm very confident that my model
is set up correctly with all the
details about the different
planets, and since I'm using
SceneKit to build this 3D
visualization, something must be
incorrectly set up with my scene
graph.
So let's use the View Debugger
to take a look and find out what
happened to Saturn.
I'll again bring up the View
Debugger using the button in the
Debug bar.
And Xcode captures the view
hierarchy, including the content
of all SceneKit scenes that are
part of the view hierarchy.
And as Chris mentioned earlier,
they're now presented right
below the hosting SCN view in
the Debug Navigator on the
left-hand side.
And selecting it opens that
runtime snapshot of the scene in
the SceneKit Editor, which is in
runtime debugging mode.
Now, you can see that besides
the 3D world, it shows you
additional information.
In this case the wire frame
representation of this sphere
visualizes the light source that
I'm using to illuminate the
solar system.
Since we're currently not
debugging a lighting issue, I
can turn off the display of
lights using the Editor menu so
we can focus on the 3D world.
Now, let me increase the size of
the window here a little bit so
we have more space to work with.
On the left-hand side I can
bring up an outline
representation of the entire
scene graph, and when I expand
this graph, you can see all the
SceneKit nodes that I used to
build this screen in
visualization.
And looking down here we can see
that Saturn is actually part of
it, and selecting it gives us
additional details in the
Inspector on the right-hand
side.
In this case we can inspect the
material property and even take
a look at it in 3D.
Now, you can also see that it's
actually part of the 3D world.
And since the SceneKit Editor
visualizes the camera's view
frustum, it's very easy to
understand why we don't see it
on the device's display.
It's simply outside the area
that the camera can see.
Now, we don't have enough time
to go into the code and address
this problem right now, and I'd
actually like to have Breckin
look at the problem after this
session.
So what I can do now, I can
export the current state of this
snapshot using the Export button
in the top right corner and save
that to disk, and I can now
share that snapshot and other
people will be able to just open
that up and use it as a
reference to then go into the
code to address the problem.
So we were able to see how
useful it is to visually inspect
the 3D world that you build
using SceneKit to get a better
understanding of what is going
on in your application.
I think if you're using SceneKit
for your applications, you'll
really find it useful to
visually inspect the 3D world
you built.
[ Applause ]
Let me switch back to slides.
Now, let's recap what we went
over today.
First we introduced wireless
development.
It's a totally new development
in debugging experience
completely without a cable.
I think you will really love it.
And if you're here at the
conference, please use the WWDC
lab Wi-Fi when you try it out.
It's set up so you can use
wireless development.
Next up we went over breakpoint
enhancements.
It's easy and more convenient
than ever before to use
breakpoints for debugging.
And last but not least,
enhancements we made to the
visual debugger.
Namely, you can now debug view
controllers right along your
view hierarchy.
You can inspect SpriteKit
content and SceneKit content.
If you haven't used the View
Debugger before, please give it
a try.
I think you'll find it very
useful to visually inspect your
applications.
For more information, please go
online.
This is the actual URL.
It's in the [inaudible] for our
code.
We also recommend the following
related sessions.
Thank you very much for coming.
Have a fantastic rest of the
week.
[ Applause ]