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

Should you design for a big screen or small screen first?

Recorded – watch the full episode on YouTube.

What's a good device to start on: big or small screen? So you aim like in the middle and have it scaled up or down or you aim big and then make it work small or start small and work your way up?

Janina Kutyn: It probably depends on what device you expect your most of your users to be using. Let's say Snapchat: if you're making Snapchat, I would imagine the demographic that uses Snapchat are often all about technology – they understand how Snapchat works. So they might be more ahead of other people in terms of upgrading. I'm just imagining, but maybe that's the kind of user to use Snapchat, so they're upgrading the device more so they might be using the newest thing.

So, then you would think, “okay, I need to target a device that most of these users will be using if you are thinking, okay, most of my users will be business workers who come home and want to sit there and read the news. Maybe that means it's a bigger iPhone iPad or, or something.” It kind of depends on the use case a little bit, but if I don't really know what is going to be the use case, then I generally just pick whatever is the smallest device that's been released. So I guess iPhone 11 Pro.

"Before merging the feature, I make sure to test it on like every screen size."

Janina Kutyn: So whatever the average most recent one was. I usually started with one of those, but then before merging the feature I make sure to test it on every screen size I expect. Some devices have a notch, some devices don't have a notch, some devices support split screen, some devices are just much smaller. So I don't just make it for one device and then kind of work my way towards achieving an adaptivity, I work on a feature-by-feature basis as I go along.

Paul Hudson: So at what level do you say that that's just going to be good enough? You've mentioned the iPhone SE having a particularly small space, particularly in landscape – the vertical space there is very constrained and you start thinking about trying to squeeze a complex layout in there. And I want to factor in Dynamic Type. You know, how far do you take this?

Janina Kutyn: Again, I think it really depends on if you know what your users are going to be using your app on. You could think, “okay, people are probably not using iPhone SE as much because of this. It's an older device now that there's a new one coming out.” Then you probably should focus a little bit on what it's going to look like. It's going to be the new shiny thing, so people are going to start buying it. So it's important that your app looks good on this brand new phone.

“I think you also have to think about what is the biggest font that makes sense for this device, like is this, this might help people who need bigger fonts and bigger letters to see.”

But I guess at that point you might as well optimize it for this device as well and make sure your app looks great at every configuration. I think you also have to think about what is the biggest font that makes sense for this device – this might help people who need bigger fonts and bigger letters to see, but at the same time, if every word is like completely cut off by the screen then you're not really helping them because your text is too large. They can't read it. So there's a threshold of meeting the limits, but do they make sense for the users that are using this feature?

Paul Hudson: And that last part I think is often overlooked because folks feel like they want to go to drag that Dynamic Type slide to the top and the app will still work. That's what they think in their heads, but that's extraordinarily hard to do. And it's really worth taking the time to look Apple's own stuff – navigation bar, titles, app, icon, text, and so forth. It doesn't just carry on growing and growing and growing, they say, “okay, this is the biggest we can possibly handle, so don't scale beyond there.” For example, if you have the accessibility extra size enabled and you long press on a tab bar icon, you get a zoomed up picture of it.

“People have already solved this issue in a way that makes sense for this platform. So why not check out how they did it and apply sort of similar approaches?”

They have just made that text bigger and bigger because it doesn't work. So they've thought about what's the biggest sensible size we can handle and then find other affordances around that that are more useful rather than sort of wrapping four letters per line. It would be a really bad user experience.

Janina Kutyn: Yeah, exactly. Actually, that's a really good point about looking at what Apple does. So they already have people who solved these issues for us. And if you just look at some good system apps, for example, Music is an amazing app. If you just look at what they do, there are a lot of examples, I think often when I'm making something, I think about, “okay, this is actually kind of like the newest app. I've seen some elements there. Why don't I check out what they did?” I will look how they handle this use case. Like people have already solved this issue in a way that makes sense for this platform. So why not check out how they did it and apply sort of similar approaches?

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 Superwall.

SPONSORED Superwall lets you build & test paywalls without shipping updates. Run experiments, offer sales, segment users, update locked features and more at the click of button. Best part? It's FREE for up to 250 conversions / mo and the Superwall team builds out 100% custom paywalls – free of charge.

Learn More

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

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.