My name is David Duncan. I'll be joined on stage by my colleague Tyler Fox and Russell Ladd. And we're here to talk to you about building apps for every size and shape. So I don't know how many of you were here back when we released iOS2 on the original iPhone. But you had one screen size to work with then.

But today, we've got iPhones. We've got iPads. Multiple sizes. We've got the iPhone 10, the brilliant new screen, and a new shape for you to build your apps to. For this talk we're going to be using our Bagel Times app as an example of a design that adapts beautifully to iPhone 10 and iPhone 8.

And so these are the three things we're going to be talking to you about today. I'll be speaking about safe area and layout margins. How you can use them in your application to adapt to various screen sizes and shapes. Then Tyler will come up and talk to you about scroll views. How they interact with safe area, layout margins, and other UIKit technologies. And finally, Russell will get up and talk to you about using all UIKit tools to build adaptive applications. And so with that, let's get to talking about safe area and layout margins.

So what is a safe area, and what does it look like on the devices that you've come to know and love? Well, on an iPhone 8 with a rectangular screen, the entire screen is a safe area. All of it's there, no overlaps on your content. On iPhone 10, there's a little extra space that's taken up on the top and bottom by the hardware that will be taken away from the safe area for your application.

And in landscape, you've got something kind of similar where we've given you a symmetric layout with space on the bottom for the home indicator for you to lay your content in safely. But what other devices might have a safe area that's not the entire screen? Well, Apple TV actually might give you the situation because certain TVs will have a screen that actually extends past what's visible to the user. And those will represent their information based on something called overscan compensation. And that overscan will be represented as a safe area in any apps that you build for Apple TV.

So now that we've seen a few examples of what the safe area looks like at the screen of a device, how does that get to your views? And how do you use that in your own applications to build adaptive applications? So let's just pick up an arbitrary view. Whole thing.

There are four insets on the top, bottom, and left and right that represent areas that might have some kind of overlay or other thing that might occlude your content if you placed it there. You can access this on your UI views using the safe area insets property. A UI edge inset that has those four values.

Now if you're doing layout with Auto Layout, you actually might want to just see the entire rec that's safe. And you can get that by looking at the safe area layout guide. Which is a UI layout guide that represents that information. It has layout anchors for you to do Auto Layout with. And a layout frame if you just want to see the actual rectangle.

So now that we've seen how that's represented on our view, let's take a look at how it gets from one view to the next. So we'll just take away the text and add a subview. And this is going to cover most of the bottom edge of that view.

Now, how does the safe area get calculated for this? Well, as we saw, that subview that we just added, it intrudes on the unsafe parts of the view on the left, right, and bottom of its superview. And so those are the values that you will see in the UI edge insets represented by the safe area insets property on that subview. And similarly, you'll see a safe area layout guide whose layout frame looks kind of like this.

Now once you've seen this, and you've got a view, you might want to actually add additional insets for your UI. You might decide that you want to add controls through your view controllers that will then add to the safe area or subtract from the safe area for your subviews. So we'll go ahead and add another subview here.

And along with that, it will have a view controller because a view controller is where we actually have the property that allows you to add additional insets. And that property is called additional safe area insets. We're going to go ahead and inherit the insets we got from our parent. Add those additional safe area insets to this view. And finally construct the final safe area that let-- , layout guide.

What other things might you want to know about how safe area behaves in your application? Well, let's take a look at another example. Here we've got one view safely inside of the safe area of its parent. So that view safe area, of course, encapsulates the entire region of that view. And we'll move it closer to one edge and as you might expect, we're not going to gain a safe area because we haven't left the safe area of our parent yet.

We'll move a little bit further out, and you'll see that the bottom inset on that safe area now grows a little bit. It takes up a part where it overlaps, where it extends outside of the safe area of its parent. And as we move closer to the edge there, it continues to extend.

Now what might you expect to happen if we move this view further off the bottom edge of its parent? Well, how about that? The safe area did not grow any further as the view moved outside of its parent. No matter how far outside of the parent that view might go. And you might be asking yourself, "Why would that, why would we do that? What's the purpose here?" And the answer is animation.

In this particular case, we're moving this subview out of its parent. We wouldn't want the content to stay inside of the safe area because then it wouldn't move with its own parent. And as an example, we can see this app. Where we're going to pull up a view on the bottom.

If that view had been laid out against the safe area of the parent, or its parent, and that parent's safe area would extend the farther it grew off the bottom of the screen, then this area would have stayed on screen during the entire transition, which would have meant that you would have not seen the background come up with it. And so that's why the safe area never grows larger on any dimension than what its parent provides.

So to summarize that safe area part, let's took a look at how you can interact with it. Again, we've already mentioned the safe area insets property and the safe area layout guide property. But if your view needs to react to when safe area insets change, then you can override the safe area insets did change method.

Typical thing you might do is just call set needs layout. But if there's any additional logic you need to run, that's okay too. If your view controller needs to respond to its view safe area layout changing, then you can override view safe area insets did change on your view controller. And finally, if you're doing your interface in IB, you can use that safe area property that's shown in the view list to build your constraints against the safe area. And so a safe area is explained. Let's talk a little bit about layout margins.

So layout margins are padding. They're a property that, in general, you have full control over and allows you to specify a space from the edges of the view. Just like with safe areas, they're represented by a UI edge insets property, this time called layout margins. Now last year, we also added directional layout margins.

These differ from layout margins in that layout margins use a UI Edge Insets value while directional layout margins uses an NS directional edge insets. And the primary difference between those two structures is that directional insets use leading and trailing instead of left and right, which makes it really easy for you to create layout margins that adapt to RTL layouts.

So you don't have to do the swapping between left and right when you use directional layout margins. Now, just as with safe area, we provide a margins guide as well called a layout margins guide that you can use with Auto Layout to layout content against that margin. And then we go ahead and put our content inside of that view.

Now the next question you might be asking since we're talking about layout margins and safe areas together is how do the two interact? Well let's go ahead and bring those markers back. Oh yeah, I meant to talk about how you can change those [inaudible] layout. So with safe area, by default, we build the safe area, and then we build the layout margins with respect to the safe area. And we do this for the perfectly obvious answer that by default, you probably actually want this. You want your layout margins inside of the safe area because they represent additional padding against the layout that you want to do.

But we thought to ourselves, "Hey, some people may not actually want this." And so we made it very easy for you to flip this default. And so if you just change the insets layout margins from safe area property from true to false, then we'll go ahead and move layout margins back to the bounds of the view. As a [inaudible] instead of being encapsulated inside.

So what else can you do with layout margins? Well, we already saw that by default, safe area margins propagate down the hierarchy. But with layout margins, they go by default. Because by default, your layout probably wants to be fairly independent with margins as opposed to safe area, which represents a concept that really is for the entire view hierarchy.

But if you want to have propagation, you can flip this on view by view by changing preserve super view layout margins from false to true. And we'll go ahead and line up those margins that are smaller than the parents in order to make sure that everything lines up naturally between a child and its parent view.

Now in years past, you've probably also tried to change layout margins of your view controller views. And if you look at what we do by default. That this margin that you'll see against that view. Now we additionally added a property last year called system minimum layout margins and these margins are the minimum margins that we've combined against any margins you provide now to create the final margin.

So if you wanted to add to the top and bottom of this, you can do that without disturbing the left and right margins that UIKit provides. But again, you might want a little bit more control. And so there's another property called view respects system minimum layout margins. If you want your margins to be completely underneath your control, flip this to false, and we'll use your margins as you describe them, no questions asked.

And so to wrap up with layout margins, the properties you have on UI View are the layout margins property, edge insets, left, right, top, bottom. Directional layout margins. Great for your RTL layouts. Top, bottom, leading, and trailing. The Layout Margins Guide that you can use with Auto Layout to do all this there.

And finally, if you have logic for when the layout margins change in your view, you can override layout margins did change and do whatever logic you need to do there. In Interface Builder to create a constraint that ties against the margin, just check that constraints to margins box. And so with that, I'll bring up Tyler Fox to talk to you about scroll views.

Thanks, David. Good afternoon. And as David mentioned I'd like to talk a little bit about scroll views today. So scroll views are a really key part of the iOS experience. And they show up all across the system. You have them in table views, collection views, UI text view, and of course in all of the custom application in all of your apps.

And so in our app, Bagel Times that we've been working really hard on as you can tell, this is our news article screen. And everything as you can see is sort of centered around a scroll view with the article. And this is we want to you know really showcase the high-quality content our writers are putting together. Like, you know, exploring the true inspiration for, you know, Apple Park. And we want to review some of the basics about how you can use scroll views in your apps to understand how they can help you adapt your content to devices of different shapes and sizes.

So to do that, we're going to walk through an example here, and we'll start with a full-screen scroll view. And on the left I'm going to show you what things look like on more or less a real device. And on the right, we're going to look at kind of things behind the scenes. Understanding what's happening in a diagram.

So everything that we talk about today is going to apply in-- we're going to talk about the y axis of everything vertically. But everything also applies equally to the x axis. And we're also going to use some simple values for illustration. So in this case we'll say that our scroll view has a height of 400 points.

Now inside of your scroll view, you'll have some content. And you can think of the scroll view a lot like a metaphorical picture frame. The scroll view size represents kind of the fixed frame of the picture frame. And then inside of that, the picture is your content. And the content can kind of slide around as if it's on ball bearings.

Now in this case, our content is vertically scrollable. And that happens because our content has a taller height via the content size than the scroll view's height. And here I've turned off clipping on this diagram on the right so we can kind of peek behind the scenes at what's going on.

So scroll views use content offset as a way to represent the current scroll position of the scroll view. Right now, we're scrolled to the very top. So our content offset is at zero, meaning our top edge of the content is aligned with the top edge of the scroll view.

Now, if we go ahead and scroll the scroll view down, that will slide our content up. So let's scroll to the bottom and watch that happens here. And as you can see, the content offset increases and goes all the way to 100 in our example when we reach the bottom. That's because the top edge of the sc-- the scroll view is now 100 points below the top edge of that content area.

If we set a content offset of zero on the scroll view, that will put us all the way back up to the top. And we're back where we started. So that's pretty much just the basics of scrolling a simple scroll view around. Now let's talk about a very important concept about extending the scrollable area of the scroll view. And we do that through a property called content inset.

So content inset is a mechanism for you to provide insets that you can specify from the edges of the scrollable area of the scroll view to the content inside. So adding content inset increases the scrollable area and makes the scroll view able to scroll to a larger area. So let's set a content inset on the top edge here and see what happens.

So here we've set a content inset of 20. And as you can see, that extends that top edge of the scroll view so that the scrollable area is now larger. Now when our content offset is sitting at zero, our content is still aligned with the top of the scroll view. But the scroll view could actually scroll even farther towards the top now.

So let's scroll around like we did before and watch how things have changed. We'll scroll to the bottom and just like before, we're still here at a content offset of 100. That's because we didn't change anything on the bottom edge. And we still have a bottom content inset of zero.

But if we now go ahead and scroll back all the way to the very top, we end up with a content offset that actually goes negative. That's because we are now able to scroll beyond the top edge of our content. And so we can scroll as far as the negative content inset on the top edge.

Now starting in iOS 7, this content inset technique became really important and that's because with iOS 7, translucent bars became really common across the system. And the idea was that you would display your content edge to edge. And it would underlap the bars so that you could get these nice colorful blurs with your content through the bars, right? Tool bars, navigation bars, and so forth. So because this was so common, we wanted a way to help automatically set the content inset on your scroll views to make this easier in your apps. And to do this, we had a property on UI View Controller.

And this was called automatically adjust scroll view insets. And the intent, intent again was to automatically set the content inset on your scroll view whenever it had overlapping bars coming from a navigation bar or a tool bar. And that was whenever your scroll view was inside of a view controller. Which itself was contained inside of a navigation controller.

Now this worked pretty well for some common cases. But if your app had a more custom or advanced usage of UI scroll view, sometimes having your code setting content inset and also UIKit setting that same content inset property could create some challenges. And so starting in iOS 11, we have a much more explicit and powerful way for you to get the same automatic behavior. And the mechanism for doing this is a new property on UI scroll view which we'll talk about now called adjusted content inset.

So starting in iOS 11, we introduced a new property on UI scroll view. It's read only. It's adjust content inset. And this basically describes how the scroll view is actually going to behave. Well you're probably asking what's the difference between this adjusted content inset and the content inset that we just talked about? Great question. Here's how it breaks down.

Adjusted content inset is equal to the content inset that your app provides plus any automatic insets coming from the system or UIKit. And so because we now separate these two, it's a lot easier to reason about what's happening. Of course you might be wondering where and when would I get a system inset on my scroll view.

Well, one most common case will be safe area insets. Let's look at how this works. So we're back to our basic diagram here. But we're going to bring some safe area insets into the mix. So if we go ahead and start out right now we have no safe area insets on any edge. But we'll go ahead and add some safe area insets to the top edge of our scroll view.

And what you'll see is that by default, the scroll view is automatically absorbing those safe area insets on its top edge into its adjusted content insets. And that's because our scroll view's vertically scrollable. And so what this does is this automatically increases the scrollable area and makes it so content can scroll out from underneath anything covering up the top edge like a bar or even the edge of the display.

So take a look at an example here where we have the same scroll view on two different devices. iPhone 10 on the left, iPhone 8 on the right. And you can see this is a real example, the top safe area inset is larger on the iPhone 10 because of the larger status bar height and the sensor housing.

And as a result, the scroll view has a larger top inset-- that's the gray region that's shaded at the top here. So this is one way that scroll view helps automatically adapt to any device that it's running on. Now let's go back to our diagram and talk about something else.

When we have a scroll view like this where we have top safe area insets, let's go ahead and add a subview to our scroll view. And we'll put this right in the content area. And so right now this-- this subview is sitting fully inside of the safe area in the scroll view.

But what if we start to scroll the scroll view down which will move that content up? Just like this so that part of that subview is now sitting outside of the scroll view safe area? Based on the safe area inset propagation that David just talked to you about, you might be thinking, okay, that means the subview is going to start seeing its own top edge safe area inset. That's actually not what happens. The reason why is because when a scroll view absorbs safe area insets into its adjusted content inset, it will no longer propagate those same insets down to its subviews on that same edge.

This is really important. Scroll views use scrolling to move content around and move it out into the safe area. And if a scroll view were to also propagate safe area insets that it was using to extend its scrollable area, it would almost be like double accounting for those same insets in two different places.

And so as a result, the subviews on the scrollable axis are kind of completely unaware that there are safe area insets on the edges that the scroll view is absorbing them into its adjusted content inset. So now that we understand how scroll views work together with safe areas, let's cover the options that we've exposed to let you control this behavior.

The mechanism that you have to do this is a property on UI scroll view called content inset adjusted behavior. And it also is available on interface builder as you can see here. Now the default value for this is automatic. And most of the time, if not all the time, you're really going to want to leave this at its default value. But we want to walk through the options so that you understand what they do and know that they're available. And so you can make the right choice in your apps. So we'll start with the first one.

The first one is the always behavior. This is pretty straightforward as you might expect. Scroll view is going to always incorporate any system inset like safe area insets into its adjusted content inset on any edge. And this works fine in our particular example here. We only have a top and bottom safe area inset on our scroll view. And so it will incorporate those and the content gets to move out from underneath the bars. We don't have any horizontal insets on the left or right. So no problems.

But be careful with this one because if you have something like let's say a table view on the iPhone 10 in landscape, there are left and right safe area insets. Using this behavior the table view is going to incorporate those into its adjusted content inset, which increases the scrollable area, which is going to make a table view horizontally scrollable. You're not going to want that behavior.

That's why we have the next behavior which is scrollable axes. For this one, the scroll view is going to independently consider things on the vertical axis and the horizontal axis. For each of those, if the content size exceeds the width or the height as appropriate, or if you set the always bounce horizontal or always bounce vertical properties to true, then the scroll view considers that axis scrollable.

And it will go ahead and incorporate in the system inset into its adjusted content inset. So in this example right behind me we have a long article that's scrollable. And so we're getting those automatic insets incorporated. But what if we had a shorter article? Let's take a look.

Okay. Here's a shorter article. What's going on here? Let's take a look under the nav bar and see what's going on. Ah. Looks like we've lost our system inset because it's not scrollable anymore. So our title's stuck all the way up underneath the status bar. So let's put back the nav bar and talk about how we fix this. Well, one way could be you could set always bounce vertical on this scroll view if that's the behavior you want. That will make the scroll view always vertically scrollable. Or we'll get to our next behavior, which is automatic.

And so automatic works basically the same as scrollable axes, which we just talked about. But it has one additional behavior as part of it that is when the scroll view is inside of a navigation controller, the scroll view will go ahead and adjust its top and bottom content inset even if it's not vertically scrollable to account for top and bottom bars. So, even in this case where we have a very short article, it still means that we're getting the right insets. And this is generally the behavior you're going to want. And that's why we have it as the default.

Just one quick heads up though. If you are setting the deprecated automatically adjust scroll view inset property to false, that will disable this behavior. And so it's going to behave basically like scrollable axes. Alright, that brings us to our last behavior. Never. Now with this one, as you expect, that means the scroll view is never going to adjust its content inset. However, that has some side effects.

For one, that means that the scroll view will end up propagating safe area insets on all of its edges just like a regular view. And as we talked about before, that might end up giving you some behavior you don't really want. For example, if you recall your layout margins are relative to the safe area, which means your layout margins might end up increasing or changing as a result of this.

This is also going to disable some very helpful automatic behaviors that scroll view provides like automatic scroll indicator insets. And so if you do a search online and you see a favorite, you know, question and answer website suggesting that you set your scroll view's content inset adjustment behavior to never, consider instead using additional safe area insets to increase the safe area insets. If your goal is to try to express to the system that you've added let's say a toolbar or some sort of other overlay.

Or you could consider just modifying the content inset directly, the property that we talked about in the very beginning. That's for you to control. And you can use that to add or subtract from the effective adjusted content inset that the scroll view will see. So with that, I'd like to hand it over to Russell to tell you all about how to put this altogether.

Thanks, Tyler. Now we've introduced many adaptive APIs to help your apps over the years adapt to different environments. And safe area is really just the newest of these. So I'm going to review some of these concepts and also talk about how they work with safe area. So let's go to the first screen of our application.

And we've got a pretty standard setup here with a tab bar controller, continuing navigation controller, containing our content view controller. Now note that the views of all three of these view controllers are full screen. This is what enables the tab bar to extend underneath the home indicator, the navigation bar to extend underneath the status bar, and the content to extend and scroll underneath all of it.

But we need to prevent these elements from overlapping. So let's see how safe area allows these components to do that. So the safe area insets start by flowing through the tab bar controller, which only receives insets on the home indicator and status bar because that's all that it sees.

Since the navigation controller is inside of that, it also receives a safe area inside in the bottom that accounts for the tab bar. And the content view controller inside of both received safe area insets that account for both bars. Now what does the story look like in landscape? Similar. There are safe area insets in the top and bottom. But there are also insets on the left and right that account for the size of the screen. And those are propagated all the way down from the screen through the view controller hierarchy.

Now I want to stop here and use this example to make a point about how you should think about using safe area when you implement your own views. So this custom view shouldn't know that it's running on an iPhone 10. It shouldn't even know that it's contained inside of container view controllers.

This is the idea of encapsulation. If your views only read the safe area insets that are provided to them on all four sides, and are able to adapt to different, to arbitrary safe area insets, that will ensure that your views will be able to, will be modular, can be moved throughout your application and run in different, different environments and still not be occluded.

Now let's jump to an article and talk about hiding the status bar. So hiding the status bar is a technique that would reclaim 20 points of vertical screen real estate on rectangular screen phones. And we're just doing this by overriding preferred status bar hidden in our content view controller and we're turning true. And this preference is then propagating up through our contained view controller hierarchy and respected by the root-- the root of the system.

Now unfortunately on iPhone 10, preferring the status bar hidden does not also hide the sensor housing. So we can't slide content underneath it. [Laughs] So UIKit will protect you and will not allow you to create this UI. Instead, the behavior of navigation controller on iPhone 10 is that it will always display the status bar when the navigation bar is visible. So if you want to hide the status bar and reclaim vertical real estate, our recommendation is to hide the navigation bar and status bar together.

And, in general, when you want to go-- when you want to create an immersive experience, go immersive and just hide all of your overlays and controls together. Not only does this look good and help your users focus on their content, it's also a design technique that will adapt well to all of our devices.

Now, speaking of immersive experiences. Let's switch to the iPad and talk about rendering text in a very wide environment. So here you can see we have text, and it's not extending all the way to the edges of our view. The problem with doing that, if we had rendered the text all the way to the edge, is that it can become difficult to read, for your eye to track from one line of text to the next at a given font size. And so the solution is to always render text inside of a readable width, a recommended readable width provided by the system based on the user's currently selected dynamic type font size. Dynamic type being another adaptive element of our iOS.

Now you can get the readable width with this API on UIView called the readable content guide. So this is another layout guide just like the layout guide for margins and safe area. And it works just the same. And I mentioned that this readable width depends on the user's currently selected dynamic type size, which means if the user changes their dynamic type size in Control Center or the setting app, the readable width will get smaller or larger to compensate.

Now let's switch to portrait and bring in our sidebar with our article list to make the context for our article display much narrower. So here the maximum recommended readable-- readable width is much wider than the space we have to display the article. And the thing to note is that the readable content guide will still not report the maximum readable width necessarily. It'll be clamped to the layout margins, which means you can be confident in laying out your views against the readable content guide. And not worry that they're going to spill outside your margins.

Now let's see how this works on a context for a safe area exists. The readable content guide functions just like-- just like layout margins where its insets add to those provided by the safe area insets. Now normally at the regular-- the default dynamic type font size of the system, the readable width is going to be wider than the width of a device of an iPhone in any orientation which means it won't come into play. However, even iPhones, if the user selects a smaller dynamic type font size than the default, it can come into play, so it's still nice for your application to adopt.

Now let's jump back out to our article list table view and see how readable width can work here. Now the thing to know about table views is that they use their layout margins, I'm talking about the margins, to layout a lot of their UI elements. So that means the separators, the system accessories as well as the labels in the system cell styles. And any views you lay out inside of your own custom table view cells, if you laid them out against the margins, will play along as well.

So that means if you adjust the margins of a table view, you can move all of these elements together. So if you have a table view with a lot of multiline text in it, it makes sense that you would want to adjust the margins of the table view to bring all these elements into alignment and still respect the readable width. So to do this, table view provides an API. Called cell layout margins follow readable width. Now when it's false, table view will use its normal system margins. And if it's true, all the content will inset.

Now, something to note is that the default value of this property has changed in iOS 12. It is now false by default. It was previously true. This shouldn't affect the behavior of your appl-- of your applications too much, especially on phones. Our general recommendation is to leave the default alone and set it to true when you know that you have a table view that's going to contain a lot of multiline text where it would make sense. And this property's also adjustable from Interface Builder with the follow readable width checkbox.

Now keeping with table views but moving on from readable width, there is something else to know how they work with safe area, which is that the content views of your table view cells will not extend beyond the safe area. However, by default, the background and selected background views do-- of UI table view cell do extend beyond the safe area.

So if you have some content you want to place in custom table view cells that you want to overflow outside the safe area and bleed to the edges of the screen, you can either place it in the background or selected background views if the semantics of those views make sense. Or there's a property on UI table view called insets content views to safe area, which by default is true, but you can change to false to get your content views to also extend to the edges. And this property is also configurable from Interface Builder.

Now let's rotate back to portrait. And in the main screen of our application, we mentioned this sheet that slides up from the bottom before containing a picker view. Now the safe area of the screen here means that we have to adjust the layout of the picker view to be inside this safe area.

And most of the system controls, like UI picker view and other controls, and probably controls of your own many views don't make sense to have to know anything about the safe area. Because it's not clear how they would respond or like re-lay out themselves internally. So we have a recommended technique for handling the layout of these kinds of views, which is to place them inside of the container view.

And the responsibility of this container view is simply to position its safe area unaware content inside the safe area by analyzing the safe area insets. And it can also provide the background, which extends beyond the safe area and makes your control feel connected to the edge of the screen in this case.

The-- another technique we want to talk about related to safe area and positioning elements close to the edge of the screen is when you have a control or button that on one device you may want to place directly against the safe area and on another device where the safe area insets are zero you may want some padding.

And the reason for doing this in design is that the safe area insets can sometimes incorporate some implicit padding. So let me bring-- I want to provide you a single solution that will work for both of these situations. So let's bring in a diagram, and I'm going to give you two auto layout constraints that will produce this result in these two different situations.

So the first constraint we need represents the padding that we would other-- we would normally add. So this is just a constant constraint from the bottom of the super view to the bottom of our control. But in this case, we're going to make it not required so that we can break it when the safe, when the safe area insets are non-zero.

The second constraint is an inequality constraint from the bottom of our control to the bottom of the safe area. This ensures that our control is always inside the safe area. So if I change the safe area insets to make them non-zero, you can see that the inequality constraint ensures our content is not clipped while still maintaining some minimum padding.

Now we've talked about many different adaptive APIs in this talk and in previous talks. Layout margins help keep lots of your elements aligned. Safe area insets protect your views from being clipped or occluded. Readable width keeps columns of text comfortable to-- comfortable to read. Size classes inform when you should make large structur-- structural changes to your applications.

And these APIs we use to implement higher-level components in our frameworks. So scroll views, tab view-- table views, container view controllers. The other kinds of things we talked about today reuse these things to ensure that our high-level components can adapt to all of our devices in the simplest way possible. So the takeaway is for you to design your applications in terms of these adaptive primitives as well.

The advantage is that-- instead of coding for a specific device. Your code will be simple, flexible, and it'll guarantee that your applications are as future-proof as possible for all of our different environments. For more information, these slides and recording will be available online. Thank you all for coming, and I really hope you've enjoyed the conference.