Note: This is an old post and may or may not accurately represent my current views, current technology, etc.
I’m a big proponent of competition among corporations because I believe the consumer ultimately benefits. That means that, although I’m a major fan of Android, I want to see iOS really innovate and I want to see another mobile OS gain traction. Early on, iOS did a lot to push mobile devices forward and helped set bars in a lot of areas for other platforms to meet. Unfortunately, iOS has not changed much lately and in some ways hurts Android when used as the “golden standard” due to its limitations. A lot of the harm isn’t realized by consumers, but Android developers encounter it constantly when something has to be done “the iOS way” or an Android feature is not even considered because iOS cannot do the same.
Android has had support for sharing between applications since the beginning. This seemingly simple feature provides the user with massive benefit and even allows for interesting glue apps such as Unshorten. Contrast this with iOS where it took until the fifth and sixth generations of the software before basic Twitter and Facebook integration was provided. Not only is this a wildly shortsighted and limited approach, but it also harms startups from competing with these services that receive preferential treatment. Further, this directly harms Android apps (and, by extension, users) because the iOS apps are made with limited sharing support and the Android versions of those apps are expected to mimic the iOS versions. As an example, I developed the CNET News app for Android a few years ago and the design required sharing for just Twitter and Facebook. Despite my best efforts, I couldn’t convince the “powers that be” to allow sharing with all services, so the CNET News app was limited to just sharing via the services that the iOS app supported, which had to be hand-coded in the app. (Note: The CNET News app has since been redesigned, so that limitation is gone and instead the app looks like an iOS app, complete with an in-app back button and inconsistent navigation.)
Despite that Apple pushed widgets on the desktop, they still haven’t done much with them in iOS. The calendar app icon gets special treatment and the notification center has a weather and a stocks widget, but that’s it. You can’t add a widget for displaying your todo list or upcoming calendar events to the homescreen. Third-party apps simply can’t create any kind of widgets regardless of what the user may want. Due to that limitation, many product managers do not even consider that the Android version of an app could have a widget and often should. Widgets are an easy way to improve an app’s value and get that app in front of the user with significant regularity.
One of the most annoying aspects of iOS apps that leaks over to Android is splash screens. Android loads apps extremely quickly, but iOS can take some time, so iOS uses a bit of trickery to give the illusion that it is very responsive. Apps load an image immediately and then replace that with the UI when it’s ready. You can see it when switching between apps too because the default behavior is to take a screenshot when you leave an app and display that screenshot when you return while the app rebuilds itself. It’s particularly noticeable when the battery level jumps around, the rebuilt UI differs from the screen shot, or when you switch into and out of an app quickly and the screenshot doesn’t complete.
App developers have to include an image that is shown when a screenshot is not available and the intent is for this to mirror “empty” UI so that the illusion of responsiveness is maintained. Unfortunately, most apps use this as an opportunity to show a splash screen that’s little more that a glorified branding ad for the app. Product managers think that the designer spent all this time making a nice splash screen, so Android should use it too. The problem is that Android is built to show UI immediately, so a splash screen can be shown no sooner than real UI can be. In other words, you’re being delayed from interacting with the app artificially.
Android has supported multitasking for all developers from the beginning and that includes giving apps a variety of ways to start themselves. For instance, an RSS reader can sync with all the feeds you read at 6am when your phone is still plugged in and on WiFi, downloading all the relevant articles for you. When you open the app a couple of hours later, everything is ready for you and the experience is fast. Similarly, apps can listen to specific events like rebooting or unlocking the phone or even custom push notifications. Unfortunately, iOS apps are much more limited in the ways that they can start, typically sticking with just when the user explicitly starts them or when breaking a geofence. That means a lot of apps that start on iOS and come to Android don’t take advantage of being able to be ready for the user before the user even asks.
Android has always had a significantly better notification system than iOS. Because of that, many product managers don’t consider that notifications are a great way to communicate with the user about certain processes. For instance, if you start uploading a large file in an Android app, you can show an on-going indication of progress via a notification that automatically dismisses itself. The same can be done to indicate the RSS reader, used as an example in the previous section, is syncing. Notifications are actionable as well. You can share a screenshot you took right from the notification or reply to an email you just received.
iOS has always applied strong limits to app icons in the name of consistency (and perhaps performance). The icons are displayed as rounded rectangles with optional gloss/glare and no transparency. The great thing about this is that all the app icons look the same and you have a very uniform appearance. The problem with this is that all the app icons look the same and you have a very uniform appearance. This is a case where the visual appeal is weighted more highly than the usability, and even accessibility, of the experience. Shape is a major factor in recognizing an object, so taking that away from the user is one of the causes behind iOS users frantically scrolling back and forth among their home screens, hunting for an icon. If you throw visual impairments on top of that, icons become even more difficult to identify.
Related to Android’s ability to share across apps is its support for URI schemes. Android apps can declare what types of URIs they support (including support for regular expressions). That means a Twitter app such as Plume can say it handles specific Twitter URLs. Users who have that app installed can tap a Twitter link such as https://twitter.com/IanGClifton/status/318077423424000000 and open it in Plume instead of a browser. iOS does not have the same ability, but it does allow apps to register arbitrary URI schemes, which means you end up with links like myapp://blah rather than something appropriate. Not only does the pollute global URI scheme namespace, but it is entirely broken for people who don’t have your app installed. They get a URI that does nothing and no indication of how to make it work. But, since iOS doesn’t support apps handling the http or https schemes, this is often treated as the solution for both platforms.
You can argue about which is easier to use or more polished, but at the end of the day, iOS does not have as many features as Android and that means it should not be used as the “golden standard” that all apps are targeted for. Take advantage of the features and capabilities of a given device. If iOS has a better WebView, use it; if Android has better sharing support, use it. Don’t let a desire for the lowest common denominator harm your app.