

Why native apps are here to stay - DeusExMachina
http://www.mentalfaculty.com/mentalfaculty/Blog/Entries/2011/9/8_WHY_NATIVE_APPS_ARE_HERE_TO_STAY.html

======
beaumartinez
If Apple doesn't want your app published, good luck providing that "better
experience".

The smart money is in making a web app for everyone first, perhaps not with
_all_ the bells and whistles, but sufficiently functional, and _then_ making
platform-specific apps.

Regarding "offering the same lowest common-denominator user experience on all
devices"—know your audience. You don't have to make your app pixel-perfect for
IE 6 if iOS users are all you're targetting. Web browsers "degrade"
gracefully.

One of _the_ features of web apps is that they can be _anything_ —"the web is
open". Mobile native apps are (often solely) available through app stores
which are dictatorships, controlling when—and if—your app and its updates are
released.

~~~
mechanical_fish
_app stores which are dictatorships_

The 1990s called. They want their metaphor back.

Let's face it: The "dictatorship" metaphor was fun (Remember the cartoons with
the X-wing fighter torpedoing the AT&T Death Star logo? Good times.) but it
was probably overwrought even back in the old days when DOS software and Mac
software and each of the 23 different Unices were binary incompatible and
emulation was dog slow and virtualization was like science fiction and
choosing a platform felt like proposing marriage. But now? It might even be a
_dangerous_ line of thinking. You need to learn to think like your customer,
and _they_ don't see this oh-so-crucial distinction between "native apps" and
"web apps". Except to the extent that web apps are a trifle more difficult to
find: Instead of finding the pretty icon and touching it, you have to touch
Safari and then type the name of your desired app into the Googles.

(No, of course the average customer doesn't know how to bookmark a URL. They
don't know what a URL _is_.)

A defining characteristic of the metaphorical "dictatorship" is that people
can't vote. In particular: They can't vote with their feet, because the wall
is too high or the ocean too wide or the border guards (on whichever side of
the border) are too expensive to bribe. But there are only two kinds of
native-app platforms today:

A) The platforms in which a full-featured HTML5-compliant browser is at most
two clicks away at any time;

B) The platforms that are being crushed to death by iOS, Android, and the
other platforms in Category A.

Where's the big barrier here? Half of my native apps _embed_ entire HTML5 web
pages. Or they link out to HTML5 web pages. Meanwhile, an increasing quantity
of web pages prompt me to install native apps. The answer to "web apps or
native apps" is "both", to the degree that they _interpenetrate and are
inseparable_ , and what reason is there to believe that this won't continue?

Developers obviously care about their release schedules and their profit share
and the backend technology underlying each and every screen on the phone, but
customers don't know and they don't much care.

~~~
beaumartinez
More than anything I meant the allusion to a dictatorship as to the fact that
Apple can decide whether they want your app or not, and can decline it for any
reason. (And I agee, it's a worn metaphor but I couldn't come up with a more
succinct description.)

> _Web apps are a trifle more difficult to find_

That's pretty much my point—Apple want to control what you put on their
devices. Remember when they were touting web apps[1]? Look at the page now.
_Most recent: 12/03/2010._ iPhone 3Gs. They dropped that as soon as they
realised they were _harming_ their profits with the App Store.

[1] <http://apple.com/webapps>

~~~
semanticist
Does Apple make money from the App Store? Last I heard it covered its costs
and Apple made from from selling extremely high margin devices.

Also, how do you reconcile the idea of an Apple who wants to maximise profits
from the App Store with an Apple who limits what apps can be sold through that
store? They're literally turning down paying customers in the App Store
because they think it'll hurt their real business, selling devices.

------
pkaler
Native Apps are here to stay because it is impossible to build a certain class
of Apps in the web browser.

There is no way to upload files on Mobile Safari. I'm told this has finally
been implemented in Android 2.2. It's 20-frackin-11 and an App like Instagram
is not even possible as a Web App.

App developers use Push Notifications to increase engagement with their App
and notify users when something interesting happens. Ditto, for Local
Notifications and Background Location. That's not even possible with Web Apps.

The new hotness in 2012 will probably be NFC. Web Apps probably won't have
access to hardware data exchange for years.

And the list will keep going on. There will be new functionality in mobile
phones released each year. Native Apps will get access to this functionality
right away. Web Apps will have to wait for years to get access to this
functionality.

~~~
rjd
> Native Apps are here to stay because it is impossible to build a certain
> class of Apps in the web browser.

Even current usages have issues. A few hours ago I decided I wanted to move a
bunch of RSS feeds into Google Reader so I could prototype a new tool I'm
working on.

So easy enough, create new Google Apps account, populate RSS feeds.

I'm not sure what was going on but my Google Apps admin console kept timing
out. No idea what the problem was, my wifi, my ISP, international cable, some
erroneous proxy, Google apps itself I dunno... maybe the bad/stormy weather
outside... But it took me over 5 minutes to create a new user account.

Everything else seemed to be running fine so I thought it would correct
itself. However after about 10-15 minutes of no improvement and very slow
progress. I gave up trying to add RSS feeds (and put them into folders) via
the web.

Annoyed at this point I downloaded an RSS client, added all the feeds I
wanted, exported the OPML and uploaded it to google in around 10 minutes.

To do a simple chore I had to revert to a native client, and that is the
reason why native apps are here to stay for me.

They are reliable and fast, ignoring other benefits. Web apps in a lot of use
cases just aren't upto task.

------
mmcdan
The biggest draw for me with native apps is the revenue model. Most users are
conditioned to think if it opens in a browser, then it should be free. It
really doesn't matter to me if i'm programming in Java, Objective C, or some
HTML/Javascript framework... but can I justify spending time without a simple
way to charge for my product?

Solve the monetization problem and I guarantee developers will look at web
apps more seriously.

~~~
toddmorey
This is a really good point and often overlooked. A native app gives you a
sense of ownership--a subtle yet powerful concept that attaches value to the
application. I'd like to think I'm above such psychological games, but I know
I've paid real money for apps that I wouldn't have paid for things delivered
through a URL. Also, the common way to bill for a webapp is with recurring
fees. But not everything fits that mental model of a monthly service very
well. For example, it feels better to me to pay a one-time fee for a todo list
app than to pay $5/mo--even if it worked out to where I was spending the same
amount annually.

~~~
SomeCallMeTim
With PhoneGap you can have what looks like a "native app" to end users that's
written entirely in HTML5/JavaScript.

~~~
flyosity
I've done usability studies with users who use native apps and PhoneGap-based
apps and users are clearly perplexed by PhoneGap apps because of numerous
usability problems like 1) they're choppy, 2) they look/feel slightly
different, 3) they don't behave like user's think they should. Users can tell
the difference between a fully-native app and an HTML interface wrapped in an
Objective-C downloadable.

It's like the uncanny valley where humanoid things get _so close_ to being
fully realistic that the small difference in their behavior or look & feel
causes people to be totally turned off. If it looks like a native app but
doesn't quite behave like one, it's noticeable and (at least the people I've
talked with) do not like it.

~~~
SomeCallMeTim
hmmm...there's part of me that's just offended by the idea of having to write
an application twice.

Maybe the HTML5 experience isn't good enough, but it truly sucks to have to
write the app once for each platform.

I'd love to see the specific examples you're talking about; details like
whether the apps were made by people with equivalent skills, and whether
you're REALLY talking about the same app being judged better or worse.

Because it's so easy to write HTML5 and JavaScript, well, lots of idiots do
it. If the study compares an app written by a median HTML5/JavaScript app
developer with an app written by a median ObjectiveC developer, then it's not
the environment you're actually comparing.

~~~
flyosity
It's the norm to have to write applications for the platform you want to run
them on. Nintendo 3DS, Playstation 3, Wii, Steam, Android, iOS, Windows...
these are all different platforms. Write-once-run-anywhere is a myth and it
seems that web developers deploying to one platform (the browser) still can't
grok the idea of multi-platform development that desktop, mobile and game
developers have understood for years.

You can't get the best experience for each platform if the tools and
frameworks you use are dumbed down to accommodate the lowest common shared
experience across everything.

~~~
SomeCallMeTim
I actually do my development in cross-platform native code. My currently
library can target iOS, Android, and Windows, and I'd be able to add most
other major platforms pretty trivially.

I agree that some UI changes are necessary between platforms as different as
the PC, the Wii, and a touch-screen-based phone. But I very much disagree that
you can't take advantage of solid cross-platform tools. I've written such
tools, in fact.

Some native code to interface to native UI is necessary, but none of the
native UI is really rocket science, and something offered natively on one
phone can typically be done manually on another. Then it becomes an
abstraction in the cross-platform library, and your code doesn't need to know
how it's implemented.

But then again I'm a game developer, so I guess you've admitted that I could
potentially already understand cross-platform development. ;)

------
technoslut
It's sort of amusing to continually hear these arguments because they always
miss the main point: It doesn't matter what you, as a dev, prefers or
envisions. It's about what the user wants. Today they prefer native apps. They
look and generally perform better. There may be a day when web apps catch up
but it will be up to the user to decide which path is taken.

~~~
drewcrawford
> It doesn't matter what you, as a dev, prefers or envisions. It's about what
> the user wants.

That's a nice _theory_. Here's the reality:

1) Client wants to build 4 native apps for Android, iPhone, iPad, Blackberry,
WinMo7.

2) Client is in sticker shock that it will cost $100k+ to roll out

3) Client does a bit of googling, drawn like a deer in headlights to the
Titanium showcase page

4) Client ditches native apps, goes the Titanium route because it's cheaper,
doesn't realize that most of those are funded directly or indirectly by
Titanium

5) Client fails to monetize application because users think it sucks.

6) Chalks it up to "the market isn't ready", repeat from step 1.

This story is roughly 75% of the mobile contracting market by volume, although
for obvious reasons <1% in terms of app sales. It comes up a lot in enterprise
mobile dev as well.

The moral of the story is that it's __much __easier to focus on the upfront
development cost and ignore the unquantifiable murky cost of ending up with a
bad product. It's the same thought process behind e.g. credit card debt--
present pleasure for future pain is easy to rationalize.

~~~
tzm
Your analysis on Titanium development being cheaper and "sucks" is false. It's
the archer not the arrow. My company builds full stack solutions for clients
with projects of $50k - $100k. We work in obj-c, java, javascript and c, with
the bulk of development dedicated to Titanium.

You are patently wrong in your assessment and seem to miss some major aspects
of the Titanium architecture.

~~~
drewcrawford
Let me give you _just one_ data point backing my "patently wrong" assessment:

Read this documentation:
[http://developer.appcelerator.com/apidoc/mobile/1.4/Titanium...](http://developer.appcelerator.com/apidoc/mobile/1.4/Titanium.UI.iPad-
module) and tell me how I should use custom fonts. I reported this issue in
early July.

------
acangiano
Here is my thought process when it comes to the issue.

1\. What problem am I trying to solve?

2\. Which technology choice provides the best solution to the problem and the
best UX? Which one does the user prefer?

3\. Implement it.

That said, the author of this post is absolutely right in regards to the
browser being a limited cross-platform solution available everywhere vs native
apps being specialized solutions for a given platform.

Even developing the client side of a web app in HTML5, CSS3, JavaScript so
that it's fast and it works in most browsers is still more complicated and
tedious than anything you experience when building native applications.

There are two main advantages to web applications, though:

* A potentially larger audience (addressed in the post).

* The ease with which users accept to pay a recurring monthly fee. It can be emulated via in-app subscriptions, but let's face it, it's less common and/or accepted by users.

~~~
Xurinos
I wonder if this is one reason why World of Warcraft does all transfers of
real money through your account on the website instead of offering an in-game
store. On the other hand, I have played other MMOs, online FPSes, and so forth
that have in-game stores.

Come to think of it, the only correlation I can think of is that web
applications are more prolific for online sales than desktop apps, which
typically relied on a model of "buy me, install me, and you own me _". My
experience in the gaming world suggests that people are happy to pay for
things within the desktop game interfaces, too. I have also read that iPhone
apps with in-app sales (particularly for free apps) are greater than the
initial app sales, and it is obvious that users have no problems making
payments for things through their phone apps.

I assumed that "web app" refers to things that must be run through a web
browser, as opposed to "app that can connect to the Internet", which will
cover recurring subscriptions like Norton's latest virus updates and so forth.

_ "if you follow my TOS"

------
willvarfar
The problem with webapps right now is that they look and perform badly.

I just tried to make a multi-touch piano keyboard work in-browser using html5.
The only thing that worked was the graphics, since that was a single image!
The chances of playing a sound when the user presses a key in any kind of
cross-browser way seems shot.

Html has been around for decades and its still not fit for purpose.

~~~
LeafStorm
HTML is perfectly fit for the purpose for which it was designed - presenting
content in a way that different pages of content can link to each other. It's
only recently that people have begun to use it as a platform for applications.

~~~
jff
Yeah, if Tim Berners-Lee was dead, he'd be rolling over in his grave. As it
is, he's probably rolling over in his bed at night...

Unless of course he's totally supportive of using a hyperTEXT markup language
to write applications, I don't know.

------
joehewitt
HTML is capable of anything, given the makers of browsers will it to be so.
There's nothing inherently special about "native" technlogies, other than OS
makers tend to give new features to the platforms they own first. It doesn't
have to be this way, but will probably remain so, because the leading OS
makers (once Microsoft, now Apple) have the discretion to throttle the flow of
new goodies into their web browsers, and it would seem they often do. Really,
how else can you explain the fact that Safari in iOS 5 still lacks the ability
to utilize the camera?

------
bugsy
I used to say native applications were the only way to do a lot of things like
photo editing. Since then I have been proven wrong in finding photo editing
and even audio production tools running in web browsers. Not the highest end
stuff, but useful enough. Javascript has come a long way and Canvas really
reorganizes the playing field.

The thing I am realizing is both Apple and Microsoft have extremely unstable
APIs that are driven by political or maybe stupidity purposes (some non-
engineering reason), where perfectly good software just stops working because
some bureaucrat at the Duopoly decided to nix something for arbitrary or
foolish reasons.

But you can't do this with HTML apps, since it's not a monopoly, duopoly, or
oligarchy, it's an actual competitive market for browsers. If your browser
decides to stop supporting HTML4, it's broken and no one will use it.

This means you can write once for web apps and be confident it will continue
to work forever.

That's a huge advantage and has changed the way I think about things. Now I am
of the opinion that if there is any possible way to make something run in the
browser, that is the preferred and superior choice. It's also instantly Mac/PC
and Linux cross compatible too.

------
joshontheweb
Im a web developer and I agree with the speaker. Native apps are cool and have
shown what people really want from their interface but are only a stepping
stone. Web apps/browsers will catch up to native apps in capability and
surpass them value. see WebAPI <http://hacks.mozilla.org/2011/08/introducing-
webapi/>

~~~
gaius
Native isn't standing still. By definition, no web app can ever do anything a
native app can't - since the browser is a native app!

------
kalkat
Looking at it only from a technology viewpoint is parochial. The non-tech view
is that the whole app experience is fragmented. Apps that hardly talk to each
other. Apps that need to be updated every few weeks if not more often if I
want fixed bugs or newer available features. Apps that behave differently if I
move to a device running on a different platform.

But then, that is only half the story. Apps that can use the power of deep
access on front end, on top of a strong thing on the back end - those are the
apps which are really making use of native story to build a more useful
product than otherwise would have been possible.

------
tmcw
This is unreadable and unconvincing. Why is it rated up? You could make a
reasonable argument supporting the headline, but he doesn't. There's no
logical weight behind his conclusions and no evidence that he's actually
thinking about any evidence, and the cherry on the top is that he uses
inflammatory phrases like 'unquestionably flawed', and then making random
arguments about presentation vs data. Plus, web applications are 'by their
very nature unoptimized'.

The only conclusion I could draw is that this guy is an iOS developer who
likes developing native apps. Fine with me, but he doesn't go anywhere from
there.

------
tluyben2
Hmm. In my experience this is not true. Everyone in northern europe is having
apps made because it's something you need to do, but they are gambling on web
apps. Repackaging via Phonegap works there if written correctly, but I don't
see any native app feelings.

------
wnoise
Unreadable without javascript.

~~~
slug
I agree with you, it's ridiculous the need to activate javascript to read a
freaking webpage.

------
n9com
Web apps just don't have the same fast and slick feel as native apps.

We've tried making them work, but mobile browsers just aren't good enough yet
to process the JS at a reasonable speed.

------
protomyth
At some point, someone is going to get a client that is meant to run apps and
we are going to move beyond HTML / JavaScript / CSS.

------
skeptical
While i find this discussion interesting to some extent, I find it odd that no
one mention that the native and web applications use cases do not overlap
completely.

We have text editors IDEs, command line utilities, etc. not every application
needs to interact with a network. More importantly, not every web aplication
is some kind of fancy CRUD interface, we do a lot more with computers than
managing our online presence.

------
Hisoka
"Apple did not want to allow native apps on the iPhone, and was pushed into it
by the overwhelming strength of the jailbreak community. People wanted the
better user experience provided by native apps, and if Apple wouldn't allow
it, they would do it themselves."

Maybe I'm ignorant.. but how is this true? Apple could have NOT release the
API for creating iPhone apps, and there wouldn't be any iPhone apps. You can
crack, jailbreak, hack, and hax0r all you want. No API, no native app.

~~~
Wilya
Remember the iPhone is, inside, a Darwin system. Put a terminal, and the sky
is the limit. Plus, there is always an API. The API, in the first days, wasn't
public, but it was there. The base apps included (calendar, browser, etc)
needed it.

And there was an app store (well, a fully free store) before Apple even
released their APIs. I don't know how people discovered the APIs (reverse-
engineering ? Leaks from Apple ?), but they had them.

------
wavephorm
Native vs Web isn't what you should think about. At a higher level, what
matters is whether the software you're using or writing is centralized or
distributed.

Anything that does not specifically require decentralization probably should
be written as a web service.

------
ThaddeusQuay2
There is the third option of hybrid native/web applications, which I haven't
seen considered here.

One example is the Adobe Integrated Runtime, or AIR, which "... intends to
provide a versatile runtime-environment that allows existing Flash,
ActionScript, or HTML and JavaScript code to be used to construct Internet-
based applications that have many of the characteristics of more traditional
desktop-like programs." - <http://en.wikipedia.org/wiki/Adobe_AIR>

Another example of a hybrid option, one which is much simpler than AIR, and
which I haven't seen anyone really trying, is where the application is sold
without a GUI of its own. You interact with it through your browser, and it
acts as your proxy to the Internet. This allows for increased computation,
better display, and optimized communication, such that the experience is
somewhere between pure web app and pure native app. The customer gets the good
feeling of "owning" the thing for which they paid, and the developer's work is
simplified by using the browser as a cross-platform GUI.

