The App-ocalypse: can Web standards make mobile apps obsolete? | Hacker News Reader

The App-ocalypse: can Web standards make mobile apps obsolete?

arstechnica.com

62 pointsnikbackm69 comments

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.

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.

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.

I sorta hear you but not the best example since transportation data benefits greatly from geo-locating which works much better in apps.

There is one good transportation app on Android, it's called Google Maps. It covers 90% of use cases. I absolutely hate that my city decided not to give Google the data (second-hand intel tells that it's because public transport provider signed some exclusivity deal with a local startup, which sole raison d'être is that the data is not on Google Maps). In a perfect world, city transportation data and transport apps would be independent, so that you could use your favourite app in all cities.

Generalizing from that, the problem with apps is one of interoperability - everyone tries to lock you in their shitty app gaining little, but taking away huge benefits that could be created by combining data sources from different parties. As it is now, companies are run by control freaks who don't care that great things are created by not trying to capture all the value you create.

Sometimes it is not the city's fault. In my town the data is publicly free to use for commercial and non commercial purposes. Google does not give a damn about it though (I live in a fairly large town in France)

There's a difference between serving free data (likely in some idiosyncratic format on some idiosyncratic schedule) and doing the Maps integration oneself. I see many French cities at [0]. I doubt that Google has developers assigned to each one. It seems more likely that each one has its own people using a Maps API to keep Maps transit data current.

[0] https://www.google.com/landing/transit/cities/index.html

I've never had a problem with browser geolocation via navigator.geolocation. What issues are you seeing?

On iOS it's substantially clunkier for the user. They have to keep agreeing to the coo popup every time they visit the site. And there's not background geo-locating. It's really not even comparable.

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.

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.

What's worse is when the app is similar to a carbon-copy of the website but actually worse because it messes up content sizing in ipad portrait view. Looking at you, Coursera.

I agree with you, particularly when the stuff could just be a simple HTML page or collection of pages (e.g. transportation schedules: those were just sheets of paper recently: why should I need a mobile app or a webapp to read a schedule?).

But I also hate when something which should be a native app is instead a JavaScriptified webapp.

There are things that should be apps, and things that shouldn't. The line is blurry, but there are few rules of thumb:

- If it can be done off-line, it should be done off-line; hence, an app. Example: public transportation: you shouldn't need an Internet connection to check bus schedules or find a route through your city. Transportation schedules update infrequently, so they should be cached.

- If it's just browsing on-line content, it probably should be a website.

- If performance matters, it should be native (unless you're writing a game or specialized software, performance probably doesn't matter).

- If you're just repackaging your website as an app because apps are hot, please don't do it at all.

Sadly, IT reached the state where customer's interest and company's interest are seriously at odds with each other, and so we have a proliferation of bullshit apps that exist only to destroy the interoperable nature of technology in order to capture ad money.

The articles point to your first point is the web and the browser platform provides the tools you should need but apple is not implementing the features into safari required

  - service workers
  - webrtc
  - app manifest

For transit, how about using a Transit App that covers those cities.

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

A more important API than Vibration is the Web App Manifest which is the new way to do "Add to Homescreen": http://www.w3.org/TR/appmanifest/ Pretty sure WebKit doesn't support this yet.

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.

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?

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.

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

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.

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.

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

Except that JavaScriptCore is a blessed way to build apps and accept OTA updates now...

> blessed way to build apps

This is the whole point. You still go through approval uncertainty, 30% tax, the threat of revocation, etc.

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.

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

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.

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.

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

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.

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.

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.

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

iOS does support adding links to pages on home screen, caching the application, hiding the safari UI etc. Granted, you won't get service workers and some touch events related stuff (yet) but nothing is stopping you to make an iOS app fully on web stack and distribute it while bypassing the App Store. https://developer.apple.com/library/ios/documentation/AppleA...

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/2014/01/death-pc-also-mean-end-web/

- http://www.wired.com/2015/06/apples-support-ad-blocking-will...

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

I haven't seen many other announcements like that.

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

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.

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

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

That's only possible if someone is writing a spec, and that someone is not the vendors.

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.

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.

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.

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

Apple recently checked in support for touch-action: manipulation

https://bugs.webkit.org/show_bug.cgi?id=149854

This is a great article focusing on the same new possibilities I wanted to cover creating What Web Can Do 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!

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.

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

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

The article is speculative. So I meant in principle, I have zero clue how practical it is right now.

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

Many, if not most, apps that depend on the Internet in some fashion do not handle losing the connection gracefully. Furthermore, it has been possible to write Web apps that can run disconnected (assuming they've been run at least once with a working connection, analogous to downloading an app).

Web apps are improving in this respect. I'm particularly interested in stale-while-revalidate that has experimental Chromium support now: https://code.google.com/p/chromium/issues/detail?id=348877

CDNs (at least Fastly) already support it, but browser support will give web app updates the option of working like native app updates.

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.

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.

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.

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.

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.

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

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

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.

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

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.

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.

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.

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

Replace the word Apple here with Microsoft and you would be making the argument for open standards and platforms circa 1999-2005. In the end the web was built so we didn't have to download a bunch of software. That is the logical conclusion of this debate.

The web was not built so we didn't have to download a bunch of software. I think you're making an argument for web apps. The web as a "document" is much older than that.

We need an open standard for apps but it doesn't have to be built on top of the web. I think we are going to witness the birth of new app standards built on top of open container specifications that can wrap native binaries.

Reply on news.ycombinator.com