As someone who develops for Android and iOS I get asked the same question over and over again by people: “Is developing for Android screens a huge pain? How on earth do you cope with the thousands of screen sizes available?”. Occasionally, they point me to infographics like this one courtesy of OpenSignal showing screen size fragmentation on Android in 2013:
The answer tends to surprise pretty much everyone: It’s not that hard, and honestly causes us less headaches than most people imagine. Firstly, the tools Google give us to lay out interfaces have supported this from day one. You’ve been able to define one or more layouts that scale to various sizes, and if you want to get everything perfect, you can have as many of these layouts as you like, while still keeping the one codebase. The layouts are XML, and don’t live in your code. If you’re an iOS developer they are pretty much the equivalent of XIB files with size classes like iOS 8. The other part people don’t realise is that Android has standardised on screen resolutions for a long time now. To give you a sample, I chose the top 10 most popular phones from our Pocket Casts stats, and added the LG G3 with its crazy new resolution:
LG G3: 1440×2560
Nexus 5: 1080×1920
Galaxy S5: 1080×1920
Galaxy S4: 1080×1920
Galaxy S3: 720×1280
Galaxy Note 3: 1080×1920
Galaxy Note: 800×1280
HTC One M8: 1080×1920
HTC One M7: 1080×1920
Nexus 4: 768×1280
Moto X: 720×1280
Seems like a lot of variation, right? The part that might confuse most non-developers, is we lay everything out at ‘1x’ or ‘1dp’. So on the iPhone you can have a 320×480 pixel iPhone 3G, and a 640×960 iPhone 4, but the interface itself doesn’t change, it’s still 320×480. You don’t have to re-lay out any buttons or do a custom interface for it. All you do is provide higher resolution assets to make things look crisper. The same is true on Android. Take the above devices, and break them down into their 1x/1dp forms:
LG G3 @ 1x: 360×640
Nexus 5 @ 1x: 360×640
Galaxy S5 @ 1x: 360×640
Galaxy S4 @ 1x: 360×640
Galaxy S3 @ 1x: 360×640
Galaxy Note 3 @ 1x: 360×640
Galaxy Note @ 1x: 400×640
HTC One M7 @ 1x: 360×640
HTC One M8 @ 1x: 360×640
Nexus 4 @ 1x: 384×640
Moto X @ 1x: 360×640
There’s no voodoo here, once you break things down into how you’d actually lay them out, there aren’t that many variations. There’s a slight variation in width, and there is in height as well, since some devices have software buttons that take up space on your physical screen. In Android 4.4 and above you can include these buttons into your interface, but for simplicity let’s just assume they take up that bottom space. So let’s redraw that commonly circulated diagram in terms of actual screen resolutions we design for on Android:
The above are literally all the phone sizes we test, support and deploy on. There are of course other phone resolutions and aspect ratios out there, and in the early days of Android there was a lot more experimentation going on with these. For modern apps like ours though, which support Android 4.0 and above, the landscape is much nicer. That’s the beauty of Android’s massive market share, we can ignore all the people with phones running Android 2.3, those with odd and rare screen sizes, and target only 4.0 and above. The resulting group of people is comparable, if not bigger, than the users we target by being iOS 7 only in our iOS apps.
Don’t get me wrong, fragmentation certainly exists in Android, but screen resolutions and sizes are not the main issue. The above diagram and analysis also only take into account phones, not tablets, where designing for physical screen size becomes more important than resolution.