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.

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.

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.

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

. 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.

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?

Come on. Oh, there we go. All right.

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.

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.

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

. 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.

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.

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.

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.

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.

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.

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.

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.

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.

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

.

Now, to give you a demonstration of these new view debugging enhancements, I'd like to invite up Sebastian. Thank you.

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.

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.