
The App-ocalypse: can Web standards make mobile apps obsolete? - nikbackm
http://arstechnica.com/information-technology/2015/12/the-app-ocalypse-can-web-standards-make-mobile-apps-obsolete/
======
nissimk
I like web apps so much better than native apps. I like seeing the https in
the address bar and I feel like I don't even trust that communications are
encrypted in a native mobile app. Developers are always trying to migrate me
into the app rather than the mobile site and it drives me crazy. I don't want
to leave the web browser. I love my back button and my tabs.

Why do the following applications benefit from native apps?

Reviews (Yelp, TripAdvisor) Ticket purchasing (Seatgeek, ticketMaster, etc.)

Very few of the answers have anything to do with the users. They all revolve
around app store exposure and annoying features like notification spam.

But on the topic of this article, I think the author is too critical of apple
as they seem to be moving in the direction of being more favorable towards
mobile web app developers. Features like WKWebView show this.

I'm sure in the end this is just a trend and mobile web apps will swing back
into favor at some point. Remember, in the early days of iOS native app
development was not allowed, and that was one of the first features integrated
to iOS frm the jailbreak community. Jobs' original app vision was mobile web
apps.

~~~
Cookingboy
Saying Apple is more favorable towards mobile web development is quite a bit
of a stretch. WKWebView simply gave developer access to the webview underneath
Safari, and replaces the outdated UIWebView.

Apple recently introduced Swift, an entire language framework that's aimed at
native app development.

User experiences is the where the biggest gap between web apps and natives are
(average users don't care about seeing that https at the top). Web apps also
cannot adopt the latest hardware features as quickly as native frameworks can
(TouchID, 3D Touch, etc). So for a platform like iOS (and Android to a large
extent) where it's all about vertical integration and optimization, we'll see
cutting edge native apps for a long time.

I'm not saying mobile web doesn't have its place, and there are plenty of
terrible apps out there that should just be a mobile website instead, but
native apps do have certain advantages that won't be matched anytime soon.

------
nextos
I really hate the situation where stuff that could be a website, or an offline
webapp has become an app instead.

All little transportation city schedules around Europe are like this, and it's
infuriating for a number of reasons. I can't use any other mobile OS apart
from Android (with Google Play) or iOS. Apps are siloes, so no other
webservice can reuse their data. It's generally quite insecure. It's a waste.

~~~
oneeyedpigeon
What's really bad is the app that is a carbon-copy of the corresponding
website, except slightly better designed in such a way that would be trivial
to implement on the damn website itself.

~~~
mahouse
Just some Phonegap shitty app, yes, I get what you mean. Sometimes it's just
an iframe so if you get the URL you can just open that on your phone.

------
yggydrasily
The article only gives three examples of APIs that are "missing" on iOS, and
one of them is the vibration API.

Since when is the vibration API a "good example" of something necessary to
"give the full app experience on mobile" (using the article's language)? Other
than message & phone call notifications, I don't want apps vibrating my phone
all the time. The W3C page they link to describes it as a "form of tactile
feedback", but that's nonsense, unless they are talking about the touch
feedback that newer devices like the Apple Watch provide, which is done mostly
at the system level.

Another example the article gives is CSS touch manipulation, which Apple has
already started working on[0]. So, the article is 1 for 3.

[0]
[https://bugs.webkit.org/show_bug.cgi?id=149854](https://bugs.webkit.org/show_bug.cgi?id=149854)

~~~
Silhouette
There are much more serious omissions if you're trying to build a web app that
works with Apple devices. For example, despite all the protestations about how
necessary it was to kill off Flash and use HTML5 for playing multimedia
content instead because Plugins Are Evil(TM), it is actually a plugin rather
than Safari that is playing a video when you visit a site on an iPhone or
iPad. As soon as you want to do anything interesting with all the extra power
that making audio and video just two more types of content on the Web should
bring... even basic stuff just doesn't work. Except for every major device but
Apple ones, that is.

------
oconnore
It's hilarious that people keep trying to solve this as a technical problem.
Apple has a business model based on disallowing compilers/JITs/interpreters on
the app store. Does anyone here think that seamless offline mobile web apps --
anything capable of general computing without approval -- isn't on their radar
as a threat to that business model?

~~~
brlewis
The article talks about this at the end:

 _So maybe what we all need right now is the killer Web app—a demonstration of
a website that performs beautifully, even if only on Android. Maybe that would
get users’ attention and, maybe then, Apple’s attention._

~~~
oconnore
Ah yes, the old "web app so cool that Tim Cook decides to flush money down the
toilet" strategy.

~~~
zzalpha
Precisely. Unfortunately, there's a certain blindness to business realities
among the tech community... a naive faith that the best, most open technology
will obviously win, this despite copious evidence to the contrary.

Flash had no chance against HTML5. Why? Because Adobe had no way to force it
on users, and vendors had every reason to want to exclude it, from support/UX
to battery life to security issues. The minute open standards reached a point
where HTML5 can take over, it will.

But high quality mobile web apps are a _direct threat_ to Apple's and Google's
business models for their respective platforms. The app stores are a primary
way those organizations generate revenues with those platforms. They have
precisely zero reason to move away from that model.

And it's only with vendor support that mobile webapps have any chance at all.
In both cases, the vendor is responsible for delivering the primary HTML
renderer and JS engine. In both cases, the vendor is also responsible for
exposing the APIs to the underlying OS that a webapp will rely upon for
maximizing integration with the platform.

Meanwhile, from the consumer's perspective, they're looking at apps, which
have great OS integration, great performance, etc, versus a clunky webapp...
the choice is obvious.

So you have no consumer demand, due to vendor control ensuring webapps are
inferior, and no vendor demand because apps are a direct source of revenue
while the APIs encourage platform lock-in.

It just ain't gonna happen.

~~~
brlewis
Your comment about Google's business model is addressed at length in the
article. Look for the section entitled "The difference with Google".

If the web starts to work way better on Android than on iOS, Apple can still
ignore it, but at least then consumers have options.

~~~
zzalpha
You (and the author) are presuming Google views mobile web apps as a
competitive advantage, but we have no evidence for that.

Moreover, the article clearly conflates the desire to make web sites perform
well, with the desire to make mobile _web applications_ perform well, with no
basis for that assumption. Yes, lots and lots of Chrome users visit web sites.
That doesn't mean Google feels a need to optimize Chrome to deliver mobile web
apps (which requires things like richer, deeper integration with the OS).

------
MatthewPhillips
I implemented an app that uses Web App Manifest and Service Workers and uses
material design lite. It's almost indistinguishable from a native Android app.
If I put a little more effort into the animations it would be even closer.

The biggest gap I find is sounds. There's no way to say "do the native click
sound here". Now I could find the sound and play it in an <audio> element but
I'm sure that these sounds differ depending on manufacturer and surely differ
on iOS and WinPhone.

~~~
TeMPOraL
> _It 's almost indistinguishable from a native Android app. If I put a little
> more effort into the animations it would be even closer._

The key phrases here are "almost" and "If I put a little more effort". The
almost-but-not-quite-native webapps are the mobile ecosystem's equivalent of
the uncanny valley. It sort of looks like an app, but then it suddenly 404s a
button, or starts lagging, or doesn't do the default for native controls, but
rarely used function. It's enough to break user's trust in what the app is and
what it's doing. It feels like Java's Swing all over again.

~~~
hackcoughgasp
The standards are still young and implementation is spotty. Several years from
now the things that you can't do in a web app will be few.

------
Silhouette
The trouble with web apps -- speaking as someone who writes them for a living
-- is that almost every major browser is now awful in terms of quality of
implementation of at least a few major features, the evergreen browsers break
stuff all the time on top of that, and the front-end tools ecosystem is a
punchline. This kind of blunt assessment tends to garner downvotes, but the
bug tracker does not lie. The number of backward steps we have taken in the
web development community over the past few years is astonishing, but because
we can't control the browsers and the goals of the browser developers do not
necessarily align with the goals of most people developing web apps, as
developers we are also limited in how much we can do about it.

In contrast, apps live in walled gardens on some platforms and we understand
that there are some major downsides to that, but the programming languages and
tools used to build them are relatively reliable, and the systems on which
they run are relatively stable (which is saying something considering how
often they do change in some cases).

It used to be that for a lot of tasks developing a portable web app was a more
sensible choice than developing multiple native apps in parallel, unless you
actually needed to integrate native-only features or you expected to derive a
lot of benefit from being available via the corresponding app stores. For new
projects in 2016, we'll be seriously considering whether that is still true on
a case by case basis, and whether it really would be more efficient to build
native versions for the major platforms we want to support and dropping front-
end web development for some projects entirely.

~~~
SiVal
I'm upvoting in hopes you'll continue to share your experience and (evolving)
conclusions.

~~~
Silhouette
Thanks. I'm generally happy to share anything useful I've come across on our
projects, though I suspect in this area the conclusions will probably depend
greatly on the specifics of each individual project.

------
mark_l_watson
Good article that explains why I don't (and probably won't) use an iPhone.

My Android Note 4 supports web standards, lets me creating web link icons on
the phone "desktop" and is generally great for web browsing.

For somethings like accessing Twitter and Facebook I don't install the apps
because I don't like the required device permissions. I do use a few apps,
like an SSH shell, but whenever I can I stick with mobile web apps.

~~~
extra88
iOS also lets you create web link icons on the device (had this feature since
Day 1, before the app store existed) and I'm pretty happy with the browsing
experience on the iPhone 5S.

I don't worry about the "permissions" for the Twitter and Facebook apps
because iOS lets me selectively allow/deny them so I don't allow them to
access my contacts, know my location and only access my photos when I choose
to send a photo.

~~~
Drdrdrq
This is one area where iOS rocks. Seriously, how difficult is it to make
permission system granular?

------
danso
I literally LOLed at the title and clicked on the article half-believing it's
part of an online performance art exhibit in which nouns are switched around
in headlines on a yearly cycle, as a way to reiterate the lessons of the Book
of Ecclesiastes [1]:

    
    
        What has been will be again,
        what has been done will be done again;
        there is nothing new under the sun.
    

ArsTechnica's sister, Wired, is a particularly frequent propagator of the
"Native is killing mobile web" debate:

\-
[http://www.wired.com/2010/08/ff_webrip/all/1](http://www.wired.com/2010/08/ff_webrip/all/1)

\- [http://www.wired.com/2014/01/death-pc-also-mean-end-
web/](http://www.wired.com/2014/01/death-pc-also-mean-end-web/)

\- [http://www.wired.com/2015/06/apples-support-ad-blocking-
will...](http://www.wired.com/2015/06/apples-support-ad-blocking-will-upend-
web-works/)

That said, the submitted article is a nice summation of how the Web has grown
so far, and the new APIs and proposed specifications that will (hopefully)
impact web development in positive ways.

It lacks one notable article from this year: Atavist's announcement that it
was ditching its native app: [https://atavistinsider.atavist.com/goodbye-
native-mobile-app...](https://atavistinsider.atavist.com/goodbye-native-
mobile-apps)

I haven't seen many other announcements like that.

[1]
[https://www.biblegateway.com/passage/?search=Ecclesiastes+1](https://www.biblegateway.com/passage/?search=Ecclesiastes+1)

------
spotman
When we see things like instagram, snapchat, spotify, sound cloud, uber,
mobile banking apps, IoT apps, and more becoming native, then this narrative
is more interesting.

Just with the IoT stuff, and the fact that many of these apps use cameras,
bluetooth, wifi, gps sensors, and more, I think that this is still years away,
and by then, what else will native SDKs be capable of that browsers have not
caught up.

Browser tech is just getting far enough along where there is things like
offline data that works good, but it hasn't caught up yet. I think "app-
ocalypse" is a little too strong of a scare statement in my humble opinion.

The article mentions google inbox as an app that shares code, but if I am not
mistaken, this is still an app store app, so while they may be able to
dynamically change how the app works server side, they still are in the app
store, billing it as a native app, so this seems to work against an app-
ocalypse.

------
Yhippa
What a wonderful world we would be in if vendors compete on how best they can
implement a spec. Assuming "best" means "as close to spec as possible" and
that the spec is fairly well defined.

I use Facebook across multiple different platforms: web, Android, iOS, and
Windows. Instead of them putting so much effort into maintaining different
codebases I think it would be better if they could maintain one and use their
freed up time and resources to deliver new features.

They actually are able to do this to some extent on Android. They have
notification hooks in there and I can do almost anything I could on the native
app. I'm pretty close to uninstalling the native app in favor of this.

Competing on spec would allow for different and possibly new phone OSes to be
viable. Windows Phone would have a shot and we can bring back webOS from the
dead (my favorite device OS of all time).

~~~
yoz-y
Facebook tried that and then rolled back on the decision. Maybe if android
CPUs catch up to the A series this might be possible. But so far the android
devs I know (myself included) simply find the web performance on android
phones abysmal.

------
xiaoma
No. Web standards can't make native apps obsolete. They can't do it on the
desktop and they can't do it on a mobile device.

Certain things are better done as web apps, other things are much better
native. Some quick examples off the top of my head would include IDEs, office-
type apps (and yes Excel _still_ crushes Google spreadsheets), games, video
players, spaced repetition software, compilers, rich chat applications such as
LINE or WeChat, as well as anything people want to keep private.

Web apps are great and I love open web standards. That doesn't make them the
perfect solution for _everything_.

~~~
api_or_ipa
If you're doing __anything __significantly laborious in Excel, you should be
using a different tool. Excel is not performant for anything >200,000 rows for
even simple queries.

~~~
xiaoma
Mostly I've worked on documents with under 500 rows. Excel is a much snappier
UX all around than Google spreadsheets (which I wouldn't use for over 200k
rows either).

------
nkron
Apple recently checked in support for touch-action: manipulation

[https://bugs.webkit.org/show_bug.cgi?id=149854](https://bugs.webkit.org/show_bug.cgi?id=149854)

------
NOtherDev
This is a great article focusing on the same new possibilities I wanted to
cover creating What Web Can Do Today
([https://whatwebcando.today](https://whatwebcando.today)). The gap between
native apps and the web exists and probably will exist, especially until
Apple's strategy doesn't change dramatically, but that's quite unlikely now.

The set of APIs available is quite broad, though, not limited to what was
mentioned here, and growing quickly. The hybrid apps are the option, but I
find it a bit half-arsed workaround with all the cons of the installed apps
and all the cons of the web. Investing in the web is the way to go!

------
jes
There are times when I either don't have access to the Internet, or my service
is very slow.

During those times, the apps on my phone are still useful, albeit, degraded in
some respects. I'd still rather have that than nothing.

~~~
maxerickson
A web app could be cached locally, so using the browser as a runtime wouldn't
preclude working without a connection.

~~~
jakub_g
(note I'm generally a pro-web anti-app guy) That is easier said than done.
Never worked with the thing, but I've read everywhere that HTML appcache is
not exactly the best thing ever invented and a pain to work with. Service
workers which are proposed to supersede it are now being pushed by Chrome and
others, but it sounded a bit complex (though powerful) when I read about it.
Then come all the other issues about cache invalidation including involuntary
automatic cache clean (hey, I'm low on memory, let's clear the cache!). Your
apps generally don't automatically uninstall themselves (though they may clean
their cached data, at least on iOS).

Regarding the standard browser caching and "offline mode", it used to work
well long time ago for simple static HTML pages (in Firefox and IE), but from
my experience it doesn't work well for rich clientside apps (and Chrome
doesn't even have "work offline" button)

~~~
jaffathecake
There's a spec in development to make an origin's storage persistent
[https://storage.spec.whatwg.org/#dom-storagemanager-
requestp...](https://storage.spec.whatwg.org/#dom-storagemanager-
requestpersistent) \- at the moment Chrome only drops data from indexeddb and
the cache api if the device starts running out of space.

------
Aleman360
OS shells and browsers need to unify first. Something like what Chrome OS does
seems like the way forward. Users shouldn't have to care if their pixels are
being painted by HTML or native frameworks.

------
nickpsecurity
Three words: efficiency, flexibility, and security. You get more of all with
apps. More true if it's a business solution than a consumer site/app. On
latter side, the adoption part is less of a problem these days where users
will often download an app for a site they're already hooked on. The problem
for consumer apps, aside from getting noticed, is becoming on of the few users
stay on vs disappearing into the background. A situation similar to the
vegetable drawer on bottom of fridge.

~~~
oneeyedpigeon
I'll give you the first two, but surely native apps can have more access to
data stored on the device than a website can. And can do more damage, too.

~~~
nickpsecurity
Why is that? The _native app_ loading the website restricts its access and the
app is itself restricted. Yet, it has much more privilege than a web app
needs. Same techniques used with better results.

------
gregdoesit
How much money does the App Store make for Apple? And how much would web based
apps make?

It's not a technical problem, it's a business model.

------
drcode
No, we're going to have a "black swan" event: Decentralized dapps are going to
make BOTH apps and websites obsolete.
[https://dappsforbeginners.wordpress.com/tutorials/your-
first...](https://dappsforbeginners.wordpress.com/tutorials/your-first-dapp/)

~~~
xiaoma
Dapps are _extremely_ interesting and I agree that most people are completely
ignorant of the potential. I don't think they'll make anything obsolete
though. They'll just carve out an interesting new niche (which, depending on
regulation, will likely be a double-digit % of the market).

------
pbreit
I think Facebook might have a big opportunity here to put some app-only
features in its app (primarily notifications and Apple Pay) and be able to
route a massive amount of communication and commerce through its app.

------
nolanl
I'm quoted at length in the article, so I feel obliged to respond. Overall I
think it's good, but it misses some nuances.

First off, there's a small contradiction about offline storage. The author
says that users prefer web apps because they take up little-to-no space, but
that the web needs to catch up in terms of storage capability. You can't have
it both ways - if websites become more offline-heavy, then users will need to
get accustomed to managing their available space (as they already do with
native apps). This is an as-yet unsolved UX problem for the web.

Also, based on the comments in this thread, I think many people don't realize
how far the web has come in terms of offline storage. Today you can build a
mobile site that stores MBs of data, launches from the home screen, and works
even in airplane mode. (On Android anyway. iOS is another story.)

I built a small site to demonstrate:
[http://www.pocketjavascript.com/blog/2015/11/23/introducing-...](http://www.pocketjavascript.com/blog/2015/11/23/introducing-
pokedex-org). On an Android phone, Pokedex.org is basically indistinguishable
from a native app, at least once you add it to the home screen. In Chrome, tap
the green lock and you can see exactly how much space it takes up (around
6MB). Feel free to put your phone in airplane mode and refresh the page - it
will still work.

Second off, there's a lot of speculation in the post about Apple's motives,
and why they might be throttling back on the web platform relative to Google,
Mozilla, and Microsoft. I'm guilty of this myself in "Safari is the new IE,"
but nowadays I try to have a more nuanced take.

AFAICT, Apple seems to have many small teams with many different motivations,
as does Google. Within Google, you'll even find teams that actively undermine
other teams - e.g. what the Chrome team is doing with Progressive Web Apps is
a direct threat to Android apps. (I'm even surprised to see one team
occasionally trash-talking the other on Twitter.) So talking about "Google's
motives" or "Apple's motives" as if they're each one big monolithic entity is
a little simplistic.

My favorite theory about Apple and the web comes from this article
([http://blog.html5test.com/2015/07/safari-and-
ie/](http://blog.html5test.com/2015/07/safari-and-ie/)), which argues that the
WebKit team is just too small since the Blink split, which is why they've been
having trouble keeping up. No grand conspiracy theory required - just that the
team is a little under-financed. Also, Safari is still rocking it in terms of
performance and battery life, so it's not like they're asleep at the wheel.

I think the web still has a chance to catch up with native (for a lot of use
cases anyway, not all of them), but it will require a change in how we build
websites. In the same way that XMLHttpRequest was around for years before web
devs "discovered" Ajax, I think offline storage and various mobile APIs might
lay dormant for awhile before suddenly everybody is taking advantage of them.
As web developers, the ball is in our court.

~~~
hackcoughgasp
I'm the author of the article and I'd like to thank Nolan one more time. He
really helped me to understand a lot about this. The storage issue is this: If
you install a native app, the code is there on your device, the entire
program, even if you haven't used it in a month. The code in the web version
of that app would likely consume nothing soon. The amount of data consumed by
each should be equal I think. No question Google has many teams working at
cross purposes. It's a "throw everything up against the wall and see what
sticks" approach. (What else could justify Chromebooks?) Apple has done this
too in the past, but the distant past: Think Mac vs. Apple ][. But by now I
think the value of their app store and ancillary revenue streams is so
significant that institutionally I would expect them to be reluctant to do
anything that would threaten it. I assumed in the story that Google had all
the same perverse incentives as Apple in this regard, but I suppose app and
in-app revenues for Google are probably a small fraction of Apple's. They're
not even really trying hard to maximize that revenue. They allow 3rd party
stores. But if even mobile devices moved back to the web, the ad revenue on
them would move back to the platform that they dominate. So perhaps that
explains their motivations.

------
enos_feedler
How is native vs open web still an interesting narrative? I was hoping for
some new spin as I read this but its still the same apple trash-talking.

Somehow it always seems to be about CONTROL with native. Control of the
platform is something _earned_ because the end-user experience is just better.

Apple might look like they are defending their powerful native app position,
but how about they just believe its better? They started the iPhone with web
app and realized its better for the end user when software is written as
extensions to the core OS rather than on top of a browser engine?

With everyone iOS release, they go further down the road and continue to prove
to both developers and users (who use the developer's features) that there is
more innovation to be had with native, with more endpoints at both the low and
high levels. It isn't just about sensors and vibrations and better hardware
interfaces. It a better interface with the OS itself. You want the presence of
an apps value on your phone but have those things show up in familiar places.
This is why you have today screen extensions. I am sure notes extensions,
calendar extensions, etc are coming.

~~~
dyoder
Is it so much of a stretch to believe that a vendor might believe it is in
their best interest to control the application platform? Why give Apple the
benefit of the doubt here? Ironically, one reason to do that is that Apple is
active in defining and implementing Open Web standards, many of which are
aimed at improving the Web as an app platform. Which, in turn, is exactly why
this is still an “interesting narrative”--both Web and native are rapidly
evolving.

~~~
enos_feedler
I think it is in their best interest to control, but I've seen that spun as
the end not the means. Apple's ultimate goal is not control of the app
ecosystem, but to improve end-user experience. Control is a necessary part of
that.

And the narrative I'm referring to is web VS. native. like one is going to
kill the other. We keep talking about this battle but there is no winner, each
has their place. period

