Why do native mobile apps seem to win all the time?

Twitter is often a place of small, but thought-provoking bits of information or personal impression. Just today, Mick Curran, one of the NVDA core developers, tweeted this:

and followed it up with this:

Jamie Teh, the other NVDA core developer, replied to this and said:

And this question touches part of the problem, but not the whole. The questions can be continued:

  • Why are there native iOS and Android apps for so many offerings that originate on the web?
  • Why is it that even Google, a company with a clear web focus, creates native Android apps for its services like GMail or Google Plus?

I believe there are several parts to a possible answer:

Developing for mobile browsers is damn hard

Every web developer who has developed mobile sites or web applications ever, and tried to make the site work on as many devices and browsers as possible, knows what hard work this is. On Android alone, the native browser behaves differently in each major version. 2.2 and 2.3 support different stuff than 3.x (the tablet-only version) and 4.0 did. And then there’s Chrome and Firefox, which also run on each of these versions, but which have to be installed separately. Then there’s Android 4.1+ with Chrome preinstalled at least on the NEXUS 7 tablet, but possibly others. iOS, which has a high rate of current version usage, supports other things than Microsoft’s mobile version of IE which runs on Windows Phone. Animations in one browser run once while in another runs forward and backward the same amount, or in a third browser, doesn’t stop animating at all… You get the picture!

The result is that many mobile sites, to support the widest possible range, are cut down to a bare minimum. Many web devs are even afraid to use anything but basic JavaScript and CSS properties because the three year old version of Webkit that runs on a Gingerbread Android browser doesn’t know about these things.

So, for many companies, it is economically saner to produce one native app per platform instead that just talks to their backend on the web, but gives users a consistent user interface to deal with even if they upgrade to a newer device along the way.

Others, like Facebook, decide to cut down their hybrid web content strategy in favor of a more native app to improve the user experience that way, because they feel that they would otherwise get nowhere with what they had. On both iOS and Android, access to device features is easier than from the browser, or it is not possible to use many features from the browser at all.

Other factors also come into play, like how to manage multiple accounts from the same service, e. g., Twitter, through conventional web means like cookies. While the native apps for Android and iOS support multiple accounts, the web app does not, it instead requires one to sign out and in with a different user name and password manually.

Too much clutter

Let’s face it, there are hardly any mobile apps that aren’t either cut down to a point of excruciating pain, or overloaded with too much clutter like a whole bunch of navigation links that take away valuable space especially on small hand-held devices such as iPhones or other smartphones. Native apps do a much better job at providing a single point of focus for the user. Users either want to view a list of articles, do a search, browse categories, but not all at the same time on a 4 inch screen! Or in the case of social media, they want to view a list of posts, or they want to compose one. Trying to squeeze both into a single web page on a small screen is undoubtedly going to create a less than pleasant user experience. In a native app, a tabbed interface allows the majority of the screen estate to be used for a single purpose, a single task, a single point of focus. Links to a web site is only presented in the About section, where it belongs, along with a copyright notice etc. In almost all web presences for mobile and desktop browsers I know, a lot of cruft is being taken along onto every sub page one visits. A huge navigation side bar, a top bar, a search, a footer with a lot of meta data….While this is still relatively OK on desktop computers, mobile devices have much less space, or much more need to scroll and become inefficient if too much stuff is presented at once.

Efficiency is maybe the greatest factor of all. If I want to order a pizza, or shop on Amazon, I want to stay focused and not be distracted by ads, too many offerings, bells and whistles, etc. I want to get the job done. I, myself, even though I work for a company that puts the web in front of all other stuff, find that I haven’t done shopping through the Amazon website in over a year because the native iOS app lets me do it so much faster. What I can shop for in the Amazon app within a minute, usually takes me at least(!) twice as long in any browser/screen reader combo. In other cases, like the one Mick describes in his tweets quoted earlier, the web site is marked up so badly that it is nearly impossible to place an order, whereas the native app makes it very easy to do.

And then there’s the browser UI itself. It takes up some valuable portion of the screen and is a constant reminder that one is not inside a mobile app but rather a web page. In a native app, this aspect becomes completely transparent. The user does not need to care what’s working behind the scenes. They get their job done, they simply launch the app, they simply interact with what they want to accomplish.

The Mozilla market place goes a long way to alleviate this last aspect, by launching the installed web app in a Firefox runtime on one’s Android device that leaves out all the typical browser UI pieces, and gibes a full screen view of the web app.

But all the web apps I’ve tried still remind me that it’s web pages I’m dealing with. They have links they carry onto every sub page I move to while working the app, and they always clutter up parts of my valuable screen estate. And yes, they get in the way! They either require me to explore past them, remember that they’re there and that I should start exploring somewhere one third down from the top, or not move too far to the left to not encounter them, etc.

And interaction models often require new pages to load. Loading pages is a very webby thing that can take quite some seconds before the app becomes useable again. A lot could be accomplished by putting everything in one bigger HTML file plus CSS and JS, and show and hide the currently not focused areas dynamically. Compiled JS is fast enough even on mobile devices that the delays are much much less than actual page loads.

There’s only one mobile web app that I know of that mimics the look and feel of its native Android counterpart, and that’s Mobile Twitter. Unfortunately, its markup is rather wild, so it is barely accessible. I have no access to the Compose button in Firefox for Android, for example. But in principle, that’s what a mobile app should be. it removes all the clutter of a typical web page, gives a tabbed interface and doesn’t bother the user with a composition form that would take up valuable space that can now be used for more relevant content.

Accessibility

Yes, this is often a deciding factor, too, whether I, or other blind users, choose to use a native app rather than the web site or mobile offering. And as the above mentioned Facebook example shows, their switch to a native app allowed them to provide a much better accessibility experience for visually impaired users on iOS.

The reason in many cases is that both iOS and Android have UI components that give a lot of accessibility for free just by using them. iOS and Android app developers only need to do comparably few things to make their even a little more than simple UIs accessible to the assistive technologies preinstalled on those operating systems.

Like with many things on the web, implementing accessibility is not an easy task especially for more complex compound widgets. Fortunately many UI libraries now offer accessibility for free, but how many of them can actually be used efficiently on mobile devices nowadays? In short, the danger — and yes, I use this word consciously — of encountering wild-west web coding in accessibility terms is quite high. This becomes an important factor for Mozilla as we venture into the mobile app space more and more with our own Firefox OS offering. I’m seeing a lot of evangelism work ahead actually, starting with our own implemented apps and expanding that to the author base on the Market Place.

In summary

The theme of too much clutter impacts a big range of people, not only visually impaired ones. People with cognitive disabilities, for example, are also often frustrated and confused by too much navigation or other “webby” stuff on small mobile screens. “Regular” sighted people I talked to prefer native apps for the same reason.

Many web app developers need to become much more conscious of what the actual focus point for their end users is at any given point in their application, and center the whole interaction of a single screen around that. The relevant content must always come first, and things that we used to take for granted like navigation bars etc. need to recede into the background or get their own special corner inside the app to not take up valuable screen estate and constantly get in the way of the user.

If some of these paradigms settle into the minds of a majority of mobile web app developers, the debate of whether the web is the better platform or not may take a more positive turn for the web from the user’s point of view.

6 comments:

  1. Quote: “In other cases, like the one Mick describes in his tweets quoted earlier, the web site is marked up so badly that it is nearly impossible to place an order, whereas the native app makes it very easy to do.”

    In other words, either they are wildly incompetent when building websites but manage to hire people who actually know what they’re doing to build the apps, *OR* the apps manage to prevent garbage markup from breaking the app (if so, can browsers learn from this?). Honestly I’m trying to find some excuse (on the part of the likes of Amazon) that *isn’t* a flying monkey’s butt, but I really can’t.

    There is no good excuse for a simple pizza-ordering site to suck on mobile (well, there’s one: the original pizza site could be 12 years old, written in FrontPage 6 and will take an arm, a leg and someone’s firstborn and about 3 years to rewrite so it’s not using font and center tags anymore, let alone mobile-first-responsive-blah-blah). It honestly doesn’t need 500 fancy ajaxians a-dancing or 400 tabs a-singing or take 12 days of Christmas to let you… order a pizza (you know the joke? With the new app, you can now order a Domino’s Pizza with your iPhone!) If the app is free to users then I really can’t figure out what’s going on. If it costs 99 cents or something, then I guess that answers the question of why simple websites suck while the apps work wonderfully.

    Again, I’m not comparing an order-a-pizza “app” to something complex like Twitter. I can see some complex social something-something working better on an app, for all the other reasons you mention. But app-craze doesn’t seem limited to them.

    All those Blackberry and Palm and Nokia users! Who will make apps for them?? Why, nobody, especially when many web developers (or at least their bosses) even believe everyone actually does have only either an iSomething or an Android something. This app craze may be pushing consumers towards a mono- (or duo-)culture.

  2. I don’t believe your reasons explain the problem with web apps:

    - Cross-browser compatibility: Native apps also have their compatibility challenges. Obviously a IOS app wont run on Android, but on every platform newer versions have features older doesn’t. Sharing common code between multiple versions of an app will probably be easier on the web.

    - Access to device features: This is probably a deal-breaker for the web app, but do the common apps use the device features?

    - Multiple accounts: There is nothing stopping you from handling multiple accounts in a web app.

    - Clutter (e.g. ads, navigation and links repeated on every page): Your main argument seems to be that web apps are designed like web sites. But I don’t believe anything prevent you from creating an uncluttered web app.

    - Browser UI: There seems to be some methods out there for hiding the browser chrome, especially after the user have added the app to the home screen (which is a prerequisite for a native app).

    - Delay when loading new pages: As you point out, this can be worked around.

    - Bad accessibility markup in web app / Accessibility for free in native: This is probably only a problem for a minority of users (so I don’t think it is why developers choose to make native apps) and probably a even minor minority of developers (which, I think, explains why it isn’t being fixed). But you are probably right that native frameworks have a lot of accessibility build in. I don’t know, since I don’t know what accessibility looks/feels like. I think, it would be interesting to have e.g. a series of small “accessibility dos and don’ts” videos that show common problems (both what they look like to the disabled and in code) and how to fix them.

    To evangelize web apps perhaps one should create reimplementations of some of the most popular apps.

  3. Hm, I’ve started reading a Jakob Nielsen report on Mobile Usability. He lists many reasons why apps are more attractive to developers than mobile-ready web pages, but empirically his testing showed that there was a much higher task-success rate on apps (74%) than made-for-mobile sites (64%), both of which were much higher than non-mobile-optimised sites (53% I think, would have to re-look that one up).

    It may be that many developers are aware of easier use from a dedicated native or hybrid app rather than a plain (or maybe responsive) web site.

What are your thoughts?