From iPhone to iPad: Simplifying App Design and Development for iOS Devices
By: Svilen Kirov
Today we will be looking into how to take an iPhone app and make it look well enough on the iPad with as little effort as possible. This is a topic that’s relevant for many teams, since designing for iPad usually isn’t a top priority, yet for some reason project managers tend to ship for it anyways.
You would expect that design and development go hand in hand, and for iPhone apps they usually do. However, that is frequently not the case for iPad apps. There is some merit to this behavior, as the same code that runs on an iPhone also runs on an iPad. Yeah, the layout might be a tad off, but is this really that important?
Well … yes. By designing for iPad, you are ensuring that your users on all platforms can get the best experience possible. The resulting higher quality product could not only increase revenue from iPad users, it can also help with brand recognition and provide people working on the team with a sense of pride and accomplishment.
Having said that, here are the four categories which your team might fall into, when it comes to designing and shipping for iPad:
If your team falls into one of the last two categories, you’re in luck. Continue reading to see how to quickly move up the chain.
It all starts with responsive design…
If you already have an iPhone app that behaves well on all iPhone screens, the iPad is mostly nothing more than a couple of extra screen sizes to consider.
Let’s look at the iPhone SE vs. the iPhone 14 Pro Max as an example of different screen sizes. The Pro Max is almost 1.5 times taller and has a significantly higher resolution than the SE. Because of this, it is better at showing higher-quality assets and can display more content on the screen. Why not utilize this and provide iOS users who own the most expensive devices with the best experience?
By the same token, if you design a feature for the beautiful 14 Pro Max screen, how do you make it work on the iPhone SE? Sure, you could make every screen a scroll view, but that does not always result in the best UX. When you add long language localizations into the mix, you can quickly see why designing with fixed sizes doesn’t work even for a single screen size.
Since iOS 6 (2012), Apple has provided us with a technology called Auto Layout to help us move away from fixed-size containers and elements. This makes responsive design for developers way easier and by now should be the default way of working. As it turns out, however, even designers and product managers that have embraced responsive design in other contexts such as the web, don’t really think of mobile as a responsive platform.
To help bridge the gap there, it might be worth having a discussion with them about the different screen sizes on which your app can be used (SE, Pro Max, iPad, etc.). To better convince stakeholders, it might even be worth checking the data for the percentage of users on each device. Firebase collects that information or if you have a Business Insights team, they should be able to fetch that for you.
If your team is already doing responsive designs for different iPhone screens, congratulations! You are very close to having a well-enough looking iPad app.
After doing a responsive design guide for the iPhone, which includes how text should expand in case of localizations and how the elements should look on different screen sizes, you can think of iPad as just another taller and wider screen. It’s completely up to the designer whether they want to resize the components so that they look nice both in landscape or portrait, or whether they want to slightly rearrange the layout to benefit from the extra real estate. Both approaches are valid, and it depends on the business goals.
Now that your app looks decent on the iPad, there are a couple more things to consider. Due to the bigger screen, multi-finger gestures are easier to perform. That’s a great opportunity to make your app even more usable by introducing convenience gestures for power users. In addition to this, iPad users might have access to hardware such as a keyboard, trackpad, or an Apple pencil. Given these tools, it’s worth thinking about how your app’s experience can be enhanced to account for them.
Making your life easier:
Our team has been on the “look well-enough” journey for iPad for the last couple of months and in this section I want to share some hacks that we’ve discovered along the way. They are not the best solutions by any means, but they are some corners that seem to be okay to cut. 😀
- If you are having a hard time designing iPad layouts for all of your screens, you can do yourself a favor and only do it for the most important ones. For the rest of them, you can introduce a max width and/or a max height for the content on it. That way you can preserve the same aspect ratio that you would get on an iPhone screen, thus getting the same good-looking iPhone layout. Sure, you wouldn’t be utilizing the available extra space, but in some cases it’s a good enough solution.
- Aspect fill is your friend when it comes to resizing assets. Make sure that your assets look well enough on the highest resolution devices — iPhone Pro Max and the iPad Pro — and aspect fill will take care of the rest.
- Stay away from UIDeviceOrientation when it comes to UI layout. It’s nice that it supports isLandscape and isPortrait, but did you know that there’s also isFlat? Yup, anytime an iPad is left on a flat surface it’s orientation is neither Landscape nor Portrait, meaning that these checks shouldn’t be used for UI layout. Apple suggests instead to make decisions based on the available space in the current window. (e.g. have one layout if the width is less than 300 pt, and a separate one if it’s more than that).
- On a similar note, isiPhone / isiPad checks aren’t much better and should be avoided when it comes to UI layout as well. The reason being that due to the iPad split screen an iPad window may have a similar aspect ratio to an iPhone one. Therefore any assumptions that the iPad is wider, wouldn’t work here. The solution here is to again stick to the window size, rather than to make decisions based on the current platform.
- Verifying that your screens look okay in both light and dark mode, with both longer and shorter text, in different screen states, for all devices of interest can be an overwhelming task. This is where snapshot testing could be extremely useful when developing with responsive design in mind. It can be used to validate that future changes don’t unintentionally change the layout. An added benefit is that if you want to verify that a specific screen looks good on all platforms, you can just look through the snapshots for it, or even better — bombard your product designer with them.
- Depending on the codebase size it might be useful to have more than one snapshot routine. A shorter one to run on CI, which verifies that key screens look good in most cases, and that the default state of all screens hasn’t changed. Then a longer “nightly” one which could test all possible screens in all possible cases and validate that no bug is left unnoticed.
- For larger codebases it might make sense to create a Gallery-type app. The purpose of such an app is to have a catalog of all of your views with dummy data. It makes UI iterations much faster, since you don’t need to fire up and navigate through the actual app, which usually takes a while.
- An added benefit of a Gallery app is that you can run it on a simulator, which isn’t the case for all apps that rely on unsimulated hardware features. This can be very useful, for example when it comes to weird iOS version-related bugs. It might be quite handy for project managers and designers as well, because they can easily see existing components in the app and choose the best candidates for future layouts.
- SwiftUI’s composability is great when it comes to reusing components for different layouts. From our experience it’s really straightforward to define components to be used in a given screen, then do two independent layouts for wider and narrower screens accordingly. Maintaining them is also a breeze, and the resulting code is easy to follow. An added benefit of SwiftUI is that you can also utilize screen previews, which allows for more rapid UI development as well.
Conclusion
As it turns out, designing for the iPad can be as simple as doing responsive iPhone design with a couple of extra steps. As long as your product team is convinced that the higher quality product associated with responsive design for the iPhone is worth it, it shouldn’t be too much work to push that a bit further to support iPad as well.
Something to keep in mind, however, is that whether you design for the iPad is a business decision. As such, you need to evaluate whether the benefits outweigh the costs. After reading this you would hopefully be in a position to reduce the costs associated with better supporting iPad, which should in turn hopefully make it a more worthwhile investment.
—
Create magic with us
We’re always on the lookout for promising new talent. If you’re excited about developing groundbreaking new tools for creators, we want to hear from you. From writing code to researching new features, you’ll be surrounded by a supportive team who lives and breathes technology.
Sounds like you? Apply here.
