How do we make things look good on all screens?

1) We can do everything programmatically.
	PRO: Everything is out in the open—no ambiguity.
	CON: It takes for-EVER.
2a) Just putting views on your Interface Builder nib will not cut it, for duh reasons.
	- Defaults to iPhone 5/S/C, will try to infer it on other screen sizes—usually fails miserably.
	- Similarly for rotated.
	- Don’t let Xcode blindly make decisions for you!
2b) Autosizing masks—also known as springs and struts.
	- Springs are things that grow and shrink as needed.
	- Struts are HARD boundaries that are obeyed.

	- A spring in the *-direction means your *-size (x: width, y: height) scales with the screen.
	- A strut on one side will force the side to maintain its distance as fixed with the same side of the screen.

	- Use a spring to specify that the size scales in a certain direction.
	- Use a strut to specify that a position doesn’t change with respect to a certain part of the screen.

	- Sometimes these can conflict, like 4 struts, but no springs. Xcode will kinda do stupid things in this case.
	PRO: We look good on all iPhone screens, portrait mode.
	PRO: It seems to solve our issues.
	CON: It doesn’t—sometimes arbitrary scaling with the screen isn’t what we want.

In the three rectangle example, we don’t keep our gap between the bottom rectangle and the two top rectangles—the rectangles scale too much in the y-direction and don’t give the desired effect. Not just that, but the gap in the two top rectangles is too great. So, springs and struts solve some problems, but don’t give us the precision we sometimes desire in complicatedly designed apps.

We need a solution to allow us to make our apps look good on all iPhone screens, portrait AND landscape.

Enter AUTOLAYOUT.

Auto layout is a relatively new (iOS 6) feature that lets you make relationships with other elements of your screen in addition to the screen itself. You basically tell Xcode a whole bunch of constraints you want your object to follow with respect to the screen and the other elements of your view. Width = this, leading space = that, trailing space at least this. This turns into a very large complicated system of (in)equalities that Xcode solves for you.

If you know anything about systems of equations, it’s that you can have ANY number of solutions. You can have multiple solutions. You can have one solution. You can even have zero solutions.  Ideally, in every auto layout spec you make, there’s exactly one solution to the system of equations you create.

To make constraints, use Control-Click-And-Drag to make connections with the other elements (or the screen). Chances are, your connections will be orange. That means that there is more than one solution to your system of equations. Your shit will likely not display properly in some way.

Generally, the best thing you can do is keep adding constraints until everything turns BLUE. Once everything turns blue, it means there’s at most 1 solution to your system. At this point, you should try running your app and rotating it around a few times and see what you get.

Sometimes, you’ll see a giant mess of output on your console. This usually happens when you have over specified your constraints and two constraints cause your system to not be resolvable. Often times, the best thing you can do is take a look at your constraints and figure out what you’ve done wrong, because this is most likely your fault.

At this point, we’re ready to move on to Size Classes. Size Classes is a fancy way of saying “Generic screen sizes”. There are different types of size classes that cater to the kind of app you want to make. In each direction (width/height) there’s COMPACT, REGULAR, and ANY. Xcode will tell you what each thing caters to.

You can define the constraints for SPECIFIC size classes, and even SPECIFIC ORIENTATIONS of SPECIFIC SIZE CLASSES. What you might see sometimes if you own an iPhone 6 Plus is that some size class based storyboards will take advantage of the large amount of real estate you have and make views that are totally custom to that phone.

You can also make separate storyboards without size classes and load the one you need depending on the phone you need. We won’t cover how to use multiple storyboards in your app.

Notice that we’ve written exactly zero code this lecture! And we will write zero. For now.

Now,