MLevel

Multiplatform Layout Considerations for Mobile Apps

Targeting popular screen resolutions and understanding the different image scaling techniques for iOS, Android and Windows 8 devices

Designing across multiple platforms can be tricky business, but in the case of mobile applications it can often become a designer’s worst nightmare. Supporting cutting edge high-resolution tablet screens in tandem with ancient, and much smaller, legacy phone screen sizes can severely increase the amount of design work. This extra work can include the need to create various layouts for target screen sizes (both for phones and tablets), dealing with proportion and scaling issues across multiple native platforms, along with all of the unique assets required for the many screen resolutions and densities across iOS, Android, Windows and other devices.

At mLevel, we are developing our learning app in the Unity gaming platform, allowing us to maintain one code-base with the ability to publish and deploy the app to multiple platforms and devices. This inspired me to research some popular smartphones and tablets to capture some basic data such as screen resolution, aspect ratio and market share to create a baseline layout size. I then created a graphic that is essentially a visual “map” overlaying some popular screen resolutions, which proved very helpful in determining a baseline screen size for our adaptive layouts. In the spirit of communal design, I’m sharing this data in the following infographic in hopes that others will find it useful as a reference resource.

multiplatformscreenlayoutxl

Outlined below is a list of screen resolutions for popular phones within each platform, along with brief explanations of how these respective platforms handle image scaling within their native applications. Let’s take a quick look at the basic ins-and-outs of screen layout challenges for each platform:

iOS Devices

Apple makes designing for iOS devices relatively easy, with a consistent screen aspect ratio of 4:3 for all iPads and 3:2 for all phones besides the newer iPhone 5. The iPhone 5 will simply letterbox older apps that don’t support views for the longer screen, or if your app’s code supports the newer phone it can take full advantage of the longer screen size.

Here are the current iOS devices and their respective screen resolutions:

• 320 x 480 – iPhone 3GS and prior
• 640 x 960 – iPhone 4, iPhone 4S (retina display)
• 640 x 1136 – iPhone 5 (retina display)
• 1024 x 768 – iPad, iPad 2, iPad mini
• 2048 x 1536 – iPad 3, iPad 4 (retina display)

iOS Image Scaling
For iOS devices with retina displays, you’ll need to include a high-resolution version of your graphic that is twice as big as the normal version (if normal is 100%, then retina is 200%), and add a suffix of “@2x” at the end of the file name – but before the file extension (i.e. filename@2x.png). Make sure you place this @2x image into the same directory as your normal image so that retina devices can auto-detect the @2x images and simply replace them in the UI (assuming your developers have coded the app correctly).

Android Devices

Google has made the Android OS an open platform, which means that they have no control over the screen sizes on devices that are running on Android. While this is conducive for manufacturers, it typically means additional work from a designer’s perspective. You’ll need to consider how your layout will scale across the many different screen ratios for these devices. In addition, some devices only support certain versions of the Android OS, which translates into the need to determine which UI features may not be supported in older versions, or the fact that newer devices may not have hard keys for home, back, menu and/or search (so make sure to include a way to search within the viewable UI). Also, it’s important to make sure that your developer specifies the layout dimensions using density-independent pixels (dp units) to ensure that the system scales appropriately for the current screen density, Using pixels (px units) will result in your layout views becoming physically larger on a low density screen (since it has less pixels per inch) and smaller on a high density screen (since it has more pixels per inch).

Here are a few of the more popular screen resolutions for Android devices:

• 480 x 800– Desire, Droid Incredible, Epic Touch
• 480 x 854 – Droid Bionic
• 540 x 960 – Droid Bionic, Droid RAZR
• 800 x 1200 – Galaxy Note
• 720 x 1280 – Galaxy Note II, Galaxy S II
• 600 x 1024 – Galaxy Tab 7”, Kindle Fire
• 780 x 1280 – Galaxy Note, Galaxy Tab 10”, Kindle Fire HD, Nexus 7
• 1600 x 2560 – Nexus 10

Android Image Scaling
Since Android devices come in all different sizes, sporting many different screen sizes (both physical screen size and screen density), you’ll likely have to design image assets in 4 different sizes: LDPI (low resolution), MDPI (normal/medium resolution), HDPI (high resolution) and XHDPI (extra high resolution for tablets).

I typically start with the normal size in a vector drawing program (I use Adobe Illustrator) and scale up/down accordingly as follows: using MDPI as your baseline of 100%, then LDPI = 75%, HDPI = 150%, and XHDPI = 200%. Note that if you’ve already created iOS assets, MDPI will equate to the normal iOS image, and XDPI will equate to the retina (@2x) version of the image – so you can reuse those images for Android MDPI and XHDPI, slightly cutting down on the amount of images that you’ll need to output. You’ll need to place all of these respective image variations in separate directories within the drawable resources named LDPI, MDPI, HDPI and XHDPI in order for them to be properly detected by the OS, making sure to keep the filename exactly the same for each variation (i.e. filename.png). Note that you should only use letters A-Z and numbers 0-9 and underscores in your file names, as dashes and other characters are not authorized in Android image file names.

Windows Devices

The newest player in the mobile space is Windows Phone 8/Windows 8, which takes a completely different approach to handling app layouts across a variety of devices and resolutions. Rather than re-inventing proprietary layout controls, Windows 8 uses built-in support for standards-based adaptive layout techniques such as XAML and the CSS3 grid, featuring flexible box and multicolumn layouts that can be used to easily define the layouts of the Windows 8 UI.

While iOS and Android use very similar UI controls and navigation paradigms, Windows 8 is a totally different world of clickable tiles and sliding panoramics, so you’ll likely spend a fair amount of time rethinking your app layout designs to fit within these new UI patterns.

Here are a few of the latest Windows 8 devices and screen resolutions that we’ve decided to target:

• 480 x 800 – Lumia 900
• 768 x 1280 – Lumia 920
• 1366 x 768 – Surface
• 1920 x 1080 – Surface Pro

Windows 8 Image Scaling
The Windows 8 platform uses 3 predictable scale percentages that are optimized for real devices in the ecosystem. Baseline images with no scaling (100%) are geared for tablets with a resolution of 1366×768, the 140% scale is optimized for 1920×1080 HD tablets and the 180% scale is used for quad-XGA tablets at 2560×1440 – each ensuring that the layouts have content that is the same physical size on the screen and the same layout across each target screen size. Additionally, the Windows 8 platform also natively supports vector graphics such as SVG or XAML that will seamlessly scale graphics without blurring or pixilation.

Automatic resource loading allows developers to save three versions of images with a naming convention (corresponding to the respective scale percentages of 100%, 140% and 180%) that will detect screen size and automatically load the proper version of the image. You can use a simple naming convention such as filename-file100.png, filename-file140.png and filename-180.png and place the various files into the same directory in order for the system to properly detect and display them.

Conclusion

So what’s the ideal baseline for designing a mobile layout across multi-platform devices? Using the screen resolutions mentioned above produced an average (mean) screen size of roughly 778 x 1250, which contains an aspect ratio of 16:10. However, the most frequently occurring (mode) screen aspect ratio within this data set is actually 16:9. This shows that mobile screen dimensions are generally trending toward higher pixel resolutions within a longer width (just look at the newest iPhone), ideal for widescreen movie playback and game play. Ultimately, we chose to use a more standard screen resolution of 800 x 1280 that was very close to the mean screen size.

As you can see, developing native apps across multiple platforms can be quite challenging. But with some forethought – and a bit of strategic and tactical planning – you can ensure that your mobile app layouts will translate correctly across a vast array of devices and platforms.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

Leave a Comment