What are the common problems when designing for different-sized screens?

Recorded April 24th 2020 – watch the full episode on YouTube.

So what do you say when someone's trying to make an app that works across a variety of devices, iPad, iPad Pro, iPhone, etc. What are the common problems they hit and how should they be worked around?

Janina Kutyn: I think some of the common problems are the screen real estate basically. And the fact that some layouts look just a little bit comical on the iPad.

Some layout looks just a little bit comical on the iPad when you have this table view that's in the middle of the screen where these giant white space on either side and a giant button stretching from edge-to-edge. I worked on those apps that do that. It just doesn't look good. It's not a compelling call to action. I think that's definitely a problem people run into.

But then, what should it look like? I think if you get stuck, it's helpful if you're working with a designer who can tell you what would make it look a little bit prettier. It's of course much harder if you work on your own apps and you don't have anyone who actually has any knowledge of design theory guiding you on that.

I think sometimes people put too much into a screen because they have the big screen, so there's, “we want this and we want this and we want this and this,” and it works all right on the iPad, but there isn't really a sensible way to scale it back down. That's sort of the opposite problem. I guess the problems arise when you start with one device and as an afterthought, do the other, the opposite device.

“I think if you get stuck, it's helpful if you're working with a designer who can tell you what would make it look a little bit prettier. It's of course much harder if you work on your own apps and you don't have anyone who actually has any knowledge of design theory guiding you on that.”

On a more technical level, I think problems happen a lot with trait collections, like with the size classes more specifically, because there are only two size classes, but there's so many different sizes. If you think, “okay, great. I'm just going to treat everything regular as large and compact as small," but then that's not the case. Because for some of the iPhones, something is compact when something is regular and when you turn it, it's the opposite and it's not really what you would expect.

Paul Hudson: It sounds like the big thing is that there's two sides of the same coin here. Too much space, not enough space. It's a beautiful piece of glass with true tone colors and gorgeous layouts or whatever, and you want to put things on there that are useful and interesting and applicable, and it can go either way. It's not a matter of just, it doesn't look good. What should I put in there? It requires some actual planning ahead, right?

Janina Kutyn: What makes sense for navigation of your app, right? If you're planning to have a tab bar controller, what do you actually have, 10 different things that you imagine as tabs? That's not really going to fit very well.

“Instead of going to a big blank screen for your menu, you could use a popover and put your menu into a little popover, or you could take, you could just split your controller and that would automatically help you fill up like both sides of the screen. Like if you use like a table, for instance, with some descriptions, like a master detail view controller.”

Then maybe you have the approach where you have the tab bar ellipsis and you tap on it and that reveals more, and what would you put into the secondary screen of tabs versus the primary? You have to think about what really makes sense for your app. How do you expect the user to navigate through it and how do you expect them to use it?

Or if your way of solving the problem of smaller screen is just put into scroll view, but then maybe a really important call to action, a really important button, is not visible when the user lands on the page and they might miss that it's there. It's really not as simple as just put in a scroll here, or just put it somewhere on the screen.

Paul Hudson: I think a thing that irks me greatly is when I see a navigation view controllers doing a full screen push on iPad. It's like, that looks fine on your little iPhone, but I've got a 12.9-inch iPad Pro, so that's a very big animation just to show me this thing back and forward. It's not a pleasant user experience any more. I can’t just do a little thumb swipe back to get back to where I was; I've got to use the actual back button. That kind of thing says to me, “okay, this app has not been optimized adequately for iPad.”

Janina Kutyn: And I was going to say, it's a shame because their UI could provide such great UI elements that could help you fill up the screen a little bit more or in a more sensical way.

Like for example, instead of going to a big blank screen for your menu, you could use a popover and put your menu into a little popover, or you could take, you could just split your controller and that would automatically help you fill up like both sides of the screen. Like if you use like a table, for instance, with some descriptions, like a master detail view controller. Right.

“If your way of solving the problem of smaller screen is just put into scroll view, but then maybe a really important call to action, a really important button, is not visible when the user lands on the page and they might miss that it's there.”

And what's really cool about those elements that on a small screen, on an iPhone, they just function correctly how you'd expect with the pushes, but then they do a smart layout on the iPad.

Paul Hudson: And it's a simple method call – just present the new view controller please and it'll figure out the correct adaptive way to show that based on the device. I find it a little bit quirky sometimes. Occasionally I get animations that aren't quite right and so forth. But the vast majority, you either work around with some hacks, or it just works first time. And it means you do get iPad and iPhone working great with the correct way of showing things. Just with a single split view controller.

Janina Kutyn: I believe some of those elements even have even been porting to port it to Catalyst. So if I'm not mistaken then, so you kind of get support in the box for like a Mac app. If you use Catalyst.

Paul Hudson: Press the button, right? Check the box! Again, for me, I'm thinking very much in SwiftUI terms, but yes, you can do a great deal. I think what works about Catalyst is that it still looks like a UIKit app. To me.

I like it a lot, but I'm using a Mac. And it's just like, if someone wants to use material design across all their apps because they like Google's design. Fine, you can do that, but I won't like your app. I won't go, “yay, I'm really glad it looks different from the rest of the apps on my device.” I'm never going to say that. And the same is true of UIKit on macOS, sadly.

Paul Hudson: Now there's all manner of layouts and sizes, rotations: portrait, landscape, big, small, split-screen, slide over, one third, two thirds, half. How can you effectively test that huge range of options?

Janina Kutyn: Well, you can do some automated tests that can test this, which I will admit immediately I am not an expert in, but at my current workplace we do a lot of automated tests to make sure things are where they're supposed to be. And the elements are all on the screen that you'd expect.

But in terms of manual testing, I often use the simulator to trigger the split screen, because that actually gives you a big range – you go to half, you go to a third, you rotate; that really gives you a lot of previews of what it will look like on the different widths of screens without actually having to run it on like a million different simulators.

“We do a lot of automated tests to make sure things are where they're supposed to be. And the elements are all on the screen that you'd expect.”

Paul Hudson: Yes. So you can put it through that and literally see for yourself: does this look and work the way I expect it to work? Yeah.

And you've also mentioned a few times size classes, horizontal, vertical, compact, or regular. And they are nice. They're better than nothing, but surely there's not enough. You've got a widescreen landscape iPad Pro 12.9-inch with your app running full screen. That is regular, but also way smaller devices in a fraction of that space. Is are they enough? Do you add extra things around them or something else?

Janina Kutyn: You know, actually that would be another one for my UIKit wishlist! I wish there were more granular size classes. I don't think it makes sense that there are only two size classes.

One, the devices are so varied in their size. So often when I'm writing apps, I kind of make my own size classes where I base it on the size where designers I'm working with thought it makes logical sense to change something. So maybe four screens of this size, this button should be for smaller screens of this size. It should be this size, and the largest should be like this, or the padding or something like that.

Paul Hudson: By size, you mean by size being literally a point width or point height?

Janina Kutyn: Yes! I make it detect what the device or the window size is, and then yeah, configure based on that.

“So often when I'm writing apps, I kind of make my own size classes where I base it on the size where designers I'm working with thought it makes logical sense to change something.”

I know developers really hate magic numbers – nobody likes to hard code numbers into their app. Ideally the system would just handle it all perfectly and it would know would have more granularity, but you sometimes have to do the compromise if ultimately it makes sense.

It's all small devices that are below this width to apply some sort of effect there, then just hard code that number. That's ultimately how websites handle responsiveness also through CSS media queries. So you need to put these thresholds in if you want to handle it more granularly than the two size classes allow.

Paul Hudson: Right. And the size queries, realistically, aren't that complicated on the web – it's more or less small phone, tablet, desktop, and that's it. There's not a great deal going on there. It happens to be, I think it's 1024 or 1023 they use for tablets or 991, because there's a bit of padding here and there with a notch and similar with, but they put in numbers that approximate a phone, a tablet, and a desktop. And that covers the vast majority of cases, I think.

“I know developers really hate magic numbers. Like nobody likes to hard code numbers into their app. Ideally the system would just handle it all perfectly and it would know would have more granularity, but, but it's like, but you kind of sometimes have to do the compromise.”

Yeah, fine. Android has TV, they've got an extra big one for supersize devices, but you know, you don't need a great deal more granularity sometimes.

Janina Kutyn: Yeah, exactly. So if you just need to put in a couple of numbers there that define these thresholds for you and you abstract it away. So nobody working with what you created ever has to actually worry about what those numbers are, they're in one place. If it changes you can replace it, then I think it's okay.

Paul Hudson: Right? I don't think we'll see more size classes, sadly. We might see a replacement for size classes. If you think about that, how much code says “if size class is compact, then do A, otherwise do B” – that would just catch fire, right? That'd be so bad; everyone who just hit compile for their app would break, and they wouldn't quite know why.

But you might see a replacement for size classes, more advanced trait collections, for example, but then of course, SwiftUI has the same size class system. So Apple would just come out and have to break that as well. I don't know.

It's a hard problem to solve. It was simpler to solve it years ago, but it’s probably not simple year.

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