The Negative Impact Of iOS On Android

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.

Sharing

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.)

Android and iOS sharing screenshots

Android sharing on the left; iOS sharing/actions on the right

Widgets

iOS notification center screenshot

Widgets in the iOS Notification Center

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.

Splash Screens

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.

iOS photos and foursquare screenshot

What iOS developers are supposed to do on the left; the branding splash screens that they really do on the right

Background Syncing

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.

Notifications

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.

App Icons

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.

Google Maps Android and iOS icons

Google Maps Android icon on the left; iOS icon on the right

Various iOS icons

After a while, they all start looking like rounded blue squares

URI Schemes

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.

Conclusion

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.

About Ian G. Clifton

Ian currently works as the Director of User Experience for A.R.O. in Seattle, WA where he also leads Android development. Previously, he has worked as an Android developer, web developer, and even a Satellite, Wideband, and Telemetry Systems Journeyman in the United States Air Force. He has created the Essentials of Android Application Development LiveLessons video series and has just finished his first book, Android User Interface Design: Turning Ideas and Sketches into Beautifully Designed Apps. He spends his off time on photography, drawing, developing, and doing technical review for other Android developers. You can follow his posts on this blog or his ramblings on Twitter.
This entry was posted in Mobile Development and tagged , , , , , , , . Bookmark the permalink.

79 Responses to The Negative Impact Of iOS On Android

  1. calvin kelly says:

    Thanks! very informative.

  2. Chris says:

    I entirely agree that these are two different platforms with two different feature sets, and that designing entirely for the lowest common denominator without taking advantage of the OS’s specifics (either iOS, Android, Windows or whatever) is utterly the wrong way to go. However, this article, while mostly accurate, contains a bunch of inaccuracies regarding iOS I’d like to point out. Starting from the bottom:
    • Url schemes are not “entirely broken for people who don’t have your app installed” — developers can use code to check whether an URL scheme can be opened, which means that they can check whether an app is installed or not. A lot of apps use this, but this is up to the developer to implement, in addition to any fallbacks that may be required.
    • Background syncing is possible when implemented carefully. Currently it’s limited to sorry 10 minutes of time, or to Newsstand apps, but it’s possible. Again, it’s up to developers to work with the system.
    • When switching apps, the battery levels don’t jump around (that sounds absurd) — the status bar state is not saved when an app is backgrounded, that’d just be silly. The status bar is painted over whatever is going on in the screen.
    • I must admit I’ve not used Android that much, but does it really load apps instantly? Does it really? Even when the phone has just been restarted and the app has not been running in the background already? I doubt that, as any software needs time to start up.
    • The iOS notification center is for notifications, and cramming it full of widgets makes it not a very useful notification center. Bad idea.

    Otherwise, a lot of fair points. I hope iOS catches up in some areas.

    • Hi Chris, thanks for the feedback.

      Maybe I should have clarified that as custom URI schemes that are exposed to the user. If your email says myapp://blah it will just be text that doesn’t lead anywhere. That’s broken for the user. The same is true if it’s in a browser or otherwise exposed. Schemes used behind the scenes can be handled by the apps, as you say.

      It’s my understanding that you only get ten minutes of background time as the app is leaving the foreground, which does not help with the syncing issues most important to the user (having content read when I open the app regardless of when I last opened it). Am I mistaken? Is an iOS app able to open itself at a specific time to do background syncing?

      The battery state does jump around. I see it daily on the phone I use to test the iOS app at my work (iPhone 4). Perhaps it’s more noticeable because the iPhone 4 is slower or because I have it displaying the battery percentage and frequently go for long periods without using it. I pointed it out to one of our iOS developers and he explained it being related to the screenshot issue and suspected it was due to being able to support different status bar backgrounds now.

      I didn’t say Android apps open instantly. I said “Android loads apps extremely quickly.” Android was explicitly designed to start apps quickly and it does; it also uses tricks to keep animations smooth and responsive when switching between apps, but those are based on the app’s properties such as the background of a given theme (not images in the app) since there isn’t necessarily a single entry point for a given Android app. Adding a splash screen to an Android app artificially slows the loading and only makes sense when it’s really necessary (e.g., loading a large number of OpenGL ES textures).

      “The iOS notification center is for notifications.” Excellent point, though I’d argue that the notification center should be for whatever the user wants to be notified of (which could be notifications in the form of widgets). Regardless, that paragraph explicitly mentioned how you can’t add something to the home screen in iOS, so product managers often don’t consider that you can do that in Android.

      • Great article, I just got one little correction about the splash screen on Android. It is indeed just delaying the application being load and shown, if it’s implemented the wrong way (which is unfortunately the common practice), but used the right way, it can be very helpful. As example, I’m currently building an application where the content is completely remotly configured, I could sync it within given intervals, but it would be counter productive, because it’s intended to be used on demand only (check the website I attached for further informations about the app, if your interested, but bare with me, it’s still beta stage). So I’m using a simple full screen dialog (not as activity where loading of the main activity is blocked) which is shown till the content is loaded in the background (as user you won’t notice a difference compared to the activity approach, except that this way the app itself is shown faster), so the splash screen pattern can indeed be very useful if it’s used the right way, but that’s somehow the biggest advantage and downfall of android compared to iOS, you have much more possibilities, but at the same time much more possibilities to mess things up.
        To most other things I agree completely.

        • Agreed. The short of it is that you shouldn’t use a splash screen unless one is needed. In iOS, it’s always needed; in Android, it usually isn’t needed. I originally detailed a few examples of when it is such as while loading a large number of textures via OpenGL ES, but I stripped that out when I was trying to shorten the already lengthy post. One more nice difference with an Android splash screen is that you can indicate actual progress.

  3. Jeff says:

    The best way I can explain it is that iOS is still designed in a world where the App Store doesn’t exist.

  4. PeeKay says:

    Good Points.
    I recently had an email conversation with an app developer who develops cross platform mobile apps. The thing I really hated the most is the fact that they want to release software updates for all the OSes simultaneously. And as a result, updates to Android are delayed as the approval process for iOS can take up to a week before you can release the updates software. I argued that , in today’s high paced world, one week is just one week too much. On android, it is more than enough time to launch the app, wait for user feedback and analytics data to come in, smoothen out bugs ( if any ), begin working on new functionality and have a newer and better version of your software out even before your current iOS version even gets approved.
    Sadly, I got some canned Mumbo-Jumbo as a response.

    Developers need to realise that their apps should not look and function exactly the same on all the devices. In fact, they should embrace each platform independently, and develop following each of their platform and ui/ux guidelines and make thier app love up each of the OSes .. Be it Android , iOS or even WP7/8 or BB or any other OS

    • The app approval delay is another really common and frustrating one. I’ve had Android apps sit for weeks because the iOS counterpart was awaiting Apple’s approval process. Sometimes you can convince product managers to allow the Android app to go out first by explaining how it can help catch any issues with the app that might also affect the iOS app, but that doesn’t always work.

  5. Rob says:

    Bravo, an excellent discussion and easy to understand simplification of a complex issue. I have always said that Android was more capable and had more functionality than ios but was always scoffed at. And an excellent explanation of how ios maintains the illusion of being quick and responsive with animations rather than actual performance.

  6. rainabba says:

    I say all very good points but the single largest one is quite simple. Companies need to stop thinking in terms of iOS PERIOD. It’s old news and companies that fail to recognize and accept this are cutting themselves off at the knees. When a product or app is designed for iOS FIRST (or only) and there’s not a proper reason (like in support of some apple-only service/system), then they’re missing out on the largest market segment regardless of how good or bad their product is. Still, I see it all the time and it boggles my mind.

    • Q says:

      Not even close to accurate. iOS is still a higher spending and much more engaged audience. Android may have more users by pure naked numbers, but the majority of them aren’t app buying or even app using users.

  7. Shane says:

    Great post. Seeing that you are a developer though can you answer why the Android and iOS are not treated different. Car manufacturers don’t do this, home builders don’t do this, and as parents we treat each child or member of the family differently based on that persons emotional needs. I prefer Android and there are some things I like about Apple but if developers are short changing us based on a perceived gold standard then it’s time to wake up. At this point Android is the platinum standard and it’s time for people to recognize it

    • I think the reason is largely because iOS was more polished off the bat. Android 1.0 had a lot of features that iOS didn’t (and some it still doesn’t), but the usability was significantly worse. Since the OS felt inferior, it was treated as being inferior. Combine that with many designers choosing iPhone because they already use and like Apple products and a decent number of managers and executives using iOS (or BlackBerry and not caring), and you have strong voices for the iOS way. Android has long since improved, but the mindsets of many have not changed.

      • Peter Brülls says:

        Uh.. I can sympathize to some extent, but you have a really big blind spot here:

        “Since the OS felt inferior, it was treated as being inferior.“

        No, an OS – this includes the UI – that feels inferior to the user *is* actually inferior.

        Arguing otherwise is like arguing that, say, Disney’s queue management may make waiting times only *feel* shorter than those of their competitors, but aren’t really different.

        While technically – in a spec-checking way – correct, it misses the point.

        (Thankfully, Google started catching up in that area.)

        • A car that “feels” good to sit in is not necessarily a better car since more goes into that consideration than just the feel (value, build quality, maintenance costs, fuel economy, etc.). One of the reasons Android appealed to me early on is because it could do so many of the simple things iOS could not like attaching multiple photos to an email or even adding an attachment while composing a message. I was willing to put up with GC hiccups to have all the features that made the device useful to me.

          • Tim F. says:

            You’re making the same mistake. The car with the most horsepower or the most upgrades also isn’t the best car because people consider other pros and cons as well.

      • NullCorpus says:

        Project Butter was a big deal for Android (first visible in Jellybean..) It represents the first time I’ve really seen iOS users oooh and aaaah over an Android tablet (Nexus 7 brought home from I/O)..

        Steve Jobs was like a walking Project Butter.. from the onset, iOS had as much display smoothness as the hardware could handle. It made it difficult to convince iOS users to take a second look at early Android devices and OS versions, despite Android having a superior set of computational features

  8. Josh says:

    I agree that Android and devices that run Android have advanced to the point that in many areas they offer superior features, functionality and performance to iOS and iPhones. However, this distinction is VERY recent in the larger lifespan of the smartphone industry. Since the day 3rd party apps for iOS were allowed by Apple, iOS actually HAS been the gold standard – because Android and Android devices were really far behind. It hasn’t really been until 2012 that Android and devices (e.g., Samsung Galaxy S III) have started to truly outperform iOS and iPhone in many areas. Because of the fact that Android dominance is very, very recent, it will take a little time for companies, ad agencies, software publishers, etc. to change their ways. It doesn’t happen overnight. Artists have to be trained a little differently, programmers have to think differently, ad budgets have to be re-focused, etc. It’s a large machine…

    Also, one last thing. The author conveniently left out one of the most annoying limitations of Android that has always made my life more difficult when doing cross-platform mobile development – maps. Android only allows the developer to only ever create a single map “instance” in code. So if you have different screens of your app that use a map for different reasons, you have to clear out that one map, save any markers or overlays that were on it for screen A, draw all the things on it for screen B, and swap back when the user switches back and forth. What a nightmare. On iOS, you can create as many maps as you’d like, which makes map management SO much easier. (I’ve been out of the loop for the last 6 months, so correct me if i’m wrong about the maps).

    • I disagree that the feature superiority of Android has been recent. Most of this blog post covers Android 1.0 features. However, I would say that the UX of Android didn’t take a leap forward until 4.0. My opinion, though, is that you should take advantage of the features of a given platform that allow it to stand out regardless of its other flaws or shortcomings.

      As far as maps, last year Google released an update that allows multiple maps (https://developers.google.com/maps/documentation/android/). Previously, it did take a lot of custom code or hacky solutions like splitting the app into multiple processes to handle multiple maps, but that’s no longer the case.

      • Josh says:

        I’d argue that UX is the most important feature of a smartphone – a device that is used on the go, with your fingers, for relatively short periods of time. If the OS isn’t intuitive and easy to use, all those great features go unused…

        I 100% agree with your main point, though – it’s absolutely a travesty when business owners and other stakeholders in charge of mobile development insist on making all versions of a mobile app look and behave the same. An iOS app should look like other iOS apps and take advantage of iOS capabilities. An Android app should not follow iOS conventions or have the same look and feel, but should take advantage of the cool things that are unique to Android.

        • Namarrgon says:

          UX is certainly vital, but the most important feature? Maybe if you only want entertainment, but “form over function” is not a popular sentiment with anyone who actually needs a useful tool.

          You can put up with a bad UX if you have no other choice, but the best UX in the world is still useless if it doesn’t have the functionality you need.

  9. Fede777 says:

    Hi, I really liked your article, I agree with some parts and I don’t with others, like I’d love to have a Weather/Clock widget in some page, and of course the settings toggles. These are just the basic ones, I’m sure I’d take advantage of others too.

    But I believe you forgot one important point to add, which is Default apps, I had a Nexus One, now I have an iPhone 4S and I really miss choosing my default apps, specially Gmail.

  10. sameer says:

    Your article make sense as i have gone through this phase, First customer want us to make iOS application then say make exact application for Android. If something can not be done in iPhone (because of it limitation), client surprisingly says us to remove that function from both application.
    Developing for iOS is like spoon feeding as you can only do what apple want you to do

  11. Steve Jobs died for his sins says:

    the title is misleading, and I suspect on purpose for click throughs on your blog. Based on what you have said, Android is doing it right while iOS is aging and still trying to catch up. How is that affecting Android? It’s not.

    • Nick Coad says:

      I thought he was pretty clear on that. He’s saying that the quality of apps made for Android is suffering because a lot of product managers are requesting that apps be made for iOS first and then Android as an afterthought. This means the developers are rarely able to take advantage of the neat features that Android has that iOS doesn’t (the sharing thing is a particularly cogent example).

  12. Unorthodox says:

    I agree with everything on this article. I especially can relate to the problem of unified look of the icons. With my limited vision I easily can and ofter do recognize apps in Android app launcher by the icon shape. If they are all fit into similarly looking squares (I installed a number of themes that utilize this approach), I have to take an extra amount of time, sometimes seconds to figure out what is in that square. No accessibility whatsoever!

  13. erik jensen says:

    Or maybe more understandable;

    Apple iOS is a modern train which take you from A to B. That`s it!

    How you come to A and from B to C, its not Apples problem, and if you want to stop and do something else on its way its just not possible!

    Android is a fast modern car that take you whenever you want, when you want it , and its yours choice how the car look like inside and outside!

    Therefore there are more cars then trains, and more Androids then…

  14. adrian says:

    life is too short to wait for that Android emulator to start. fix that and you’ll have more people developing for Android. I will

    • Adrian Stöckl says:

      Well, i agree that the android emulator is a pain to work with (even while it’s great, because you can setup almost every possible hardware), but i barely need it, because it’s much simpler to test apps on different handsets, just send the apk to your testers and you’re done.
      iOS on the other hand makes it painful to give the app to testers, yes you can provide it by adhoc install, but you still need to gather the udids, need to set up the provising profile (which needs a paid developer account),… , also keep in mind that xcode doesn’t provide a emulator, but a simulator, nice for common apps to test, but bad for opengl etc. (yes, i know it’s easier to get all possible devices at iOS than android).

    • byte_order says:

      Building and installing the apk on a set of actual devices is far more quicker (even better, automated thanks to adb push) and you’re on. With actual targets, not emulated ones.

      Thanksfully, the iOS simulator is fast to load, otherwise nobody will tolerate th adhoc install costs. But running your app in a simulator is not the same as on actual targets…

  15. srgtuszy says:


    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.

    I don’t know who told you that or where did you get information that iOS apps take more time load, but obviously, it’s plain wrong. Maybe some iOS apps are poorly optimised and take some time to load, but it all depends on the individual case.

    The only difference is the time limit, in iOS there is a hard limit of 24 seconds to launch the app, after that, the watchdog kills the app. In android, every action that blocks the main thread for more than 15 seconds will result in an ANR.

    • Dianne says:

      Actually Android’s ANR timeout is 5 seconds… and we consider 5 seconds an *eternity*, worthy of throwing up a big dialog to let the user kill the app. Our target app launch time is generally less than 1 second. For a simple app, you should be able to get going in about 200ms; for the most complicated app you should be able to get your UI up in less than a second and then can be doing whatever additional loading is needed in the background.

      • Exactly what Dianne said. The Android team did a phenomenal job making the apps load quickly and most apps can load and show full UI in a few hundred milliseconds. There are also tools like StrictMode to explicitly catch mistakes that developers make that would cause the UI thread to hang.

  16. a pretty goose for you says:

    so what you are saying is the IDE and UI controlls are different when comparing 2 DEs and UIs from different OEMs.

    pure genius!

  17. sumit kher says:

    This is very inspiring, as getting from the start & Having no real background in programming (aside from making some adventures on ZX-81 and MSX), I want to get started on developing something for my own Android based eBook reader and android app development training even this online course seems to be interesting http://www.wiziq.com/course/13599-professional-android-app-development-training-1-on-1-sessions. Has anyone tried any online courses so far. Please do provide a light on this also.

  18. Mark H says:

    What about android fragmentation. As an android developer that is my biggest obstacle.

  19. rainabba says:

    The “fragmentation” argument (I hate even giving it that much credit) is just another spin Apple came up with. Android is fragmented the way the human race is fragmented. Different physical devices were created to address the wants and needs of different people. If that weren’t the case, as an app developer, we’d just have fewer opportunities to sell (uhh, hello? iOS?).

    Android isn’t fragmented, it’s powerful and designed to allow for maximum consumption of hardware. You and I both KNOW that you can always built just one app and not have to worry about all that hardware diversity, you’ll just be limiting your app significantly (just like if you were designing for nearly any other mobile system).

    • byte_order says:

      or any app designed for one single platform, in fact.

      Fragmentation is another word to say uncontrolled evolution is bad.
      Uncontrolled evolution is not bad or good, it’s life’s way to adapt (in our context, bigger screen resolutions, new hardware capabilities, faster and wider connectivity, newer sharing services, whatever).
      Therefore, it’s unavoidable.

      Better prepare for it, and clearly not all mobile platforms are equals here…

  20. Pingback: Windows Phone Gains Ground In Some Markets | This Is Jah Smith DOT com

  21. Pingback: Windows Phone Gains Ground In Some Markets | Technology Blog

  22. Tim F. says:

    This comment belies the flaw in this argument. If Android is not fragmented, iOS cannot be holding Android back. It is not “powerful” to be able to write a highly niche app that the majority of Android devices cannot use. Maybe unprofitable, highly focused, less likely to be adopted, etc… are more apt but it’s not “powerful.” If the author’s thesis is correct and Android developers feel the need to copy Apple apps, they also feel the need to target a two and a half year old version of the Android and hardware that may have been state of the art two years ago. And exerting “power” as you describe it will put your app on a small island fragmented from use by the vast majority of potential users that you also likely want to claim as a reason for targeting the platform in the first place.

    Android is treated like a second class citizen because it is a second class citizen. More features is not more important than the right features.

    If iOS remains a more popular, more profitable, and larger (in terms of actual cohesive addressable market rather than splinters and shards of markets) and people on lesser platforms want apps like those on that platform, then that’s how it will be. More features, or even better, features are not the be all, end all of platform health. Cohesion, addressability, ease, market uptake, etc… are equally significant.

    It’s also humorous to me that Apple has, for a very long time, been a platform that seeks to maximize its own unique advantages and is generally strict about “encouraging” development to that uniqueness; whereas many other platforms try to add every feature that every other platform could imagine or to create UIs that “run anywhere” (often undesirably) despite the form factor, screen size, or usage scenarios, or want to promote tools to target other platforms, or to get their tools and feature sets working within other platforms, or promote the web as the universal development environment that will subsume all others. And, now that developers are enticed to follow Apple’s lead, Apple is keeping Android developers from making unique, special snowflakes.

    Also, the apps that I’ve seen developed specifically for Android are often complete and utter crap — all that UX stuff, that some dismiss as fluff that can’t compare with enumerating feature bullet-points, matters; iOS ports may be “limited” but are often of superior quality. I’d rather have the copycat apps than the crap that “freedom” and “power” afford.

    • >I’d rather have the copycat apps than the crap that “freedom” and “power” afford.

      You’re clearly an iOS user then and that’s fine, but the “fragmentation” argument is tiresome. You can still release an app that runs on a G1 to Google Play; you cannot release an app that runs on the original iPhone on the App Store (and soon you will have to target iOS 5 at a minimum, which will cut out the 3G), but perhaps that’s called “progress” on the Apple side. Fragmentation is defined in my book by explicitly having to change your app to support new hardware, which happens in the iOS world. The iPhone 5 came out and every single app had to be updated to work properly on it. If you don’t call that fragmentation, what do you call it?

      And iOS is not holding Android back do to fragmentation anyway (and I’d rather not derail this discussion with yet another fragmentation argument). The entire point of the article is that one platform should not be used as the UX or feature gatekeeper of another platform. If all iOS apps had been required to emulate GC lag back when Android 2.2 was the latest Android version because product managers didn’t want the iOS app to take advantage of iOS’s capabilities, I suspect your attitude would be quite different.

      • Tim F. says:

        >You’re clearly an iOS user then and that’s fine, but the “fragmentation” argument is tiresome.

        I use both about equally actually.

        >You can still release an app that runs on a G1 to Google Play; you cannot release an app that runs on the original iPhone on the App Store (and soon you will have to target iOS 5 at a minimum, which will cut out the 3G), but perhaps that’s called “progress” on the Apple side.

        Yes, it is. Certainly coding to 5 year old devices that progress significantly each year is not progress.

        >Fragmentation is defined in my book by explicitly having to change your app to support new hardware, which happens in the iOS world.

        That’s the stupidest definition I’ve ever heard. That’s the definition of a platform that is not progressing.

        >The iPhone 5 came out and every single app had to be updated to work properly on it. If you don’t call that fragmentation, what do you call it?

        I call that updating an app to support the latest technology.

        >And iOS is not holding Android back do to fragmentation anyway (and I’d rather not derail this discussion with yet another fragmentation argument).

        That was my point. Android is holding itself back, not iOS.

        >The entire point of the article is that one platform should not be used as the UX or feature gatekeeper of another platform.

        And my point is: this is unfortunately always true when one platform is more dominant than the other and it’s completely unrelated to number or quality of features. As someone who’s been involved in computer technology for 35 years, I’ve seen it 4 or 5 times, spanning several years to more than a decade. It’s called reality.

        >If all iOS apps had been required to emulate GC lag back when Android 2.2 was the latest Android version because product managers didn’t want the iOS app to take advantage of iOS’s capabilities, I suspect your attitude would be quite different.

        I wouldn’t moan that it’s Androids fault for being laggy I would complain to Apple for allowing iOS to slip into second place in terms of desirability as a primary format to developers.

        • Tim F. says:

          Also, here’s a real world example of a developer pulling developer practices from Android to iOS: Rovio games had unobtrusive UIs. When they expanded to multiplatform and couldn’t sell their apps on Android and other platforms — they introduced ads. They also began migrating from their pay model to a freemium model. With the change to the freemium model, they began cluttering their UIs with elements to access other purchases. Their apps now suck in comparison to other games specifically developed to be paid purchases on iOS.

          (It isn’t always, most often it’s not, some developers pet feature that really shapes or defines the attractiveness of a platform.)

          • They released Angry Birds as a paid app on iOS and a free-with-advertising app on Android. When they found Android was making a recurring monthly revenue of over a million dollars a month and the iOS new purchases were dropping off, they changed their business strategy. They now have an annual revenue of $200 million, so it seems to me like that was a business decision rather than an “Oh, that’s how it works at X, so lets do it the same way at Y.”

        • Tim F. says:

          Another real world example: When Adobe switched to Windows as it’s primary development format in the late 90s. It was irrelevant if Windows supported more or “better” features, the vast majority of Adobe’s own specific market of users hated it: the UI was inconsistent and worse. Features regressed. The Mac may not have been the “better” development platform, but Mac users still wanted Adobe products for Mac to be targeted to it. They complained to Adobe and Apple. They did not complain to Microsoft.

        • byte_order says:

          There is two way to handle a platform evolution :
          - supporting evolution either by hand or using built-in features of the platform frameworks that have some future-proof support
          - supporting evolution by killing platform older iterations, enforcing newer ones.

          The first one is called fragmentation, the second is called planned obsolescence.

          The first one cost far more to developers, that’s the cost of supporting diversity.
          The second one cost far more to customers, that’s the cost of *not* supporting diversity.

        • > I use both about equally actually.

          That seems surprising to me given the innumerable excellent apps developed for Android only and this statement that you made: “the apps that I’ve seen developed specifically for Android are often complete and utter crap.” I’m guessing we have very different expectations from an app. Perhaps you’re the type who likes Clear on iOS whereas I like Tasks on Android? Or maybe you have an iOS device as your primary device and lug around an Android device for work and consider that equal.

          > That’s the stupidest definition I’ve ever heard. That’s the definition of a platform that is not progressing.

          Actually, it’s a concept called backward compatibility. If a platform has to fundamentally break apps to make iterative progress, it is poorly designed.

          > Android is holding itself back, not iOS.

          My argument is that people are holding Android back based on the feature set and expectations of iOS. I’m not sure how you can construe that as Android holding itself back.

          > And my point is: this is unfortunately always true when one platform is more dominant than the other and it’s completely unrelated to number or quality of features. As someone who’s been involved in computer technology for 35 years, I’ve seen it 4 or 5 times, spanning several years to more than a decade. It’s called reality.

          So your suggestion is to not identify it, not do anything about it, and just call it reality? That sounds like the opposite of progress.

          > I wouldn’t moan that it’s Androids fault for being laggy I would complain to Apple for allowing iOS to slip into second place in terms of desirability as a primary format to developers.

          You would complain to Apple for the choices that third-parties make?

          • Tim F. says:

            >Perhaps you’re the type who likes Clear on iOS whereas I like Tasks on Android?

            No.

            >Or maybe you have an iOS device as your primary device and lug around an Android device for work and consider that equal.

            No.

            Maybe you should stop making presumptions.

            >Actually, it’s a concept called backward compatibility.

            Sure. And it is most assuredly not the definition of fragmentation.

            >My argument is that people are holding Android back based on the feature set and expectations of iOS. I’m not sure how you can construe that as Android holding itself back.

            I disagree with your argument and your support of the argument, was that not clear?

            I’m not incorrectly construing anything — I’m telling you that you are wrong.

            >So your suggestion is to not identify it, not do anything about it, and just call it reality? That sounds like the opposite of progress.

            No. My suggestion is you don’t blame a competing platform for the lack of uptake of features on a different platform. I suggest you make a better case beyond saying, “X has more and/or better features.” I suggest you ask yourself the question, “If I think Y is inferior and has fewer features, why is Y still more attractive as a primary developer platform and/or to model your cross-platform apps against?” I would ask yourself: “Even if a platform is successful, why is it that some programmatic features get used and others do not?” I would ask yourself: “Are there other things that may be more important than enumerating a bunch of features that I think are cool but the average consumer may not care about?” Etc.

            In other words, I am all for developers taking advantages of unique features. I am against blaming Apple for Android’s deficiencies and whinging about it. I am against slagging a company as lacking features or having worse features and then talk about how horrible it is that everyone is copying that.

          • >Maybe you should stop making presumptions.

            I apologize that you took my questions as presumptions. I was trying to dig out what values you consider when you declare that most Android apps are crap (“the apps that I’ve seen developed specifically for Android are often complete and utter crap” and “I’d rather have the copycat apps than the crap that ‘freedom’ and ‘power’ afford.”), but clearly you’re very defensive of your position and don’t want to explain it.

            >Sure. And it is most assuredly not the definition of fragmentation.

            We’ll have to agree to disagree here. I think that if every new piece of hardware or new OS caused every existing app to be broken then that is fragmentation. You don’t.

            > I’m not incorrectly construing anything — I’m telling you that you are wrong.

            If you’re not misconstruing anything, then I don’t know how you took this article as an attack on Apple. I explicitly mentioned product managers multiple times and the only time I even mentioned Apple in the entire article was to say that they pushed widgets on desktop but not mobile.

          • Tim F. says:

            ” I think that if every new piece of hardware or new OS caused every existing app to be broken then that is fragmentation. ”

            And that’s just completely made-up nonsense.

  23. Tim F. says:

    P.S. Your comment system is broken on Safari (even with third party cookies not blocked). Maybe you should not focus so much on Google products.

    • Care to elaborate so that I can fix it being broken? I obviously don’t post as an anonymous user and I don’t use Safari, so I haven’t seen whatever issue you’re referring to and no one else has ever mentioned it.

      • Tim F. says:

        What does being “anonymous” (you have my email address) have to do with it? Form submission does not work on Safari. You get an error message.

        • I meant anonymous as in you don’t log in to the site but I do. Sure, you have to put in an email address, but it doesn’t even have to be your real address. I’ll give it a try on Safari though, thanks. I’m surprised that it has issues, since I’ve done little to change it from the stock WordPress experience and it works fine with Chrome, which is also backed by WebKit.

  24. ulybu says:

    Thanks for writing down my frustrations!
    Hardware additional comment:
    Can’t stop thinking about the delay nfc-related technologies development suffers due to its non-presence in the iPhone 5..

  25. Pingback: El impacto negativo que iOS ejerce sobre Android [ENG]

  26. Max Winde says:

    For me, as an iOS developer it’s often exactly the other way around: We end up not implementing features because they are not possible, to hard or would take to much time “on the other side”. Examples would be: use mp3 instead of m4a, because many Android devices don’t bring an mp4 audio codec. Don’t show the cover image of the currently playing song on the devices lock screen because Android can’t do this. Don’t add Twitter and Facebook Sharing, because Android can’t do this easily. Map integration? Can’t do on Android. The list goes on and on.

    It gets worse when we come to Interface design. On Android there is no single interface language: Android 2.x looks like this, Android 4.x looks completely and every OEM smashes it’s own interface on his devices. So it’s completely normal for the designer to just design interfaces and not to care about user interface rules for any platform. When we, as the iOS developers bring this up often we get an “why do you bring this up? The Android team did not complain! Just do it like them!” Also designers often don’t think about transitions. On Android this is easy, because it’s completely normal just not to use transitions from one state to another. If you do something like this the app ends up looking like a complete alien on iOS.

    It’s often hard work to convince the customer that it’s better for them to have an app that makes the most out of every platform. For you it just seems to be the case of iOS == bad; Android == good. You don’t even seem to see that other OSes have advantages too.

    • Alex P says:

      Don’t show the cover image of the currently playing song on the devices lock screen because Android can’t do this.

      Oh yes it can. RemoteControlClient API is avaialble on 46% of Android devices, that includes the ability to show a cover image and control playback from lockscreen.

      Don’t add Twitter and Facebook Sharing, because Android can’t do this easily.

      Easily? The total amount of code required to do a Share button to Facebook, Twitter or any other service installed is 5 lines. I kid you not – 5 lines. No need to integrate with LinkedIn, Facebook, Twitter, Bluetooth, email or any other service that accepts whatever you’re sharing. Just 5 lines.

      Map integration? Can’t do on Android.

      Really? Not only can you integrate maps in your application, you can also integrate with alternative service on Android.

      In short, before you start showing how little you know about Android make sure you at least read up on the basics.

      • Adrian Stöckl says:

        Small addition about interfaces if i’m allowed to, yes, it changed within the years and versions, but with 4.0 (or better said already with 3.0, but because it’s tablet only, i go for 4.0) they found their style and set up guidelines, which will possibly change as well in the future, but that’s called progression and doesn’t only happen at android, but almost everywhere (Webpages, desktop GUIs,…) and yes, the different vendors do build their own skins (unfortunately), but this doesn’t mean that it isn’t still the best practice to use the given guidelines google provides.

        • Max Winde says:

          It might be a good idea to use googles guidelines, but in practice I have only very seldom seen an android developer who actually does care. And I can’t blame them, because Google does not seem to care either: most google apps behave completely different when doing the same thing like when you press the phones back button.

          • Adrian Stöckl says:

            They are used more and more, what’s app, titanium, Tapatalk,… there are still many not using it yet, but the trend definitely points into that direction, think about that many apps available are build by small teams (or even one man shows), it takes time and resources to catch up, let them take it.

            Interesting, at all apps I use (not only Google apps), except they where poor build (or poor copies of iOS pendants), hitting the back sends me to the previous screen /context /activity.

      • Max Winde says:

        Okay, so showing cover images is now available on nearly half of all devices.

        Facebook and Twitter Sharing: I have a Nexus 7, I’ve never seen an App with System Facebook or Twitter Sharing nor have I seen a way to login in the system prefs. I now that there is an URL sharing panel, but that’s not what I meant: you have to leave the app to use it, so it’s not the same.

        Map integration: there is a way to open Third Party Apps in Android from the Google Maps App? Can you tell me any app that actually uses this?

        • > Examples would be: use mp3 instead of m4a, because many Android devices don’t bring an mp4 audio codec

          That’s because Apple (sometimes) uses their own audio codec (ALAC) instead of the more typical AAC codec. Until late 2011, ALAC was proprietary, so Android devices could not handle the files because Apple explicitly disallowed it. The “enhanced” podcasts were an extension to the format that Apple also made; a developer I worked with previously wrote code for an Android app to pull those out and display them and it worked fine on all versions of Android.

          > It gets worse when we come to Interface design.

          Android apps should all follow the design guidelines regardless of version. They are based on user experience expectations and are backward compatible (e.g., the long-removed menu button doesn’t break). The guidelines should be deviated from only if it truly makes sense.

          >When we, as the iOS developers bring this up often we get an “why do you bring this up? The Android team did not complain! Just do it like them!”

          The Android side gets that sort of problem as well, but it’s usually around resources. “Why doesn’t this asset that’s perfectly sized for an iOS screen work for you?”

          > Also designers often don’t think about transitions. On Android this is easy, because it’s completely normal just not to use transitions from one state to another.

          Graphic designers rarely do but interactive designers usually do. However, many mobile designers come from backgrounds such as print or logo design, so they’re not as familiar with interaction models and animations. Android has very explicit reasons for using animations. Specific animations are used to indicate that you have switched apps to fulfill an Intent or you have just added something to the back stack. There are also default animations for layout changes that can be enabled with a simple boolean for 3.x and above (with no harm to previous versions).

          > For you it just seems to be the case of iOS == bad; Android == good. You don’t even seem to see that other OSes have advantages too.

          Perhaps I misrepresented my position then. My point is that the limitations of one platform should not harm another. I thought this line was clear “If iOS has a better WebView, use it,” but maybe it wasn’t.

          • Tim F. says:

            “Perhaps I misrepresented my position then. My point is that the limitations of one platform should not harm another. I thought this line was clear “If iOS has a better WebView, use it,” but maybe it wasn’t.”

            If your point is a generic one: cross-platform development should never be towards the least common denominator, it should always exploit the unique advantages of each platform you develop for…

            If such was the case…

            1. Your examples are awfully one-sided.
            2. You say Android 1.0 has better and more features (highly suspect) an awful lot.
            3. You are still completely avoiding the non-technical pros and cons for programming to the Lowest Common Denominator (and/or at least some compromise).
            4. Your point has been made a million times before and has always lost to practical/business considerations.

          • > 1. Your examples are awfully one-sided.

            Quite simply, I haven’t seen many cases in which Android considerations limited an iOS app. I work with plenty of iOS developers, but I don’t do iOS development myself, so I’m probably not the best person for coming up with examples of that. Of course, if someone with that knowledge wrote a blog post, I would love to read it. The more everyone knows about the advantages of each platform and the detriment of ignoring the unique requirements of a platform, the better.

            > 2. You say Android 1.0 has better and more features (highly suspect) an awful lot.

            Can you please point out where I said that Android has better features or even more features? I must be missing something because these are the parts I see on this page where I mention Android 1.0:

            “Android 1.0 had a lot of features that iOS didn’t (and some it still doesn’t), but the usability was significantly worse.”
            “Most of this blog post covers Android 1.0 features. However, I would say that the UX of Android didn’t take a leap forward until 4.0.”

            > 3. You are still completely avoiding the non-technical pros and cons for programming to the Lowest Common Denominator (and/or at least some compromise).

            Care to enlighten me then as to why a product manager would have an Android developer spend weeks on custom sharing features built into the app to mimic an iOS app and share to a small set of third party services instead of spend minutes to utilize native sharing and focus on improving the UX of the rest of the app?

            Care to explain why a product manager would not even consider whether an Android widget would be worthwhile for an app?

            Care to explain why a product manager would have an Android developer spend a week developing a custom splash screen that can handle all the special cases and artificially delay the user experience instead of focusing on product value?

            > 4. Your point has been made a million times before and has always lost to practical/business considerations.

            As I’ve pointed out, there are apps that do take advantage of features unique to a platform and those apps are quite frequently ones that do extremely well. So, ‘always’ is rather hyperbolic.

        • NullCorpus says:

          Ian is absolutely right about the sharing aspect of Android.. “Intents” have been baked into Android from <1.0 and they can be passed back-and-forth amongst any set of apps registered to handle them.

          Sharing content through any app capable of dealing with shareable content is really just a small handful of lines (you don't even have to know what Apps are on the device)

    • byte_order says:

      “For me, as an iOS developer it’s often exactly the other way around: We end up not implementing features because they are not possible, to hard or would take to much time “on the other side”.”

      Sounds more because you don’t fact-check what you think you know “on the other side” than what is actually impossible…

  27. I’m the author of Unshorten, thanks for the referral Ian! I noticed a decent uptick in downloads the past few days and did some searching and found your blog.

    The intent/sharing system of Android is one of the best features of the OS as far as I’m concerned. Apple would be wise to suck it up and implement something similar.

    As for the overall thesis of this article, I agree: there are definitely some things that get brought over to Android apps from their iOS counterpart that just don’t fit in with the OS or could be done better. However, I think that with such a strong community developing behind the android design guidelines and UI/UX principles (including the Holo theme, action bar usage, etc.), some of this has changed dramatically. The Pure Android page is a nice list of things NOT to do in an Android app.

    Check out the work some of the Android developer advocates are doing. Android Design in Action is a great video series that shows examples of “the right way”. The Pure Android Collection is a set of hand-picked apps that should be considered cream of the crop. There are many more great resources as well.

    With something for developers and users to point to and say “this is how it should be done”, I think the app scene is changing and we’ll see less and less iOS-ness on the platform.

    • Hi Alan, thanks for stopping by. I love Unshorten and think it serves as an excellent example of an app that people don’t know they need until they have it. It’s also a great example of how to make the Android Intent system work. Apple would definitely be wise to start implementing something similar to Android’s Intents, though I wonder if they are concerned with losing the default app status for apps where some users find a third-party app is better. Competing on an even playing field would be a very different experience for them.

      The whole Android design website is awesome and a great resource. I’ve used it as part of an arsenal in fighting bad decisions, such as using chevrons everywhere in an Android app to indicate something can be touched (just the thought makes me cringe). We are seeing a shift in focus on making Android apps better (both visually and UX-wise), which is very pleasing, but I wish we could hurry it along, haha. Any time I see an iOS port come out on Android where they literally took the app exactly as it was on iOS and tried to duplicate it on Android, a little part of me dies inside. The user experience is different on each platform and mixing them for the sake of consistency across platforms instead of consistency within a platform is terrible.

  28. Mike M says:

    I’ve heard many excuses from both developers and android supporters but it would be interesting to hear your opinion on why Android has fallen behind iOS when it comes to music creation application.

    With iOS the number of music apps- whether it’s from an individual with an ingenious idea for a touchscreen music/sound app (see Gestrument or Bjork’s Biophilia) or large developers like Steinberg (Cubase), Propellerheads (Reason) or Korg (Polysix, KAOSS)- are plenty and wide ranging (see Audiobus or JACK which allows interapp operability in iOS devices). But so far none are willing to touch Android.

    Why is it? Fragmentation is one of the many excuses I often hear. The different screen sizes, the lack of Core Audio like API on Android which brings me to the next point.

    The fact that Android devices can’t do low latency audio (the touch to sound response is lacking compared to even older iOS devices). This is one thing Google has promised since 2008- to bring low latency audio to android but so far with inconsistent result.

    And finally lack of interests from users. Most of these apps aren’t free and Steinberg, for example, sells a version of their Cubase for the iPad called Cubasis for $50 (a steal when the OS X version albeit with more features go fof $700). The larger portion of music apps on both the iPhone and the iPad sell in the $3-$20 range. Of course, the whole quandary of chicken or eggs applies here since the choice for Android user is rather abysmal.

    Some might argue it’s a niche market but if you look through the App Store offerings, you might see otherwise. The tablet especially is the perfect hardware for music- you can’t get any more intuitive than a touch enabled music device.

    • To be honest, I’m not extremely knowledgeable of the music creation side of things. My understanding is that Android has fairly high audio latency (>100ms) as you said, which is probably the primary reason we haven’t seen much in this area for Android. Supporting multiple screen sizes is easy, so that’s not the issue. I don’t know what all Core Audio provides, but Android added support for OpenSL ES in 2.3. It may be that that isn’t enough.

      Even if Android has exactly the right APIs, there could also be the perceived risk. Looking at iTunes, Cubasis has only 63 ratings; I’m not sure what the bought-to-rated ratio is, but at say 20:1, you’re looking at just under 1300 purchases. If that’s remotely accurate and that’s on the platform they expected to most succeed, there doesn’t seem to be much of a business case for supporting a platform that they think would likely see fewer downloads. Developing that type of software is much more expensive than developing a newsreader or similar, so I wouldn’t be surprised if they haven’t yet recovered their investment (of course, I am just totally throwing out a ratio there, so if it’s 500:1, they’ve certainly made their money back).

      Looking at JACK, the app appears to be extremely recent? There are just 14 ratings (since it’s free, I assume that means it was recently released rather than just not being popular). Audiobus looks like it has seen significantly more downloads, so there’s definitely a market out there, and I’m glad to see iOS covering it. Hopefully someone will step up on the Android side and make it happen, but I’m afraid I can’t be particularly helpful in definitively saying why that hasn’t happened yet.

  29. Jon-Cameron says:

    Not only a very interesting and informative article Ian, your answers to the critics are precise and professional too. Well done.

  30. AlikMalix says:

    Hey guys, you have no idea how much I appreciate your professionalism (from Ian, Tim F, Max, and others). I’m not a developer by any means, I came accross this thred because I have a few ideas for the app, and wanted to know where these ideas stand. Funny thing is, your replies to each other (regardless of differences) are dignified, backed up by reason or fact, and most importantly perfectly understood by a non developer end user like me.

    I will be checking in from now on. I am biased toward apple when it comes to app availability. There are many times when it just gets frustrating not being able to find not one, but quite a few games for example on my friends android app stores, so that we can compete. We currently have one modern game Real Racing 3 that my android friends can join in, otherwise they’re left to their own devices. Z2 has great titles, but they don’t developed for android, quite a shame actually.

    My research allowed me to understand that one of the two major factors that contribute to android’s lack of certain apps/games is intact the “overhyped” fragmentation argument, and the other is profit return. (Point making – I wouldn’t write off “fragmentation” as just apples spin on android).

    I think google should start regulating how android is being used/modified, and maybe set some standards or guidelines for hardware to catch up with developers love affair with iOS. But then there’s always the dark cloud on the horizon (for developers) called Tizen, with a chance of Firefox, and Amazon winds.

    Now speaking of ideas. I’m a contractor – I buy a lot of material, and I buy it often. I need a calculator that I can input many times such as lumber cost, Sheetrock, wire, etc, also current sales tax rate, markups, and other values and have them accessable to add or multiply by at a touch of a button. Like custom set values added as a button. It would be great if I can change/update those values with ease. And please don’t forget the the print tape (kind of like iCalc in the App Store). Le time know if that’s possible, and if you guys think you can profit from this thing feel free to run with it, email me if u do though: alikmalix@me.com

    Once again, I enjoyed your arguments.

Comments are closed.