App stores are not the future, says Google | Hacker News Reader

App stores are not the future, says Google

blogs.ft.com

31 pointsAnon8421 comments

They didn't seem to really be talking about App stores per se, more about 'native' apps vs browser apps. I still think that native apps will be prevalent for some time yet, especially were performance is an issue which is often the case with mobiles. Many newer applications, which have only become a possibility because of hardware advancements, require higher level of performance as well. For example I don't see real-time video based 'reality overlay' applications running on your mobile browser soon.

It is really much more pleasant to use an iphone app rather than an in browser app. Not only is the appearance far better, but, I don't have to wait for a button to load. It's there already and I can push and wait rather than, wait, push, wait.

Part of HTML 5 that Google and others have been pushing is the ability to run browser based apps offline (think Google Gears), where the browser is basically a rendering engine and javascript sandbox, rather than a means of accessing remote resources. This is what they are referring to here.

> Webkit, which Apple had turned into an open-source project, was also powering the browsers on the Android and Palm operating systems.

Wasn't it already open source with KHTML?

Yeah wow, journalists seem to be complete retards when it comes to technical subjects...

http://en.wikipedia.org/wiki/WebKit

"WebKit began in 2002 when Apple Inc. created a fork of the KDE project’s HTML layout engine KHTML and KDE's JavaScript engine (KJS)...

...On June 7, 2005, Safari developer Dave Hyatt announced on his weblog that Apple was open sourcing WebKit (previously, only WebCore and JavaScriptCore were open source) and opening up access to WebKit’s CVS tree and Bugzilla tool.[11] This was announced at Apple’s Worldwide Developers Conference 2005 by Apple Senior Vice President of Software Engineering Bertrand Serlet."

This talk on the history of KHTML is also pretty interesting: http://yuiblog.com/blog/2006/12/11/knoll-staikos-video

If it began by forking something else, then it began as that something. Apple created the name, the QT abstraction layer, a bunch of patches, and some other work, which was great. To say they 'created' a fork of an existing project is somewhat dubious.

You're probably right, but it's literally true that Apple created WebKit -- even if WebKit is mostly code they didn't write.

Very few open source projects are created in a vacuum.

The point of an App Store is to be a place where it's acceptable to charge money. Customers come in (at least to the paid side) expecting to pay. I would never pay $1 to login to http://www.runpee.com/ but I gladly paid $1 for the mobile app (http://www.appstorehq.com/runpeemobile-iphone-46448/app).

People have been taught that stuff that comes through the browser is free. GOOG (and MSFT?) wants more stuff to come through the browser so that people will spend more time on the interet, while AAPL just wants people to spend more money. For the sake of developers, I hope AAPL wins.

“Many, many applications can be delivered through the browser and what that does for our costs is stunning."

Well it's true that there is no cost at Google's side, but most importantly there is also no gain. Apple does have to pay for the servers, the bandwidth... But they also are making money out of it.

It may be true that the future is the browser, but I currently see no way for companies like Google and Apple to charge money for a web app.

It will be interesting to see how they standardize things like access to accelerometers, GPS and cameras. Palm currently has APIs for this, right? Anyone know how that works? Are they accessible from Javascript?

[Edit: The Pre APIs do appear to be accessible from JS (http://developer.palm.com/index.php?option=com_content&v...]

The way this works is simple: The Browser becomes the OS. Where you had an abstraction protected by API's in a previous OS, you now just have an interface provided to you by the local client (browser). All of this can be abstracted easily enough, and will be .. its already happening on Android, where you can access GPS and Accelerometer from the browser ..

It depends, also, on the hardware integration. Hey, good thing there is a VM around to handle this issue.

It won't be the VM or App developers slowing down progress in this area. It will be the "standards" issue so that developers don't have to write three different modules for three different accelerometers and properly load the right one depending on which iPhone or Palm Pre you have. That will definitely slow things down as vendors fight over which of their API is "the bestest" for all phones/netbooks.

The thing is, even if all of the currently "common" hardware features become part of some standard, there will be additional features in the future that will not, and browser-based applications will not be able to take advantage of this hardware as quickly as native applications can.

So, as long as you're comfortable waiting for WC3 to "bless" support for a device, and then browser vendors to turn out apps (which are these so-called irrelevant native apps themselves), then in that case I agree.

While I do agree that web browsers could be the future, I expect it will take a long long time for the industry to transform. Given that some many browsers and standards on the market these days, can you take the risk to develop an application just working on Chrome? Even you do, if your customers don't like Chrome, you have no way to reach them. At the end of the day, you still have compromise with customers, no matter how great Chrome and HTML 5 are.

Browsers other than Chrome also support HTML 5. Sure, support is partial at this point, but the standard hasn't even been released yet. What makes you think someone would develop an app that only works on Chrome?

Projects like Google Native Client ( http://code.google.com/p/nativeclient/ ) makes me think that. If you can execute X86 code and leverage hardware acceleration through a browser that would probably be worth telling people to download Chrome to use your app.

Given that NaCl is open source I would expect to see it running in all webkit-based browsers as well as mozilla, not just chrome.

Web apps are already a better solution for a lot of kinds of apps - apart from some additional eye candy that you can implement with native apis.

Full control, no approval process and instant updates.

It is already happening on the desktop sw for the vast majority of users (whether we like it or not) and I can't see how this shouldn't be the future of mobile apps as well.

Browsers are not inherently slow. They're slow if you want to make them do things they were not designed for.

Take real-time 3D, for instance. We just need standardized APIs to do things like O3D (http://www.youtube.com/html5) and we're set.

MobileSafari, the PalmOS and the Android browser are all built on webkit. So here's where these things will happen in the near future.

An API for real-time DSP would be another milestone, in my opinion.

So...what about devices that are not always (or reliably) connected?

I'm aware that there are several "web apps offline" approaches, but doesn't that make the app a sort of native/web hybrid?

...or do they mean that native apps are not the future, except apps that run in a browser, natively?

I believe html5 should help bridge the gap when things are offline as it supports a concept similar to Google Gears. So yeah, the next generation of browsers is a able to change traditional app design.

Reply on news.ycombinator.com