

Beyond App Stores: Weaving Apps into the Web - gaborcselle
http://blog.gaborcselle.com/2012/12/beyond-app-stores-weaving-apps-into-web.html

======
daleharvey
Take a look at open web apps / chrome apps / phonegap / the Firefox OS project
(I work on the latter). The line between apps and websites is getting thinner
by the day, and getting very close to being non existent.

Also the 'apps are an island' comment is quite specific to iOS, Android has a
very elegant system for allowing apps to interact with each other, one which
the web is adopting (web intents/activities).

The basic premise is the wrong way round, web apps will adopt native
functionality (web api's) and native performance (which already good enough
for most use cases), they will (and can often already do) work offline.

'Native' apps are almost by definition going to have to be rewritten for every
platform and will never have the same introspection and interconnectedness as
the web.

Which platform do you think is going to fix its disadvantages first? seems
obvious to me.

~~~
awo
I think the key question is where will the consumers go? Android is more open
than iOS, but devs continue to build for iOS first b/c that's where all the
users are at, especially the paying users.

I only know a little bit about the Firefox OS project, but if you give control
to the OEMs, won't you run into the same problem that Android has with
fragmentation?

On one hand, I don't want to be naive. Everything on the desktop has moved
into the browser. That happened a lot faster than I though. Everything in
mobile is moving 2x the speed of desktop, so will everything move onto a
browser in mobile eventually too? The key difference between the desktop and
mobile is that there isn't hardware ubiquity. Every computer has a keyboard
and a mouse. But the hardware buttons aren't standardized across Apple and
Android. The home button is crucial on the iPhone and same with Android. Would
either of those platforms ever cede control over that button to a browser?
Otherwise, you've got to put that functionality on the screen which takes up
space.

~~~
daleharvey
'fragmentation isnt a problem, its a fact'

We will never convince the entire world to settle on a single device, Androids
biggest 'problem' is a large part of why it is completely dominating the
mobile market (although I dont disagree that OEM customisation can be
annoying).

Apps dont have control over the home button on iOS / Android, I dont
reallyknow what you mean 'cede control' (unless you are thinking Firefox OS
runs inside Android / iOS as an app? it doesnt, its a full OS)

------
BroNamath
I don't like apps anymore. Why would I want Hotel Tonight (for example) on my
iphone from a trip to Dallas two months ago. The constant updating,
notifications, etc. Apps are a mess. I don't have a solution but I do know I'm
tired of apps.

~~~
rwbt
Exactly, Mobile Apps (not games) are rapidly becoming the CD-ROMs of the
modern times. Too much waste of space and resources for such a minimal use.

I only use email/rss and twitter apps. Everything else I always try to do in
the browser.

------
moocow01
"let mobile browsers download small apps and execute them within the browser
window"

If you want to know how this turns out you only have to look at the evolution
of browser plugins (applets->flash,silverlight,unity,etc) that has taken place
for the last 20 years. We could also decide to skip all that and just
concentrate on moving forward the HTML spec and tools to make better mobile
web applications.

------
jiggy2011
Automatically downloading and executing binary code from the web. What could
possibly go wrong?

Isn't NaCL supposed to in part solve this?

~~~
webXL
Take out that automatic nonsense and I think he makes a good proposal. A URL
can currently load a local app rather than a page in webkit. Only in this
case, there would be some markup that would tell the browser to check for the
installed app, perhaps the browser would present some unobtrusive indicator
that a hybrid app was available to download. Just keep the address bar and the
rest of the browser chrome there, swap the webkit frame out with the app's
window, let the app access some of the history APIs, and you'd have a good
portion of this figured out.

~~~
gaborcselle
Thanks for seeing the value in my (somewhat avantgarde) argument.

I'd be happy with the app availability indicator as well. The native app would
still remain within the confines of the browser, so that you could easily
navigate away. People don't install apps today because it takes time to
download them, and the browsing experience is interrupted by switching to a
different app.

~~~
phil
Ah, I misunderstood your proposal. This would actually be a great update and
is pretty plausible.

Like, a streamlined way of installing an app and the ability to launch it with
some URL the first time. Relatively easy, not a platform threat.

------
notatoad
The proper solution to this problem is for content providers to build a
properly responsive site. Allowing apps to access browser cookies isn't going
to fix anything - the reason that a native app doesn't open to the place you
left off on the web is not because it's technically impossible, it's because
app developers don't give a damn. Giving them more tools isn't going to change
this.

~~~
gaborcselle
Allowing apps to access browser cookies is a solution to the problem that apps
and websites are disconnected and don't know about each other's state. That's
a different aspect than the one you're talking about.

Yes, you can build responsive sites, but what you can do in the browser is
limited, especially when it comes to flaky connections that are still very
typical. To take the example in the post a little bit further: Imagine you're
on the train and are reading a multi-page New York Times article. Train goes
into a tunnel. Trying to load the next page will result in a connection error.
Native apps can know about your network state and can pre-cache content you're
about to read next.

~~~
daleharvey
web apps can know about your network state and can pre-cache content you're
about to read next. (<http://www.html5rocks.com/en/mobile/workingoffthegrid/>)

~~~
lukifer
Last I checked, implementations of offline caching were unusably buggy. Has
this improved?

~~~
notatoad
It works. LocalStorage API is pretty solid and widely supported, if you're
doing some simple buffering to handle connectivity issues it's awesome, except
that it prompts the user for permission to store data. WebSQL is solid where
it's implemented, and IndexedDB is solid where it's implemented but
unfortunately there isn't a lot of overlap (screw you apple). and AppCache
works great, but figuring out how it works in the first place is annoying as
hell.

------
colevscode
we can call them "applets"!

~~~
johnrob
Over time, we'd discover that this sandboxing platform is more useful for
running server processes on co-located tablets.

------
phil
This would be pretty neat, but file it under "things that will never happen on
iOS in a million billion years."

------
pixelcort
In iOS 6 there is a way to open your native app with the same content as the
current webpage.

[https://developer.apple.com/library/safari/#documentation/Ap...](https://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html)

~~~
gaborcselle
Yes you can, but that opens a different app and takes you away from Safari and
its browsing history.

------
signalsignal
I don't know how else to put this but local, compiled apps run faster than web
apps. And the problems laid out in the article are indicative of development
choices, for example not being able to pick up where one left off in a local
app as opposed to in a browser app in the NYT example.

~~~
gaborcselle
Running a compiled app instead of a web page, as laid out in the post, would
have that benefit.

The central theme of the post is that the local app and the webpage are
disconnected - the fact that you can't pick up where you left off in the other
is not a development choice.

~~~
awo
The analogy of native apps being an island is a good one. But I'd argue that
native apps is a pretty fucking big island ;) Check out this chart -
<http://www.emarketer.com/Mobile/Article.aspx?R=1009155>

People use apps on their phones, not the web. Mobile web is a subpar
experience. LTE will fix some of the speed issues. HTML5...well that's going
to take a lot longer than people think. Cool technology but ANY lag with a
gesture makes the touch interaction feel broken.

I've been thinking on this problem for the past 4 months. Seems like you're
pretty passionate about it too. It's a big problem for users, and companies
are sitting back and ignoring it. I have lots of theories as to why. Would
love to meet up in person and share thoughts.

------
pspeter3
I think it would be far more useful for Android Browser/Chrome and iOS Safari
to support special tags for rendering apps in their native style. Ideally have
it be the same set of tags and Android and iOS figure out how they want to
render them.

------
drivebyacct2
>My proposal would be to let mobile browsers download small apps and execute
them within the browser window

Is this a sick joke? Besides the fact that the browser can trivially redirect
to the exact app in the app store, I'm already annoyed that ABC wants me to
download their god damn app everytime I accidentally click on one of their
articles on Google News.

Not only that, but if the user has the app installed they're already prompted
to open the same content with the app instead of the browser if they want.

This problem is already solved. This is very, very common in Android apps and
I understand it is a new feature in iOS6 as well.

I guess if this is absolutely necessary, the browser could output a new header
for domains that are declared in the .ipa/.apk that would notify the server
that they have the app installed... and then they could force the app to open
with a regular redirect. But that still majorly SUCKS to users who already
have that choice anyway. If anything this gives the publisher more control of
forcing me to use their app which I absolutely do not want.

~~~
gaborcselle
Most publishers that have terrible apps also have terrible sites. Apps that
get very little usage today are hardly going to get better if users don't
start using them. Building an easier onramp for apps is going to increase app
usage and cause publishers to build better apps.

~~~
drivebyacct2
That's pretty much the opposite of what I want. And what they want regardless
of whether or not they know it.

Firefox OS is going to continue to open peoples' eyes to web apps and make
people wonder why they scrambled around wasting so much money to make native
news apps that do nothing but render a webkit view anyway. As another person
has pointed out, there are _very_ increasingly few things that webapps can't
do that native apps can, especially on mobile where they're unprivileged
anyway.

