Wow. Good afternoon, everybody. Good afternoon and welcome. You want to create great apps. And having a great layout is part of making a great app. Auto Layout makes it easier for you to build your layouts, targeting different devices, orientations, adaptations as well as layout for different languages. Today we are going to talk about what's new in Auto Layout, and this session is broken up into three subparts. First is going to be with me. My name is Jason Yao. I'm an Interface Builder Engineer. I'm going to tell you what's an Interface Builder.

Second, Jesse Donaldson from AppKit will tell you what's new in Cocoa, and then third, Marian Goldeen from UIKit will tell you new debugging techniques. With these tools and techniques, you will save yourself developer time and effort when you apply them to your workflow. So, let's get started shall we?

The first topic I want to talk about is something that I'm calling incrementally adopting Auto Layout, incrementally adopting Auto Layout. What do I mean by this? Well, when you are laying out your views inside of Interface Builder, you do not need to constrain everything at once. You can do it incrementally to save yourself time, simplify your setups, as well as give yourself more flexibility. But before I show you how to do this, let's first take a look at an example to set the backdrop. So it all starts by taking a view and dragging it onto Interface Builder Canvas.

You give it a size and position. You compile it and run. And you're going to get that view as sized on the device. Then you go head and rotate the device, and you realize that it's fitting the same size but there is some work that needs to be done. So what's going on here?

What's going on is we're simply pinning this to the top and to the left with the width and height. In fact, what we're doing is we are implicitly creating constraints during compile time so that this view holds the size in -- with the Auto Layout Engine. If you needed more dynamic resize behavior, what you would need to do is go to Interface Builder Canvas and add your own constraints. And the question is could there be a better way of doing this, perhaps a way without constraints, to get simple resize behavior?

There can be. New to Xcode 8 is the ability in Auto Layout documents to be able to specify autoresizing masks on your views that do not have constraints. What that means is that you can get simple resize behavior by specifying autoresizing masks. For those of you who remember a time before Auto Layout you might recognize this UI.

This is the Springs & Struts UI. You can pin things to the edges as well as decide whether it's going to be width or height resizable. And these views are going to work great next to your constraint views. In fact, what we are going to do is we're going to take those autoresizing masks and we are going to translate them into constraints.

But we are going to translate them into constraints at runtime. And there is a key distinction there. We're generating them at runtime and not at build time because it's going to be more flexible and more transparent to you, giving you greater control if you need to do anything programmatic to these views, because for those who are pro-Auto Layout users out there, you might recognize this flag. On the view, we are simply setting translatesAutoresizingMask IntoConstraints equals true.

What about for the views that you've added constraints to inside of Interface Builder? They're going to be the same as before. You click on the view. You are going to see all of the constraints that are affecting that view. Autoresizing masks are going to be ignored and translatesAutoresizingMask for these views will be false.

So, putting all of this together back to the original problem, we can incrementally adopt Auto Layout by first starting with autoresizing masks to so the simple resize behavior, and then add constraints for the more sophisticated behavior. And that gives you greater flexibility. When you are ready to add constraints, choose the subtree that you want to add constraints to, start from the parent, and work your way in.

This allows you to adopt Auto Layout on your terms and is great for new layouts that you are going to be building to get that -- the simple resize behavior, but it's also great for documents where you've been wanting to layout. Well, now you can while preserving your existing behavior. I'd like to show you a demo of this in action. So, let's take a look at what this is.

So, I've got Xcode 8 open with Interface Builder. I am going to build a weather app. I've got my views and I've dragged them into the View Controller, and they are fitting to an iPad portrait. And so, let's take a look at what it's going to look like in landscape by going to the new device configuration bar and switching it to landscape.

Clicking over here, you can see there's work to do. So, let's go ahead and start with the top banner. And we want this to be stretched across the superview. Instead of adding constraints, I haven't added any constraints to this yet, I can go into the size inspector. And of course we've got the Autoresizing Mask Inspector over here, and all I need to do is make it width resizable and pin to the other edge.

Now, I want to work on the children. I'm going to go to the moon, and by default this is pinned to the top and to the left, the way I want it. As for the cloud, I'm going to pin it to the right and get rid of the pin for -- to the left. And then for the label, I want this to proportionally resize and proportionally precision.

So, I'll get rid of the pin to the left, make it width resizable, and you can see there is a little animation showing me the behavior it's going to be. And then we'll just pin it to the top and bottom and make it height resizable as well. Now when we take a look at this thing, we can switch it to landscape, and it's looking pretty good. Let's try two-thirds split screen.

It's almost there, but my label is truncated. What's going on there? What's going on is as you take a look at the label it's doing the right thing. It's using autoresizing mask, and it's proportionally resizing based on its superview. Autoresizing masks do not take into account the content size of your view.

I can fix this up by using constraints, but for this particular case UI label, I do have another trick. I'm just going to go into the Attributes Inspector and then switch it from a fixed font size over to a minimum font size. That way it's fitting into the frame that it's given.

So, now when we go back to landscape full screen, it's looking pretty good, as well as portrait. Next, we are going to deal with the temperature control in the middle. I want a more sophisticated alignment for this. So, I'm going to use constraints. What I could do is I'm going to hold down -- I want to constrain the 75 to the superview. So, I'm going to hold down control on the keyboard, drag out a connection to the superview.

It brings up the constraint menu where I can hold down shift and add multiple constraints at once. So, I want to center it horizontally and vertically and hit add constraints. Similarly, I want to do the same. Control drag to the sunny, hold down shift, and we want to horizontally space this as well as add a baseline constraint. And then do the same to the sun. Control drag, hold down shift, horizontal spacing, and this time center vertically.

Now, my views have the constraints that they need. And we just need to update the frames so that they are in position. And so we are going to go to the Resolve Auto Layout Issues menu, for the selected views and hit update frames. Next, I want to make the temperature control even larger.

So, I'm going to click on that and just increase this font size. And you might notice that when I increase the font size, because everything is already in place, Auto Layout is going to automatically update my frames for me. We do more automatic update frames for you in Xcode 8. So, next, we want to have a nice back drop, and this is a sunny day. So, we're going to go ahead and add an image view.

From the object library, I'm going to go ahead and drag out that image view, size it to my superview, and then set as image, as well as choose its fill mode. In this case, we probably want something like an aspect fill. Now, we want to make sure that this thing is sizing to its superview.

And we could add constraints, four of them, and pin them to each side. But for this simple resize behavior, we don't even need to add constraints because we could go into the Size Inspector and just use autoresizing masks and pin it to all edges, making it width and height resizable.

Last but not least, let's go ahead and put this to the top of my document outline. So, it's in the back. And then we're going to clear the background on my banner because this is a visual effect for you, and we now can see the nice translucency. And then we'll test it out. So, it's looking good -- looking good right now. It's looking good in landscape, two-thirds split view -- two-thirds split view and portrait, as well as iPhone 6s Plus. And so that is how you can incrementally adopt Auto Layout.

The next topic I want to talk about is a little more advanced topic. And it is about mixing design and runtime constraints. There are situations where you could run into this type of thing where you are laying out your views inside of Interface Builder and you're just adding constraints, but you do not know all the constraints you're going to add to views until runtime, maybe because it's based on information like time of day or like data that you're loading that only the run time app knows. There are three tools and three examples I want to walk you through for dealing with these type of situations.

The first is the use of placeholder constraints. In this situation, I've got an image, and I want to go ahead and center it in my device both horizontally and vertically, also a little bit inside form the leading margin. I also want the image to maintain its aspect ratio.

However, I don't know what that final image is going to be, not until runtime. And so, in order to assimilate the approximate size and layout so I can see the Interface Builder, I can go ahead and add a 4 by 3 aspect ratio, approximately what I think it might be, and then mark it as a place order constraint. Therefore, it would be removed at build time. When I actually get the image that I'm going to be setting in runtime, I'll go ahead and create the real aspect ratio constraint and apply it in.

For the second example, pretend you are creating a custom control. Your custom control is going to drive off of something like US -- UIView or NSview. It's going to provide its own drawing, and it also is going to manage its own content. It may want to even provide its own size. It could provide that size to the Auto Layout system by specifying its intrinsic content size.

Interface Builder is not executing that code, and so it doesn't know what your intrinsic content size is going to be, but you can simulate the approximate size of it by giving it reasonable values using the intrinsic size placeholder. Therefore, you could also see how it is going to look like in your layout. Just remember for your custom controls, if you're going to do this, that you do need to provide its real intrinsic content size, and you can do this by overriding the intrinsic content size property on your custom control.

The final example is the one that's new to Xcode, and I'm leaving it for last because it should also be the option of your last resort, when you have exhausted your possibilities for both placeholder constraints and design and intrinsic content size placeholders. And so, we're giving you the ability to tune the ambiguity warning levels on a per view basis.

What that means is that for this view I want to go ahead and center it on screen, vertically, but that's all I know. I don't know what horizontal position it's going to be or what size it's going to be. In fact Interface Builder is drawing this thing is red because it's warning me that it doesn't have enough constraints to be able to position it. It's ambiguous.

I know that I'm going to be adding this constraints later on at runtime when I have all the information that I need so I can go ahead and remove the clutter from the -- from my work space by going to the ambiguity setting and switching it from verifying always to either verifying for position or never verifying at all, and I'm promising to myself I will add those constraints later on so that the view holds its size before the first layout pass.

These are the tools for being able to work with designer runtime constraints when you've exhausted the possibilities of constraining everything you can inside of Interface Builder. Well, what we've seen is how to incrementally adopt out a layout and how to play well with designer runtime constraints, and we're ready for the second part of this session. I'd like to invite up my colleague Jesse Donaldson to talk about what's new in Cocoa. Over to you, Jesse.

Hi, everyone. Today I'm going to tell you about NSGridView, a new layout container that were providing on macOS. So maintenance on constraints can be complicated even when you have something as simple as this set of checkboxes, and we've built in a stack view to make it easier to build things like this. And it's great anytime you need to spread some items across a space.

But there's some kinds of layout that can still be difficult to achieve like this, for example. You can build this with stacks, but NSStackView isn't going to help you align the content across both the rows and the columns. So that's why we've built in NSGridView. It makes it easy to put the content into an explicitly defined grid, and it will take care of alignment for you across both axes. So let's have a closer look.

I took this UI from our voiceover preferences, and I've added these purple lines just to help you see how it can fit into a grid. NSGridView uses a couple of helper classes, NSGridRow and NSGridColumn, to represent the rows and columns, and by default they're sized automatically to their content.

You can also specify an explicit size, if that's what you need. These also let you add some additional padding if you need some extra space here and there in your grid, and if you have some UI that doesn't apply the current hardware configuration, then they can be dynamically shown and hidden.

NSGridView uses a separate class, NSGridCell, to represent the individual cells, and the job of a cell is just to manage the layout for a particular content view. Cells also let you control the placement of the content if the cell has a bunch of extra space in it. And if you have some content that needs to span the boundaries between cells, then they can be merged as you might be familiar with from a spreadsheet program. So, I've built a smaller version of this UI that still has all the interesting pieces in it, and I want to go through this a bit at a time and show you how it's built.

So we intend to provide support in Interface Builder for NSGridView, but until we have it, we're just going to be working with the code. What I've done here is make outlets in my nib file for all the controls that I want to put into my grid, and then whenever you specify a ContentView for NSGridView, it will take care of moving that to be a subview of the grid if needed. This makes it really easy to allocate your grid view at run time and then integrate it into an existing view hierarchy.

There's a few different ways to construct grid views. I think this is the easiest one. All you need to do is specify a list of the content views for each of the rows. And let's get to a couple of things. First, you don't have to worry about sizing the grid. It'll take care of however many rows and columns are needed for the content that you've specified.

Second, the code that you end up with is roughly grid-shaped itself and is at least highly correlated with the UI that you're specifying. This makes it much easier for you or somebody else to come back later and find your way around the code. So, if we just run this, this is what we get. That's not too bad just for calling the constructor, but it doesn't match the design yet, obviously. The most striking problem is just that the UI is very spread out. There are all these gaps, like this one.

And this occurs because the grid view is constrained to the edges of the window. Now when I did that, my intent was to make the window the same size as the grid, but what actually happened was that the grid was stretched to fill the window. If you've used Auto Layout very much in the past, you may have encountered similar problems with text fields or other controls. And we're going to resolve this here the same way, by adjusting the content hugging priority of the grid view.

So, the other controls in this window already have a higher content hugging from the nib file but until we raise the content hugging on the grid view, then it's possible for the window to actually pull the content view edges away from the edges from the rows and columns. Once we raise it, instead we'll see that the edges of the windows are pulled in, and the gap closes up.

So, the next thing I'd like to look at is these labels. They're clearly laid out within theirselves, but they really need to be right justified so that they're up against the controls that they are labeling. And this is easy to change by just adjusting the placement value for those cells.

The x and y placement properties are available on rows, columns, cells, and the grid view itself. The idea is that if the value is not specified on the cell itself, then the value from the row and column will be used or from the grid view if necessary. This makes it very easy to just set the value in one place and then have it affect a wide range of cells. So, in this case, we can get the column at index zero from the grid view and just set the x placement on that column, and we'll see both of the labels hop over to the right side.

The next thing I'd like to look at here is the baseline alignment. The text of the labels is not properly aligned with the text in the controls. And it's subtle in the slide, but it's easy to fix by adjusting the row alignment. Row alignment is inherited the same way as the placement, and for this particular design, it's fine to just have everything in the grid align by baseline. And so, we can set the value in one place on the grid view, and it will affect everything. And if you look carefully, you'll see the text slide into place.

Now, one thing to keep in mind about row alignment is that you may have a bunch of views in your row that are all aligned. And then you may also specify placement for those cells. So, in that kind of a case, the grid view may not be able to satisfy all the requests.

And so, it's important to understand that the row alignment will always take precedence over the placement. The way it works is that we'll take the whole group of aligned content views and then we'll place it using the placement from the first cell. So, the next piece I'd like to look at is this pop-up button. The design has a little bit of extra space above and below the pop-up button, and we can get that space in our layout by adding some padding to that row.

So, the first thing we need to do is fetch the row. We could actually do this the same way that we got the column before by specifying the index, but this way is a little bit better. Instead, we ask the grid view for the cell that contains this pop-up button, and then from the cell, we get the row.

This is better because if someone comes along later and changes the configuration of the grid view to add a checkbox or something like that, this code will still be valid. If you fill your code with a lot of hard-coded index values, then as soon as someone adds a checkbox, you need to go and review all of that code to see which of the indices need to be updated.

And in any case, once we have the row, we can go ahead and set the padding values, and we'll see that we get a little bit of extra space above and below the pop-up. We need a little space over the status cells label as well, and we can achieve that the same way.

So, I want to take a moment here to talk about the difference between padding and spacing. We haven't really talked about spacing much. The padding values are available on rows and columns, and they are just for adding an extra space here and there where you need it in your grid.

The spacing values are available on the grid view itself, and they apply to the spaces between all the rows or all the columns. So, if we take a copy of the design here and we remove all of the padding, then this is what we get. The UI is still properly spaced out, but we lose the visual distinction between the different clusters of controls.

If instead we keep the padding but we take out all the spacing, we get this. We still have our control clusters, but the UI is very cramped together. And of course if you remove both, you end up with this, where the whole thing is just very tightly compressed.

So, an important thing to keep in mind here is that the padding properties all default to zero. You won't have any padding in your grid unless you specify it. But you almost always want some space between the content views, and so the spacing on the grid view defaults to non-zero.

If your use case requires that your views are laid out immediately next to each other, then you'll need to go to the grid view and set those spacing properties to zero. The last piece that's really out of place here is this checkbox, and it's an interesting case because it needs to span the boundary between these bottom two cells. But we can do that by merging the cells, like I mentioned in the introduction.

There are a few methods for this, but in this case, we can just tell the row to merge its first two cells. And when you do this, it has the effect of extending the boundary of the top leading cell to cover the entire merge range. So with this code in effect we see the checkbox slides, and now this content view is laid out across both cells as if they were the same one. And in fact, you can see it's still inheriting the trailing placement from that first column.

We don't really want it to have trailing placement, but we don't want to have leading placement either. This checkbox is actually supposed to be centered on the boundary between the two columns. So, because the columns are not evenly sized, this isn't something that the grid view will do for you out of the box. But it does leave you room to do it for yourself.

And that starts by setting a placement for this cell to none. When you set these placement values to none, it has the effect of causing the grid view to stop maintaining that aspect of the layout. And what that buys us is that the grid view won't be applying any constraints that might conflict with our constraints. So, once that's done, we can go ahead and make a constraint from the checkbox's center x anchor to the leading anchor of the checkbox above it.

And then once we have the constraint, we could actually just activate it like you normally would with a constraint. But in this case, we're going to set it in the custom placement constraints array. If you do that, then it allows the grid view to maintain any custom placement constraints for you, and it will do things like activate and deactivate the constraints depending on whether or not the cell is visible.

So, with this code into place, we see the checkbox shift into position, and the implementation then matches the design. We're finished. Some pieces of the grid configuration here were a little bit complicated, but the whole thing is still much simpler that if you needed to build this UI from basic constraints or even with stacks. In fact, there's not a lot that needs to change in order to expand this to the full UI that I swiped from the voiceover preferences.

So, to summarize, NSGridView is great if your application has a static grid-like UI that you need to manage. And a great way to start working with it is to take all of your content views and put them into a grid and see what you get. At that point, you can iterate on the configuration of your grid until you've reached the layout design that you're looking for. I hope you find it useful. Next, I'd like to bring out my colleague Marian Goldeen, who's going to talk to you about some new debugging tools that she's built. Thank you.

It doesn't happen often, but when it does it's a hang, and then that turns into a crash, and it can be hard to debug. And that's a layout feedback loop. When you encounter a layout feedback loop, you're usually beginning or ending a transition, and it might be something like this. You tap the button to start a transition, and the button responds, but then nothing else does.

So, you're running on Xcode, and you look in the debugging navigator, and you see that the CPU is pegged, memory's increasing, and maybe you break and you look and you just see a bunch of layout in the backtrace. And what's happening is that there is some collection of views that are running layout again, and again, and again in a tight loop. The run loop's never turning. Any messages that are happening are collecting to autorelease objects, so that's all collecting. So that's why the memory's increasing.

And what's driving this is an upstream setNeedsLayout. And what I mean by that is one of the [inaudible] views during its layout is doing something that is causing a more root directed view, to get a setNeedsLayout so when layout finishes its pass, it goes right back to the top and starts again, and what you want to know is what views are involved because that's going to help you figure out where that setNeedsLayout is coming from, why, and what you're going to do about it. This information is actually a little difficult to collect.

So, that's why we're introducing a layout feedback loop debugger to help with these particular situations. This is a launch argument that you add in Xcode. It's the UIView or NSViewLayoutFeedbackLoop DebuggingThreshold, depending on whether you're on macOS or iOS. And you give it a value. I've used 100 here. You can use any value, but we'll clamp it between 50 and 1,000.

Now when you've got this launch argument set, the layout feedback loop debugger will be counting layout subviews for every view that runs layout, and if any of them run more than that threshold within the same turn of the run loop, it will then allow the cycle to continue for a little bit while it collects information. Then it will throw -- raise an exception and dump that information into the logs.

It dumps it to the com.apple.AppKit subsystem or the com.apple.UIKit subsystem, depending on whether you're on macOS or iOS, in both cases the layout loop category. If you want to know more about the new logging subsystems and categories, come to the session at five o'clock today at Knob Hill on the unified logging and activity tracing. Alternatively, you can set a break point in the debugger, an exception break point. And you can print the feedback loop in the debugger, or it's also nice to hit the break point and maybe introspect what's going on a little more.

So, I said info dump, and I do mean info dump. So we're going to go through two examples of real live layout feedback loops that I debugged with the layout feedback loop debugger. Now we're going to look at those logs, warts and all, and hopefully a walkthrough of two different logs are going to help you.

We're going to look at a layout feedback loop that was caused by an upstream setNeedsLayout. This is actually independent of Auto Layout, and another one that was caused by ambiguous layout from constraints, which is very special to Auto Layout. So for the first example with the upstream geometry change, here's a graph of the view tree where the feedback loop was happening. And a lot of view in that view tree were actually running layout.

Often you're lucky and there aren't so many views, and ones like this your heart kind of sinks. But it turned out that ten of them were just churn. They were innocent victims of the actual problem that was happening higher up in the hierarchy. So, what was going on was that that third level view, during its layout, was changing the bounds of its superview.

Now when a views bounds change, it gets an implicit setNeedsLayout because it will need to re position its views for the new bounds. But also if that view that's receiving the bounds change, if its superview is not actually in layout, the superview will also receive a setNeedsLayout so that layout subviews will have the last word on what the layout is.

So when the layout pass gets down to the bottom and finishes, it goes back to the top, and it runs layout on it because that top view still needs layout, which resets the bounds of the middle view. And the feedback loop is powered by the two views fighting over the bounds of the view in the middle.

As you can imagine, there's a lot of layout going on. So, there's a lot of information in the log. So brace yourself. This is what the log looks like, or at least the top of the log, which is where I want you to start when you look at one of these logs. The first thing that's called out is the top-level view that -- of the layout feedback loops. So, in this loop there is no view more root word than this view that's getting layout.

Following that is a recursive description of the subtree under that top-level view. And next to some of the views in that description, you'll see a number. For instance, the -- you will always see one next to the top-level view. In this case it's 23. Those numbers, the ones with the numbers are the views that are actually receiving layout, and the numbers are in ordering. Of course, it's a cycle, so we can put one anywhere. But we do it so that the last one is the top-level view, so it gives you an idea of how many views are involved.

So, that's a 23, but there is only ten down here, and there is three up here, and that doesn't add up to 23. So, what happened? Well, let's go look at the next section of the log, which is the views receiving layout in order. And in this section, you can see that just because there is one loop doesn't mean that every view that lays out in lays out only once.

We have ten views that are laying out, followed by another two views, followed by those same ten views again. And so, those where the more [inaudible] views. And when you see this situation, where you have a bunch of views that lay out more than once in the cycle, they're often victims of the other ones that are more important.

So, as I said early on, we're really interested in where is the top-level view getting its setNeedsLayout from. So, following this section is a lot of detail about the actual -- what's actually happening during the layout. So, we're going to scroll past that down to the bottom of the log to a section called call stacks sent to the top-level view.

So, it's down there, and you just have to look for it. Now, there can be more than one of these. You know, usually there's only one. This was a pretty refractory one, and there were several. They're pretty similar. So, I'm only going to show you one of them.

At the top of the backtrace are some funnel methods for the feedback loop debugger, but pretty near the top you see that in frame five, you see the DropShadowViews receiving a set bounds. And if you remember from the recursive description, the DropShadowView was the subview of the TransitionView. So, the only way that set bounds of the DropShadowView could be causing a setNeedsLayout on the TransitionView would be because the TransitionView is not in layout.

So, that view in frame seven that's running its layout is not the TransitionView. It's something else. But we don't have that information in this backtrace. I didn't have symbols for this particular app. So there, they are not showing up. Furthermore, it could be a view. We're lucky here because it's the DropShadowView that's receiving set bounds, which override set bounds, but it could be a view doesn't override set bounds. But hopefully between the information from the backtrace and the information from the top, you'll know what in the details you're interested in. And so, what we are interested in is the frame changes for the DropShadowView.

So, we scroll back up, and we find where that one -- information is. So, this is under some geometry change information. And we see that in fact these geometry changes to bounds changes and our frame changes -- change are repeating again and again. And two of those changes are coming during layout on the TransitionView, which is rational and what you'd expect.

But one of them is coming from the viewLayoutSubviews method of a particular view controller for the view that's a subview of the TransitionView. So, we've located our problem, and the way to fix this bug is for the programmer to figure out some other way to achieve their ends that don't involve changing the bounds of a superview during layout.

All right, so now we're taking a breath because we're going to example two, which is a different kind of feedback loop entirely. For those of you who have been using Auto Layout to do anything very complicated, you've probably run into the problem of having ambiguous layout. And ambiguous layout is usually not so terrible. Usually you get maybe a bunch of zero size views. And you're like where did my views go, or maybe the view -- the layout is what you want except occasionally you rotate the device or something and you get a different layout.

But sometimes you're really unfortunate, and during the update constraints passes that precede layout, you can exercise that ambiguity. And if that ambiguity gets exercised, then variable changes will occur with each one, and each time it'll dirty layout somewhere. And so you get this cycle. Now an ambiguous layout as a layout feedback loop leads to something that's really that gets you scratching your head unless you think of it. So, that's why when this is likely, we call it out at the top of the log. So they're already thinking about it.

And so, it says ambiguous layout is suspected. And then when you look at the recursive description, you see ambiguous layout all over the place, and, you know, it's pretty suspicious. I'm going to digress here a moment because I have abbreviated things in these logs to make them fit okay on the slides.

And -- but there's an abbreviation in there that you might not recognize that is actually in the logs itself. And that's the tAMIC. You see that right there were it says ambiguous layout. So tAMIC stands for Translates Auto Resizing Mask into Constraints, and now you can all call it that too.

At any rate, so were pretty sure that ambiguous layout is our issue. And we could go look at the backtrace for the setNeedsLayout is set to the top-level view. But I'm not going to show you that. All that's in there is internal foundation and UIKit methods. And it's not helpful to us.

So, in this case, we need to look at the details, and the details here are going to tell us views with variable changes that are triggering layout. And one thing you need to remember about ambiguous layout is it's contagious. So, you might just be missing a couple of constraints. But a bunch of views are ambiguous because they're all kind of dependent on each other.

So, you may have a lot of these, but you just start with one and once that's fixed up, a whole lot of the rest will evaporate if not all of them. So you look at this. You see that the min x variable is oscillating between minus 120 and minus 160, which is kind of odd values anyway.

And because it's ambiguous layout, we list the constraints that are affecting the layout, which you can then hopefully examine and get some idea of what's missing. I'm going to go over now examining constraints because it can be intimidating to see a list of constraints. And drawing pictures is the only way to deal with it.

I like to start with a graph of the view hierarchy of the views that are in -- that are listed in the constraints. And fortunately for this example, the views were all different subclasses so I could label them for you. And the next thing I drew is draw myself a picture of what the constraints were. So the constraints were a minimum leading and trailing padding for the label inside the container.

And there was a centering constraint between the container and the action view. And then the action view had autoresizing mask constraints positioning it within the representation view, kind of positioning it in a weird place. Something's definitely funky with these constraints. And finally there's an alignment between the representation view and its sibling. But there's nothing that actually insists that these -- this whole view hierarchy needs to be in any particular place. So, that's how we got this ambiguity and the layout feedback loop.

So that's layout feedback loop debugger. It's a launch argument. You won't need to use often. But when you do, it should save you a lot of time. And to recap, we saw the -- how you can incrementally adopt Auto Layout and Interface Builder. In AppKit, there's NSGridView for grid-like layout. If you'd like to see that soon on iOS, cast your vote in Apple Bug Reporter. Finally, we have the layout feedback loop debugging threshold. More information on the WWDC website, and have a great rest of the afternoon, and thanks for coming.