Of Tablets, Phones, and Apps

by Steve Wildstrom   |   November 15th, 2012

iOS 6 and Android logos (Apple/Google)This began life as a reply to a comment on Part 4 of John Kirk’s “Why Android Is Winning the Battles, But Google Is Losing the War,” but quickly got out of hand.

John’s post sparked a discussion of Apple’s and Google’s different approaches to developing apps for tablets vs. handsets. Commenter rj said that Apple’s approach is to favor development of “Universal” apps that will run on either the iPad or iPhone. This is correct, but it rather misunderstands what a Universal app is. If implemented following Apple’s user interface guidance, a Universal app will effectively create two different versions in a single package.

The Android guidelines focus heavily on scaling and are marked by a belief that, at worst, developers need make only modest adjustments to phone apps to make them suitable for tablets:

Provide different layouts for different screen sizes

By default, Android resizes your application layout to fit the current device screen. In most cases, this works fine. In other cases, your UI might not look as good and might need adjustments for different screen sizes. For example, on a larger screen, you might want to adjust the position and size of some elements to take advantage of the additional screen space, or on a smaller screen, you might need to adjust sizes so that everything can fit on the screen.

Apple is much more concerned with the need to redesign apps for different display types:

Ensure that Universal Apps Run Well on Both iPhone and iPad
If you’re planning to develop an app that runs on iPhone and iPad, you need to adapt your design to each device. Here is some guidance to help you do this:Mold the UI of each app version to the device it runs on. Most individual UI elements are available on both devices, but overall the layout differs dramatically.

Adapt art to the screen size. Users tend to expect more high-fidelity artwork in iPad apps than they do in iPhone apps. Merely scaling up an iPhone app to fill the iPad screen is not recommended.

Preserve the primary functionality of your app, regardless of the device it runs on. Even though one version might offer a more in-depth or interactive presentation of the task than the other, it’s important to avoid making users feel that they’re choosing between two entirely different apps.

Go beyond the default. Unmodified iPhone apps run in a compatibility mode on iPad by default. Although this mode allows people to use an iPhone app on iPad, it does not give them the device-specific experience they want.

But reading the two sets of programming guidelines, I noticed a much deeper difference. Both, of course, are intended as developer references and contain a great deal of nitty-gritty information about APIs and how to implement specific features. But the Google version is full of code snippets and parameter definitions while Apple’s approach is much more concerned with reminding developers that what matters is the user experience and how good app design contributes to that experience. The Google approach is more practical, but Apple’s may be more useful. I don’t want to read too much into a couple of pages from developer manuals, but at least to me, they do sum up important differences in how Apple and Google approach the world.

 

Steve Wildstrom

Steve Wildstrom is veteran technology reporter, writer, and analyst based in the Washington, D.C. area. He created and wrote BusinessWeek’s Technology & You column for 15 years. Since leaving BusinessWeek in the fall of 2009, he has written his own blog, Wildstrom on Tech and has contributed to corporate blogs, including those of Cisco and AMD and also consults for major technology companies.
  • W. van Dam

    Perhaps one other distinction in the manuals is that Google aims to be as low barrier as possible, hence the hands on code examples, while Apple intentionally raises the bar a bit to avoid that just about anyone starts writing an app.

  • rj

    Thank you for taking the time to respond to my post, with a full article no less.

    I think I understand where you’re going, although I assure you that I do not misunderstand what a universal app is. I think your description:

    ” a Universal app will effectively two different versions in a single package”

    is less accurate than mine:

    “applications that are sold once, but run on both the phone and the pad, providing a tailored user experience for each”

    A typical universal app will likely have much code that is shared by both the iPhone and iPad “versions”: model classes, persistence code, preferences, etc. It isn’t simply two separate apps rolled into one package.

    Apple does appear to be more explicit about distinct phone and tablet experiences, and this makes sense – they effectively only have one size of tablet (1024×768 and its pixel doubled retina counterpart) and two sizes of phone to support. Android, by contrast, targets a continuum of devices – from 3″ cheap phones thru 5″ tweener devices and 7″ tablets up to the incredible 2560 pixel wide Nexus 10. Out of necessity, they have to rely more on scaling, but its not like that’s the only approach they advocate:

    ” At the same time, the system provides APIs that allow you to control your application’s UI for specific screen sizes and densities, in order to optimize your UI design for different screen configurations. For example, you might want a UI for tablets that’s different from the UI for handsets.”

    and

    “Although the system performs scaling and resizing to make your application work on different screens, you should make the effort to optimize your application for different screen sizes and densities. In doing so, you maximize the user experience for all devices and your users believe that your application was actually designed for their devices—rather than simply stretched to fit the screen on their devices.”

    http://developer.android.com/guide/practices/screens_support.html

    Which approach is better? I’m not sure. Apple’s approach makes it easier to produce pixel-perfect designs, but for a more limited range of devices. Android’s allows for a wider range of devices, albeit at the cost of less precisely positioned UIs and the risk of jaggies. Kind of like the way responsive design works on the web today. They’re also better positioned to take advantage of incremental advances in display technology, while Apple can only improve when screen densities double.

    For some apps, precise positioning is most important; for others, sharper text and graphics are preferable. Apple essentially offers the same (high quality) experience on the iPad mini and the full-sized iPad. Android appears to allow for different experiences on the much differently sized Nexus 7 and Nexus 10. it seems plausible that a future version of Android could allow you to run two apps in ’7″ mode’ side by side on a 10″ tablet. Its more difficult to see how the iOS model could accommodate something like that.

    • steve_wildstrom

      You’re right; your description of Universal is better than mine.

      At a higher level, the thing that really struck me reading through the two sets of guidelines is the way Android focuses on the mechanics while Apple focuses on the experience. Maybe I’m reading too much into this, but I think these approaches encapsulate how differently Apple and Google view the problem. For Android to compete successfully in tablets, Google has to work a lot harder on the user experience.