Xcode 9 introduces wireless development for iOS and tvOS. Discover how to configure and use wireless development with your devices. Learn about Xcode's latest debugging features — including debugging workflow enhancements, and new view debugging support for view controllers, SpriteKit and SceneKit — now with no strings attached.
Good morning, and welcome to
Debugging with Xcode 9.
I'm Chris Miles and I work on
We've got a lot of great new
debugging features to talk about
today, so let's dive straight
I'd like to start by talking
about developing and debugging
Let's take a look at our typical
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.
It is now possible to develop
and debug on your device over
Wi-Fi, and we call this wireless
So who can take advantage of
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
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
while the accessory's plugged in
to the Lightning port.
We think accessory makers are
going to love wireless
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
Wirelessly connected Apple TVs
are also supported.
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
Sit back and relax on your couch
while you build the next great
Apple TV game
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
Well, you just need an iPhone,
iPad or iPod touch, running iOS
11 or an Apple TV running tvOS
And on the Mac you just need to
be running macOS 10.12.4 or
What about tools support?
Well, Xcode has extensive
support for wirelessly connected
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
Profiling in instruments works
great as well, and other tools
that also support wirelessly
connected devices, include
Accessibility Inspector, Console
For tvOS developers, Safari Web
Inspector supports wirelessly
connected Apple TVs.
So this is great news for
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
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
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
So that's just been a brief
introduction to wireless
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.
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
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
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
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
Just put that pin code in and
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
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
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
If you can ping the device from
the Mac, you're probably good to
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
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
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
Now, if you don't see a globe,
that means that it's not
connected right now.
Maybe it's asleep in your
Build and run to it anyway.
We'll connect to it
So that's a little bit about how
to get started with wireless
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
I'm going to select Xcode, go to
the Devices and Simulators
And you'll see here's our new
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
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
So I'm going to open an app that
my colleagues and I have been
It's called SolarSystem, and you
can read about it a little bit
in the README.
For now I'm going to click the
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
So as soon as it comes up, we'll
take a quick look at it.
So here are our planets orbiting
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
That should take a little bit of
effort, but people are finding
that they can get there pretty
I'd like to test this out.
So let's think about how would
you test this out before
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
So you can't see the screen, so
I'm going to describe what's
I'm going to jump a little bit.
Okay. Now, the astronaut jumped
quite a bit, but not high enough
Let's see if I can actually jump
to 180 feet.
Did I get it?
Come on. Oh, there we go.
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
Looks like we lost the
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.
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
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
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
So what do we do when we need to
dig deeper into performance
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
I'm going to click the Time
Profile button and this is going
to transfer the debug session to
Instruments and keep the app
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
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
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
Here we go.
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
So now I can scroll up and down
and I can correlate what other
tracks are sharing that
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
So being able to see that all of
these are not correlated
obviously gives you information
Okay. So what we've just seen
are a few things that you can do
with wireless development in
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
And with wireless development
And with that, I'd like to hand
it back to Chris.
What a fun demo.
I'd like to move on to talking
about enhancements we've made in
Xcode for working with
Some of you may not know, but in
Xcode breakpoints have a lot of
There are options that you can
set to customize the way that
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
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
The first of these, we've added
code completion to all the
Breakpoint Editor text fields.
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
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.
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
This should make finding the
breakpoint you're looking for
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
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
So if you haven't been using
breakpoint options, give them a
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
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.
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
View controllers are represented
visually in the Canvas as well.
Xcode renders banners for View
controllers above the views that
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
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
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
Now, not all user interfaces are
built using UIKit and AppKit.
Some designs may require custom
UI with rich interactions and
One option to do this is using
SpriteKit is a 2D graphics
framework and it's available
across all of Apple's platforms.
It's great for building games,
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
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
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
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
So now SpriteKit developers have
a visual tool for debugging
their SpriteKit scenes at
But we didn't want to stop at
Sprites. SceneKit is a 3D
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
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
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
Where are all the SceneKit scene
Also notice that in the Canvas
the 3D scene is just being
represented by a flattened
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
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
We already have a really
powerful 3D editor built right
into Xcode so we integrated the
SceneKit Editor with the View
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
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
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
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
And if you'd like to save a copy
of that snapshot, that's easy,
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
So these are the enhancements
we've made for View debugging in
We've added View Controller
debugging, SpriteKit and
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
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
Let me show you how that would
Let's bring in another Xcode to
debug this first Xcode
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
We can select an option to show
all the clip's content.
So now we can see all the
Sprites that are outside the
And we can continue to zoom out
to get a big picture view of
that entire scene, a SpriteKit
So that's an example.
And this is actually what we do
on the Xcode Team.
We use our debuggers to debug
Now, to make these view
hierarchies exploded out in this
custom 3D visualization we used
And so now we're doubly excited
that we can use our new SceneKit
Debugger to debug our View
Who wants to see that?
Let's bring in another Xcode to
debug the previous Xcode.
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
So we can select that and we can
view that 3D custom
visualization in the SceneKit
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
Now, to give you a demonstration
of these new view debugging
enhancements, I'd like to invite
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
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
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
Let me show you what that looks
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
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
On the left-hand side you get an
outline representation of that
hierarchy; whereas, in the
center you get a visual
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
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
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
So let's see if we can address
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
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
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
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
Now, let me change the scaleMode
to something that will better
achieve what we're trying to do
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
Now, we saw how easy it was to
visually inspect our application
that was using UIKit and
SpriteKit right along each
We were able to get a good
understanding of where our three
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
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
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
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
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
In this case the wire frame
representation of this sphere
visualizes the light source that
I'm using to illuminate the
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
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
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
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
Let me switch back to slides.
Now, let's recap what we went
First we introduced wireless
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
Next up we went over breakpoint
It's easy and more convenient
than ever before to use
breakpoints for debugging.
And last but not least,
enhancements we made to the
Namely, you can now debug view
controllers right along your
You can inspect SpriteKit
content and SceneKit content.
If you haven't used the View
Debugger before, please give it
I think you'll find it very
useful to visually inspect your
For more information, please go
This is the actual URL.
It's in the [inaudible] for our
We also recommend the following
Thank you very much for coming.
Have a fantastic rest of the
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.