Swift Components Tour – Autolayout Intro – Who? & When?

In this lesson

The Swift Components Tour is over! But let’s talk about autolayout, specifically the who, what, when, where, why, and how of autolayout. Today, ¿who? to use autolayout and when to use autolayout.

Kyle Roberts
Swift Guru at Large

Kyle's Series


Tap on time to skip ahead


Hello world. Kyle here with Brax.tv. Today we are going to answer the last two of life’s big questions about Autolayout. We’ve covered what, why, where and how. But what about the when and who? First, I’d like to apologize. I don’t have much visual references to go with this so this video is going to be mostly this still screen here. But I’ll make it snappy. How about we cover the who first?


This question doesn’t make a ton of sense for Autolayout. The answer could be Apple. The answer could be you, the developer. Who is Autolayout? Why not just everyone? Everyone can use Autolayout. Everyone should. I don’t really have much of an answer here. But I don’t think that’s really my fault, I think that’s more just the question. And that’s the best answer I can think of. Anybody can use Autolayout, as long as you have some base knowledge with iOS. But if you’re this far in the Swift Components Tour, you should have that base knowledge.  I guess I can reword my answer of the who of Autolayout: anyone who’s watching this video. Because if you’re watching this video, you have that base knowledge. You’ve gotten this far. It’s your turn.


Real quick, the final question of the who, what, when, where, why, how of Autolayout is when. I would say the answer to that is whenever possible. I can only currently think of three reasons not to use Autolayout on a new project. Of course, if you’re working in an older project that’s using frame based layouts already, it’s going to be a bit of an effort to recreate all of that with Autolayout. Maybe in the future there might be six different sizes of iPhones and six different sizes of iPads. It would probably be worth the effort to convert it to Autolayout.


Scenario 1: when to not use Autolayout. When you are utilizing the Core Graphics framework. You can make Core Graphics and Autolayout play nicely together but there are also some situations where it’s easier just to accept that you should use frame based layout. A couple examples of those are when you’re working with CGImage and you need to set the size and the placement of an image in a view. But there are still ways around that so that you can still use Autolayout while technically still sticking with the frame based layout for the CGImage. Say you have an invisible view the exact size of the image that you are looking for. While you are working with your CGImage, you can use frames to set up that CGImage and then add it as a subview as that view that you’re using Autolayout with. You’re technically using frame based layouts when you have to for this CGImage stuff but, you actually place that image as superview somewhere on the screen, you can use Autolayout. I guess that’s sort of just a half a point.


We’ll give the other half point sticking in the Core Graphics frame work, to working with PDFs. Now as far as I know Core Graphics is one of the only ways in iOS that you can edit a PDF or build a PDF from scratch. Since a lot of PDFs might have a fixed resolution and it’s mostly easier to use frames while working with Core Graphics, then that’s another situation that you would maybe want to use frame based layout over Autolayouts.


Another scenario, which is what I have in front of us, is that sometimes it’s just easier to use frames. In this specific situation in the master view controller of the Swift Components Tour app, I needed to set one frame on a label in the app. The label we’re talking about, just for reference, is the header label of each section in the master view controller, which are these green bars here. When I was trying to set this up with Autolayout I just wasn’t getting the results that I was trying to get. Even working with Autolayout in code, it just seemed easier to take one line and break a rule – it’s not really a rule – but just break out of Autolayout for a second and set the frame. It’s a very simple easy frame. So that this label in this header view of the table actually looks nice.


Even though Autolayout is great, I think in situations like this it’s perfectly fine to use frame based layouts especially if you’re more comfortable with it and you don’t spend hours and hours trying to look for a solution for such a small detail. I think it’s perfectly fine to use frames. This is the only line in the entire app that we are using a frame based layout. Everything else, Autolayout. It’s pretty cool, but I was having trouble finding a solutions for this without having to make a subclass for this header cell or this header view. I just wanted to keep it simple and do it all in this master view controller of this view for header and section method. So I opted for the frame based layout and it works fine. It works in sync with everything else going on in the app, being Autolayout.


I know I said I had three example scenarios when it’s ok to use frames over Autolayout. But honestly, I completely forgot my third reason. These two I’ve had in my head for a little bit. The third one I thought of while I was talking and now I don’t even remember it. I’m not saying that there are definitely not any other situations where you could use frames. I’m just saying that after you start with Autolayout and you’ve become an accomplished Autolayouter, that it’s hard to go back and it’s hard to think of a simpler time. Thanks for watching.

Additional Info

Register to get access to additional resources and info.