TEAM LICENSES: Save money and learn new skills through a Hacking with Swift+ team license >>

What other tools can help us make adaptive layouts?

Recorded – watch the full episode on YouTube.

Apart from simple size classes, there must be other tools that Apple gives us to help us make these great adaptive layers. Would you be able to suggest which would be the best ones?

Janina Kutyn: So another thing I can think of is the trait variations of Interface Builder. As I said earlier, I'm not someone who uses Interface Builder a lot, so I think I was pretty late even discovering this feature. I'm sure people had been using them for years when I went, “have you heard about trait variations?” This is amazing because you can select the kind of combinations of trait variations.

And again it's not per screen size, so it's not like one way on iPhone SE and another way on iPhone X and another way on iPad. It's more like for a trait variations of a width and length, width and height compact, or width regular height compact, or something else, you can specify different layouts. So you can adjust the constraints or position your elements.

“The only limitation that I have found is that for the elements that exist in multiple variations, you have to use the exact same constraints to express their positions.”

Or you can actually even add UI elements. So if I want a button there on iPhoneSE, but I don't want it there on an iPad for some reason that I can do that using just trait variations. I think it's pretty cool.

The only limitation that I have found is that for the elements that exist in multiple variations, you have to use the exact same constraints to express their positions. So if I remember correctly, you can't add a constraint in one variation, but it's not there in another one for the same element, like, am I wrong in that? I found a limitation somewhere with this.

Paul Hudson: I think they call that installed. Is that right? You, you can, uninstall a constraint for certain variations, I think, but you're right. That is powerful. You can do things like I want this label to have a bigger font size when I have more space and it's just a variation for a simple thing and it works brilliantly. I find the UI a little bit confusing because IB already has a lot to it, lots of buttons and sliders and clickable stuff, and then lots of views around it.

But then also now some things inside there as well, and it becomes a bit more complex again. I do wish though that it was exposed programmatically.

“There's so many traits you can change. It's not just about positioning. So I think that's a pretty cool feature.”

Janina Kutyn: Definitely. That would be nice. It'd be nice to just have the same thing in code, but I do agree with you that the UX is kind of confusing because like when I first stumbled on the feature, I actually thought it was, “oh great, I can do something different for iPad and iPhone because the UI kind of lets you preview this on different screens,” but it's the same trait variation, even though you're looking at a different screen. But yeah, like you said, you can change fonts. You can change colors. There's so many traits you can change. It's not just about positioning. So I think that's a pretty cool feature.

Paul Hudson: I can almost in my head see how that might work programmatically, just like CSS media queries work, you say “for this Mac screen size here are my rules, and for that Mac screen size here are some other rules.” You'd do that programmatically and hopefully it would switch between them automatically. Right now you can spot the change and activate the appropriate rules, of course you can, but I want to say upfront “here are all my rules – programmatically make them happen, please.” Just like you can do with the variations.

Janina Kutyn: And you know, something like this could even live maybe, maybe in trait collections and you'd get these updates if with trait collections change, then that's another one for my wishlist. So more comprehensive trait collections.

Paul Hudson: It's a big wishlist now – Apple had better get busy otherwise it'll be iOS 13 all over again.

This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.

Listen on Apple Podcasts

Hacking with Swift is sponsored by Blaze.

SPONSORED Still waiting on your CI build? Speed it up ~3x with Blaze - change one line, pay less, keep your existing GitHub workflows. First 25 HWS readers to use code HACKING at checkout get 50% off the first year. Try it now for free!

Reserve your spot now

Sponsor Hacking with Swift and reach the world's largest Swift community!

BUY OUR BOOKS
Buy Pro Swift Buy Pro SwiftUI Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Beyond Code

Was this page useful? Let us know!

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.