Android’s Advantages over iPhone
Android vs. iPhone, Part One
This is part one of a multi-part series comparing iPhone and Android. I’m discussing only phones, not tablets, and focusing on the core of the smartphone user base. That’s a broad demographic, but excludes the inevitable niche users for whom some unusual factor trumps anything I discuss here. (And it’s worth remembering that may include you.) Enjoy.
Last November we moved Emu from iPhone to Android. It meant throwing out a prototype and learning a new platform; but Android removes Emu’s biggest barrier to adoption, and that was worth the trade-off. I’ve always had an iPhone. So the past six months have been a crash course in Android – as a user, a developer, and a product designer.
Lately I’ve seen a number of iPhone / Android comparisons suggesting that for the typical user, you can’t go wrong either way. These baffle me; I’ll get to why in future installments. But a loss is not a shut-out, and there are critical areas where Android nails it while iPhone misses the mark.
Android’s notification system is excellent. Notifications live in a drawer that pulls down from the status bar at the top of the screen. Each also has an icon in the status bar itself, providing a reminder when the drawer is closed. Apps have tremendous control over notification content: text, icons, sounds, vibration patterns, even fully custom layouts. Notifications can be combined – an app can choose to modify an existing notification rather than post a new one. You can clear a single notification by swiping it off the drawer, or clear everything at once with a single tap. A notification can be a widget unto itself, with buttons that provide quick actions without opening the app.
Most apps provide in-app notification settings, but there’s also a toggle in Android’s central Settings app to enable/disable notifications on an app-by-app basis.
iOS also has a notification drawer, but the similarity ends there. The drawer is grouped by app, so if you have a large number of notifications, the ones you care about may not be visible. And you will have a large number, because there’s no way to clear the drawer out. You can clear it app by app, which requires two taps on a tiny button each time. That’s too much effort for most people, rendering the drawer all but useless.
Once the ticker is gone and the phone is unlocked, there is no further indication that you have an outstanding notification. Since your drawer is overflowing, it’s no help in determining if you’ve missed something (and if so, what). So it’s easy to miss things if you don’t stop what you’re doing and address them as soon as they come in. Notifications are disruptive by nature, but while Android’s approach minimizes that disruption, Apple’s maximizes it – as well as that anxious feeling you get when you know you’re missing something important, but can’t quite figure out what.
Apple discourages in-app notification settings, and provides granular app-by-app options in the central Settings app; but they’re so poorly worded and complex that even now I don’t really understand what they do.
Given that Apple’s implementation came after Android’s – and mirrors it in so many ways – the discrepancy is just odd, and smacks of cargo cult design.
Most Android phones have a little light that blinks when notifications are waiting; apps can control its frequency and color. Its implementation could be better — I’m not sure about the multiple colors, and I’d prefer an elegant pulsing like the sleep light on Apple’s laptops. But it’s yet another way in which Android ensures you don’t miss something important. And, Android phones needn’t turn on the screen when a notification comes in; they can just blink the light. So Android users don’t need to keep their phones upside down in meetings.
Apple isn’t good at the Internet. MobileMe was plagued with problems. Apple Maps launched too soon. WiFi sync between Apple devices is spotty at best and replete with strange, unfixable errors. iCloud is convoluted, finicky, and underwhelming. (Who came up with Photo Stream? Why doesn’t it just put my iPhoto photos on my phone?)
But if there’s one thing Google gets, it’s the Internet. If the iPhone is an Internet-connected device, then Android is the Internet in your hand. (I’d say your pocket, but most Android devices don’t fit there.) You don’t connect an Android phone to your computer. You turn it on, put in your Google credentials, and go. Your Gmail is there. Your calendar is there. If you’re upgrading from another phone, your apps simply download and appear, many with their data intact. Your bookmarks and history turn up in Chrome. It really is that simple: the device in your hand is a conduit for your online self.
(It’s not perfect. On occasion, half your stuff never shows up and you have to set it up manually again.)
Multitasking has always been a draw for Android, but early versions of Android got a lot of criticism: because apps ran in the background, they drained the battery. Android’s approach has evolved, and overall it now beats Apple’s.
Behind the scenes, Android is constantly managing which apps — and which bits of each app — are running, to keep resource usage low. Developers must build assuming that if the user isn’t looking at a particular screen, it can be torn down at any time.
So far that’s similar to iOS, and actually more difficult for novice developers: Apple’s platform takes care of a lot of the work for you. But Android developers have the option of creating standalone app components that work differently: “receivers” and “services” that start up in response to a wide variety of system events (location changes, incoming calls, etc.) and can remain running in the background. This makes it easy to keep small, targeted bits of code alive when the main app isn’t; and to start those pieces up on demand.
Apple does provide a limited version of this. For instance, apps that stream or play audio can continue doing so in the background; and an app can wake up and perform brief tasks in response to location changes. But outside a very small set of exceptions, an app that isn’t onscreen can’t do anything.
By way of example:
- When you open the iPhone’s built-in Mail app, your new mail is waiting for you – because it runs in the background. Third-party email apps like Boxer and Mailbox don’t have that ability, so when you open them you have to wait while your mail downloads. Whereas on Android, any email app can do what Apple’s does.
- Dropbox has a “Camera Upload” feature: whenever you take a picture on your phone, it’s uploaded to your Dropbox. On Android, anyway. iOS shuts the app down shortly after you close it, so to upload the photos you’ve taken you have to remember to reopen Dropbox and wait. Inevitably you forget, so your pictures aren’t there waiting for you when you want them.
As the Dropbox example demonstrates, this limitation of iOS breaks the fundamental “cloud” experience, wherein your stuff follows you wherever you go.
But Android’s flexibility does have a dark side. Since any app can run code in the background, a poorly-built app can drain the battery or bog down the device. If your sole criteria are battery life and stability, Apple’s approach is better. But since the iPhone launched in 2007, we’ve gone from a world without apps; to a world where apps supplement core functionality; to a world where mobile software innovation is often in the hands of third party developers. The iOS approach slows that innovation.
Thankfully, Apple has promised improved multitasking for iOS7. As described it will offer many of Android’s benefits, implemented in a way that protects users from excessive resource usage. Time will tell how well it works.
Both platforms let an app use data or functionality that’s part of the operating system itself. For instance, apps can read and write to a user’s calendar; embed interactive maps; be notified of location changes; or display a list of a user’s contacts. But Android provides access to far more than iOS. Apps can receive notifications for a wide variety of system events: incoming calls, battery status changes, when the user turns the phone on, etc. Apps can make and receive calls, or send and receive SMS and MMS messages.
Indeed, the ability to send and receive SMS and MMS is the sole reason we built Emu on Android first. On iOS we’d need to create our own messaging service, ask users to sign up for it, and then request that they invite their friends. On Android, we can be a drop-in replacement for the built-in Messages app: just download and install, no sign-up necessary.
That’s good for developers like us, and it’s good for users. Emu is trying to create a better communication experience; Android lets us focus on that, rather than on building yet another chat service. And by reducing the effort required to try our app, we give more people the opportunity to decide whether our approach is actually better for them.
(The Android flexibility described here is actually the tip of the iceberg. Apps can replace or augment nearly any aspect of the Android experience, from custom launchers to post-call popups to system-wide overlays like Facebook’s Chat Heads. But this extreme flexibility is a drawback rather than a benefit; I’ll get to that in a subsequent post.)
The Back Button
Back buttons are a beautiful thing. They’re like a navigational Undo. No matter how convoluted the information hierarchy, no matter where you’ve been, you can always retrace your steps with a Back button.
Thus, Google’s inclusion of Back as a permanent, hardware-level feature was brilliant – and perhaps not unexpected from a web company. For an iPhone switching to Android it takes some getting used to, but it quickly becomes indispensable.
Suppose you’re in the Facebook app and you tap a Yelp link. The Yelp app opens, showing you the business listing. Now you want to go back to Facebook. On iOS, you have to double-tap the Home button, find the Facebook icon in the drawer, and tap it. On Android? Just hit the Back button. One tap, no thought required.
iOS has a Back button too. Except it’s not really Back, it’s Up: it takes you to the parent screen of your current one, as defined by the app developer. That works well within a single app, where you’re simply retracing your own path through the app’s information hierarchy. But when you’re dropped into the middle of that hierarchy from elsewhere, it’s less valuable and may even be confusing. Furthermore, its placement in the top left corner of the screen is awkward: even on the relatively small screen of an iPhone 4 or 4S it’s a stretch.
One of Android’s great weaknesses is its inability to make difficult product design choices. That tendency rears its ugly head here: despite the excellent universal Back button, Android also includes the iPhone-style Back. As is often the case with such non-choices, it’s a worse experience than either approach individually: users now have to keep track of which type of Back is which, and make a choice between them each time.
Thankfully, both platforms are moving away from the up-style Back button, app by app. Google’s Gmail and Hangouts now use a transient drawer for their top-level screens, accessible by swiping in from the left; Apple has announced it’ll be following suit with its Mail app in iOS7. Facebook popularized a similar approach (employed by Spotify, Flickr, LinkedIn, Mailbox, and many others), and Sparrow for iPhone takes it a step further to handle a multi-level hierarchy. Since most app hierarchies aren’t more than 2-3 levels I suspect we’ll be seeing fewer and fewer Up buttons on both platforms.
When it comes to delivering a clear, responsive, predictable, and usable product experience, Android has catching up to do. But it’s ahead in some non-trivial areas; and lately it’s evolved much faster than iOS. The best-case scenario is one in which two or more platforms provide real competition for one another.
Next time on Android vs. iPhone: All I wanted was a fast Android phone with a high-quality screen that would fit in my pocket.