
Why apps are not the future - davewiner
http://scripting.com/stories/2011/12/13/whyAppsAreNotTheFuture.html
======
davesims
Linking is one of the things that I think Android got right over iOS. Google
-- web company that they are -- smartly realized that their mobile OS platform
needed to borrow metaphors from the web and attempted to do this with their
Intent/Activity architecture.

The challenge here is the execution -- it's Java-heavy and unwieldy compared
to <a href=...>, but the basic structure is there and allows for interesting
interleaving of Activities from one app into another. I haven't yet seen a lot
of discussion or adoption of Open Intents, but I think it's an interesting
approach. It does, again, seem to suffer from an inheritance of Java's
heaviness, and that may be a fatal flaw.

<http://www.openintents.org/en/intentstable>

Whether this approach succeeds in sustaining rich-client apps as web apps
mature remains to be seen, but I do think it points to the fact that OP's
criticism was a concern in the minds of Android's developers at the earliest
stages.

~~~
zuppy
You can link apps in iOS too. You can do a simple test: open safari and type
fb://feed and it will open the facebook app and go to your wall.

More:
[http://wiki.akosma.com/IPhone_URL_Schemes#Registering_your_o...](http://wiki.akosma.com/IPhone_URL_Schemes#Registering_your_own_URL_schemes)

~~~
spiffworks
How does iOS handle multiple apps registering for the same type of URL? In
Android, I get a popup asking which app I want to use for this action, and an
option to make that the default for future actions. Is there something similar
on iOS?

~~~
SoftwareMaven
You get a popup asking which app to use. I don't think there is a "save as
default" because that would necessitate a way to manage those defaults, which
would expose the underlying mechanism to users, something Apple is generally
averse to doing.

The reality is that it doesn't get used a whole lot. Browsers, Dropbox, and
other apps of that nature tend to provide the data while miscellaneous apps
consume it.

------
mekoka
I believe native and browser-based apps can and will coexist.

As a web developer, I've had my share of frustrations with the browser and I
certainly would welcome a more flexible and feature rich alternative for some
use cases.

To give an example, I can see native development overturn browser dominance in
the manufacturing of Content Management Systems. For years these apps have
been tied to browser technology and their usability and features have been
limited because of it. Sure it makes them easy to deploy (all you need is a
browser), but in exchange you get crappy wysiwygs, lack of remote access (ftp,
ssh), image editing that sucks and a string of other annoyances that we've
simply learn to accept out of convention.

But when you think of it, there's no reason it should be like this.
Organizations typically only have a handful of people that require access to
the admin panel. You could simply have them install a native client that
communicates with the server via http, exactly like the browser does, but
offers a much more elaborate API. The added bonus would be the possibility to
easily delegate various other tasks to other tools (Unix style).

Other normal web users (consumers) can continue to access the frontend (as
opposed to the admin panel) via browsers.

This is a future I can definitely embrace.

~~~
bad_user
I'm not sure I agree. Since I discovered Google Apps, I forgot about Microsoft
Office.

Google Docs is always there. It may be a crappy experience on my Android, but
I have access to content I wouldn't otherwise. Collaborative editing and
sharing is really easy too - I don't have to ask other people to buy iPhones /
iPads / Androids to get them up to task. They only have to have an email on
which I send an invite. And sure you can make a better native app and I would
appreciate one on my Android, however I remember how this one time I forgot my
phone and borrowed the iPhone of a friend to access a really important
document.

On the whole, web apps are more accessible. Native apps are a nice bonus to
this experience, however if the core is not web-based, then it loses a lot of
value.

~~~
dextorious
"""On the whole, web apps are more accessible. Native apps are a nice bonus to
this experience, however if the core is not web-based, then it loses a lot of
value."""

Well, that can be easily solved with native apps that also have a web
counterpart, for desperate times (i.e in the middle of Tahiti without your
laptop/mobile phone/tablet).

------
clintavo
We keep having the same debates over and over. We've seen this before on the
desktop. It started with apps that had to be written for both Windows and Mac.
Then the web came along and, as bandwidth increased, many apps were able to be
run as web apps, simplifying code maintenance and giving developers the
ability to easily target multiple platforms. Apps that benefit from linking
work better as web apps. Some types of apps, however, run better as native
apps: things like games and Photoshop. So we ended up with both.

Mobile will follow the same track: we'll end up with both.

~~~
wvenable
The reason why this conversation is coming up again is that so many
applications that are web applications on the desktop are more commonly
accessed as native apps on mobile. For example, on iOS I use a native client
for IMDB, my bank, Mint, Wikipedia, and so on. But on the desktop I use web
sites for these services. There has been a shift _back_ to native on mobile.

I agree that we'll end up with both but perhaps more importantly is that the
difference between web and mobile will blur together even more.

~~~
politician
I think the real reason that you see apps on mobile devices is that an app
puts an easy to use branded icon on the "desktop" instead of requiring the
user to open a browser and navigate to the site. I don't think it has anything
to do with lack of access to capabilities (e.g. Mint doesn't need access to my
camera).

Try this thought experiment: What do you think would be the reaction from
users and developers if Apple simply renamed Safari's "Add link to home
screen" option to "Install App"?

~~~
wvenable
I never said anything about "lack of access to capabilities". Native
applications, in the vast majority of cases, are just better in every way than
the similar web versions. They're faster, cleaner, and more capable. If both
are being offered, it makes no sense to choose the web version.

My company makes an iOS-compatible web application with no plans for a native
client right now. We use some JavaScript[1] to remind users to add us to their
homescreen. But if we had the resources, we would build a native client --
it's a no brainer.

[1] <http://cubiq.org/add-to-home-screen>

------
roc
Webapps need to better handle offline usage and poor network conditions. Until
then, apps still have a huge leg up on mobile devices.

Mobile devices are battery constrained. Radios to provide data feeds are a big
factor in battery drain. Interpreted languages increase battery drain. And
network coverage is far from universal, to say nothing of download caps and
cell network performance concerns.

Apps are preferred today because they're more responsive, they drain less
power and they're generally usable offline and in dodgy network conditions.
The web has many advantages over native applications, but until it gets better
for mobile users, users are not going to get past the more-immediate
shortcomings to care much about those advantages.

And given that we seem to have reached a point where potential battery life
past 1 day of solid use is traded off for greater performance during
operation, I don't see the battery/network situation changing much any time
soon.

~~~
zerostar07
By the same argument, though, apps will be obsoleted as soon as the next
battery technology arrives, because, let's face it, installing apps, updating
and uninstalling is a ghost long dead. As soon as Apis to access camera,
microphone etc come to the browser, who would choose to program native?

~~~
bulte-rs
> installing apps, updating and uninstalling is a ghost long dead.

So, when not installing native apps (which takes time) we add - in the case of
e.g. the iphone - webapps (links) to our home screens. Which is faster than
installing a native app. After that we 'endure' a longer loading time every
time we start the app. And we still have to remove the icon from our home
screen when we're done with it.

Mind you, I see the advantages of web apps; but this does not seem like any
different from the native app use case; it seems a bit worse to me actually.

> who would choose to program native Performance junkies? graphically
> intensive app-developers (games?). Sure, we may have an 'opengl'-component
> to use in our webapps; but why the extra overhead?

~~~
zerostar07
Web app icons don't make sense as you 'd soon end up with thousands of them. I
imagine future phones will just have a voice-recognition-enabled search box
instead of icon grids.

~~~
bulte-rs
The same could be said about native apps. There are more than enough apps in
the various app stores to fill numerous 'springboard screens'. On the other
side we only use a small set of apps. Why would habits change when switching
from native to web-based when the experience is the same?

------
dwiel
I agree with the sentiment of the op, however, I dont think you can ignore the
fact that so many people are willing to spend a dollar or two on an app
whereas paying for access to a web site seems relatively rare (outside of the
business world).

~~~
toyg
Show me a (useful) website that costs less than $5 for lifetime access.

Many SAAS companies charge the same as an app, but _per month_ , so you can't
really compare it with a one-off payment.

~~~
rgbrgb
<http://www.google.com/>

~~~
toyg
I don't understand whether you're trolling or not. Google doesn't make you pay
for access, last I checked.

~~~
rgbrgb
>>> Show me a (useful) website that costs less than $5 for lifetime access.

The business model is often completely different for the web. We pay with our
eyeballs (ads) and our thoughts (click data).

~~~
scrod
Nice. So that pretty much guarantees that only those SAAS apps that are
operated by the largest corporations, and that harvest your personal data most
efficiently, are the ones that dominate. Everything else is only that much
more likely to disappear in an instant, taking with it not only all your
documents, but the app's functionality itself as well. I really don't know
what people like you are smoking.

~~~
rgbrgb
I only smoke weed. But yes, outside of fairly niche markets, the largest
corporations are dominating (Amazon AWS, Google Docs). It IS a lot more likely
that any of these alternatives ([http://www.makeuseof.com/tag/5-great-
alternatives-to-google-...](http://www.makeuseof.com/tag/5-great-alternatives-
to-google-docs-you-should-consider/)) will disappear with all your data than
that Google Docs will. I'm not saying it's some awesome thing that big
businesses can out price the little guys and I'm not saying that the
profitable SAAS does not exist (Harvest, Github (most of Github's users don't
pay a dime)). The simple reality is that most people get a fair amount of
utility from free web services.

------
king_magic
_"Visualize each of the apps they want you to use on your iPad or iPhone as a
silo. A tall vertical building. It might feel very large on the inside, but
nothing goes in or out that isn't well-controlled by the people who created
the app. That sucks!

The great thing about the web is linking."_

I'm not convinced. I see the "app" response to "linking" as being something
like Windows 8 contracts. In fact, I wouldn't be surprised if iOS and Android
have something similar to contracts in the next 2-3 years. At least I would
hope so!

I think that there are applications that make more sense to implement as a
traditional app, and that there are applications that make more sense to
implement as a web app. I don't see this changing anytime soon. I really
don't.

~~~
AndrewDucker
Well, Android has "Intents", which allow similar functionality, although not
as much as "Contracts" if I understand correctly.

~~~
king_magic
I was actually not familiar with Intents. Good to know.

------
jgroome
I don't think anyone outside of the app-development ecosphere seriously thinks
that the Web is dead. It's a pretty absurd thing to say.

~~~
randomdata
As a web developer, I think it is dying, but not in the way you immediately
think.

Modern websites are starting to resemble full-fledged applications. Built
using entire MVC frameworks atop the Javascript runtime that abstract the
underlying primitives, just like their native brethren. Today, from a
programmer's standpoint, there is little difference between building a native
and web application.

Every new browser iteration just brings tighter integration into the
underlying system. There are no real web-specific technologies being
introduced. We are reaching the point where the web serves little purpose
other than a clumsy virtual machine. The natural progression will be to go
full on virtual machine, like Java attempted to do many years ago, where
HTML/CSS/etc is just another application on that virtual machine.

The idea of pointing a browser to an address to open an application will stick
around, but I think the web parts, a program that renders interlinking
hypertext documents, is dying – though certainly not dead yet.

~~~
bad_user
In the meantime Wikipedia is still the most useful product of the Internet and
the biggest database of human knowledge. It's only surpassed in traffic by
Google, Facebook, Youtube and Yahoo.

    
    
        the web serves little purpose other than a 
        clumsy virtual machine
    

That clumsy virtual machine can bring you Facebook.com on every mobile phone,
regardless of the platform. And if good native apps are now available for
Facebook, well, we are talking about Facebook.

~~~
dextorious
"""In the meantime Wikipedia is still the most useful product of the
Internet"""

You missed the point.

There's nothing Wikipedia does that cannot be done in an native-gui mobile
App.

It's just a list of articles, a way to search for them, and a system to edit
them. Nothing web particular about Wikipedia, one can imagine a Wikipedia app
for mobile and desktop OSs that achieves the exact same thing.

~~~
jgroome
But surely the success and therefore usefulness of Wikipedia is down to the
fact that it's available to everyone with a web browser? Apps are only ever
going to have a tiny proportion of the target market, compared to the number
of general web users out there.

That's what this is about. Of course you can do the same functionality that's
made Wikipedia work in an app, but I don't think you'd ever get the numbers
needed to make it useful.

~~~
dextorious
"""But surely the success and therefore usefulness of Wikipedia is down to the
fact that it's available to everyone with a web browser? """

It's success when it was created, and maybe now, yes.

But how about a future where everything has a mobile phone and/or tablet, but
fewer have or care to use a web browser?

~~~
bad_user
Normal people never cared about web browsers, but that didn't stop web
browsers from spreading like a virus. Most of them don't even understand the
concept. If you ask them what a browser is, they'll probably answer Google.

As an example, I love my e-Ink Kindle. The one big annoyance I have is that
the browser on it is so awful that it is unusable. And it bothers me because
book authors are often placing links to external references in the books I
read.

And I just want to read those references. Maybe add a comment or two if it's a
blog. Since I'm there anyway, maybe I want to recommend the book on Facebook
or Twitter with, you guessed it, a link. Maybe I want to search on the web for
other discussions on the topic. And so on and so forth.

It's not about love for the web browser per se. The browser is an awful
virtual machine. Also the HTTP protocol is one of the featureless protocols in
existence. The development model is scary sometimes as you've got to learn
dozens of technologies, each specialized for a certain task, each broken in
its own special way.

But developers bitching about this are missing the point. It turns out that
the openness of the web is disruptive and simple form elements communicating
over a simple protocol is all you ever need for 80% of the use-cases.

Quite the contrary, I'm seeing the web stronger than ever before. The one big
problem I'm seeing however are walled gardens. Some day from now we'll look
back and actually see what a big mistake this was. But the web as we know it
will still be there. Because nothing can really replace it.

------
mrich
You gotta love IT.

On Windows there was perfect integration between apps after Microsoft added
linking and embedding using COM/OLE. 2D/3D hardware acceleration was standard.
Linux as a competing OS implemented most of this also. Then came the web, and
after years of standardization we now have hardware accelerated 2D & 3D, near-
native performance (albeit using a completely new toolchain) and most of the
standard desktop things. We have gained platform independence and ubiquity.
Now we have to reinvent everything on mobile devices.... Granted, most of it
is already there. But I sure would love to see most new mobile apps
implemented in HTML5, to make them work cross device as much as possible.

~~~
dextorious
I wouldn't call COM/OLE "perfect integration between apps" at all.

And no, "2D/3D hardware acceleration" was not standard for the majority of
Windows applications out there, including the Windows desktop.

~~~
davesims
"I wouldn't call COM/OLE "perfect integration between apps" at all."

Oh come on, it was so simple! All you had to do was set up a ProgID and/or a
GUID in the registry (no! not HKEY_LOCAL_MACHINE, silly!, HKEY_USER! Oh wait,
you're right, it is HKLM...) and then implement IUnknown in your app and the
register the interface when you installed your app...hopefully with Windows
Installer, which makes all of this a simple 15-step process. There's only
like, 25 different registry keys to keep track of and 12 layers of interfaces
to implement.

It was perfect I tell you!

------
IanDrake
I think we've lost focus here. Web pages as apps are silly, but there are just
things you can't do from a web page on a mobile phone, like interface with the
camera, GPS, compass, local caching, etc... That's where apps come in (or
should).

~~~
politician
PhoneGap exposes those features to JavaScript through Device APIs.

~~~
Spearchucker
Lol, was about to mention PhoneGap.

------
marknutter
I can think of more reasons:

\- app discoverability sucks ass

\- apps require updates

\- app development is unnecessarily tedious and must be done x number of times
for x platforms

\- iOS apps need to be approved by Apple, and you have to play the game by
their rules if you want to charge money for them

\- apps lack basic features of browsers - no universal find, no back/forward
buttons, no bookmarking of pages or states, no organizing apps into tabs, etc.

Let's be honest: not counting games, the vast majority of the native apps out
there would work just fine (or better) as websites. Add API's like access to
the camera and there's even less reasons to develop a native app.

Apps will be relegated to games and highly sophisticated interfaces, which if
I had to guess probably represents around 10% of all the apps out there (heck,
most of the games out there could probably be done in the browser).

------
babarock
Linking is really the only feature I care about in the web. And it's not a
negligible one. I'm tired of all the Flash animations, the AJAX updates or
other fade-ins and shiny effects. It looks pretty, but I'm not connecting to a
website to watch a fashion show, I'm really here for the content.

I wish we could go back to a more "HTML-only" oriented web. You still find
some of those (usually with old Unix hackers or computer scientist) and
they're amazingly enjoyable to read. Also, parsing them and running
grep/sed/awk/... is a breeze. Am I crazy to ask for data I can manipulate
easily?

------
thetrendycyborg
You _can_ link with apps. Intents do this.

[http://developer.android.com/reference/android/content/Inten...](http://developer.android.com/reference/android/content/Intent.html)

~~~
k-mcgrady
To an extent you can do this on iOS as well with URL schemes.

------
djKianoosh
I think one potential answer to this is the ability for mobile/tablet apps to
embed a browser inside the app. So you see this already with the twitter app
on the ipad, when you click a link, it opens a browser in-app. The app makers
don't reaaaally want you to leave, so the in-app browser is a nice compromise
for them. And as a user, I like it. I don't necessarily need/want to leave the
twitter app on my ipad. I just want to read the linked content real quick and
jump back to the app. Works for me :)

~~~
hack_edu
Unfortunately, the browser experience can vary drastically depending on the
app linking out. Plenty just dont at all. You see a link, but clicking doesn't
do much but let you copy the text, if you're lucky to even have that. It's
frustrating and makes me tend to avoid links in most all apps.

Take Flipboard, and otherwise beautiful app that is the gold standard for
future blockbuster apps; when you decide to open a link to a full article you
will get stuck inside an awkward hardy-useful piece of Safari. Even if you
click out, you efffectively lose your place in the flow of what you were
browsing. This is an example of bad integration from the browser. Don't even
get me started on the apps that come with built-in browsers that feel like a
toynrather than a tool.

I want to read the linked content _not necessarily_ real quick and return
back, and trust that the experience will be as good as a native app. In a
perfect world all Apps would be web apps.

------
richardburton
Why does it have to be binary? Why does one school of thought have to lose in
order for another to win?

------
DrJokepu
Regardless whether the author is right or wrong, "I don't care" is not a valid
way to dismiss a counterargument. It's an effective way to resolve cognitive
dissonance however.

------
Tichy
Another thing I recently realized: if the trend is to store everything in the
cloud. How long until we also store apps in the cloud? Oops, they are now web
sites...

~~~
tikhonj
Not just _any_ websites, but websites locked down by Apple/Microsoft/whomever
_for your own good_!

------
taylorbuley
Deep linking is perfectly possible in apps. The !# hasbang is ugly, yes, but
the HTML5 History API corrects this with the ability to pushState,
replaceState and popState without necessarily having to deal with hashes.

Moreover, this style of linking matters most with publicly available data. For
private data, such as the stuff I'm working on storing in the browser with
IndexedDB, having a public link isn't necessary for data that's not publicly
available. I of course want to support browser history/links in full (see
<http://warpspire.com/experiments/history-api/> for an example of what's
possible) but my point is that when apps are personalized there is not always
a need for a link that can be shared across the web.

If I wanted to prognosticate about our web-based future I'd look beyond
vanilla hyperlinking and at Web Intents instead.

------
billions
Apps are shaping into Native, Hybrid, and HTML5. Native will always own a) 3D
& graphics, and b) frequent users. HTML5 is in the immediate future shaping to
be a 'try before you download' the app. It will be dominant in one time use
(web) apps. I am working on an HTML5 marketplace- PM me if you're curious

------
jollyjerry
A friend brought up a good point the other day that the popularity of the iOS
app store has actually pushed back on advances in web technologies on mobile
devices. Because the sanctioned way to sell applications must go through
Apple, less attention overall has been spent building mobile webapps. Also,
since the hardware is also out of developer's control, there hasn't been a
push to make native hardware available to the javascript.

Even with that, I do think that we're on the cusp of a big webapp revolution
(again). With all these emerging JS frameworks (backbone, ember, derby,
knockout, etc), and the modern and capable webkit powering so many mobile
devices, developers will take note.

------
namank
You know the people who make phone software are actually aware of this?

In Android, the concept of Activity and Intent serves to essentially promote
this. Its not a solved problem by far, but work HAS been done in that
direction. Rest assured, this work is only going to speed up from here.

After all, smartphones and tablets are marketed as consumption devices. The
manufacturers would be hugely remiss if they didn't learn anything from the
internet. And as we know, Steve Jobs and his industry descendants are anything
but remiss.

This is not to say the OP are wrong. Web doesn't compete with apps, it
supports them. The two are complementary paradigms, not competing.

------
tgrass
It is easy for me to imagine a world that moves from the messy chaos of the
web to the clean, self-contained, predictability of the app, and linking would
be a mere ancillary concern.

Apps are the path of least resistance for the consumer.

------
solipsist
Has it ever occurred to you that the next generation technology might harness
the advantages of both apps and the web?

That's the way innovation occurs. Incremental improvements. Referring back to
past implementations. Standing on the shoulders of giants. Learning from both
the good and the bad of technology.

When people bring up the debate of Apps vs. Web, it's equivalent to saying "
_Facebook vs. Google+ - which one will people use in the future? You either
get the Facebook like button or Google circles. One or the other, but not
both_."

~~~
gambler
How exactly will it happen?

------
tcarnell
Yep, completely agree with the article. For me an important difference between
the 'web' and 'apps' is that generally speaking nobody builds mobile apps out
of generosity or egalitarianism, ie to give something to the world for free -
mobile app developers are in it for the money.

However, the openness and non-proprietary nature of the web seems to encourage
people to be generous and share content and services.

How many open source mobile apps are there compared to really great open
source web/pc software?

------
iradik
Apps allow content provides to hide their data and only share it in a highly
controlled environment. It's very unweb like, but appears that controlling a
scare resource is profitable.

------
Havoc
>It pleases the money folk to think [...] That users are happy to live in a
highly regulated, Disneyfied app space, without all that messy freedom.

Sadly I think those folks are right. Shiny things do appeal to average people
above freedom, flexibility etc. Given enough people with both money and an
interest in shiny things, apps will rule supreme.

~~~
dextorious
It's not like the flexibility to export you data in some format or the freedom
to modify the code means anything to people --or like it _should_ mean.

How about the freedom from baby-sitting your OS install and the flexibility to
just use a nice, polished app and go on with your REAL work?

------
mufumbo
The web will prevail. It's just question of time.

Just be smart and make profit with the app fever while you can.

------
MatthewPhillips
Linking is nice but the real killer feature is that installing, updating, and
opening a website happen at the same time. Apple, Google, and Microsoft can
build their own linking mechanism, but I have to preinstall the app before the
link will work.

~~~
Someone
Fixing that is not too hard. If you look at Mac OS X Lion, for instance, part
of that already is in place (in a different domain). If you download a .xyz
file and double-click it, the Finder will suggest looking for applications
that can open .xyz files.

I think a logical extension would be that the system would automatically
download free viewer apps instead. Add a seamless way to upgrade to the editor
app, and you are all set (tangentially related: I think a thing like OpenDoc
using that infrastructure could succeed in today's market)

~~~
MatthewPhillips
Could they download and install these viewer apps in a fraction of a second or
two, because thats what a browser does. The web works on the basis of
progressive enhancement so all the browser needs to fetch is one Html file
which it can display to the user while it downloads all other resources. I
don't see a native code matching that.

~~~
Someone
_"all the browser needs to fetch is one Html file which it can display to the
user while it downloads all other resources."_

If only. There are pages where that is possible, but typically, at the very
least, browsers need to download some css, too (for example, google.com, on my
system, does 9 http requests of which one fails). Even with inline css, a
browser can discover, halfway through a file, that some css moves a div up
top, floats it, etc.

Add to that 'not everybody' specifies image dimensions in the HTML and that
Javascript that runs on page load may do DOM updates, and you get a much more
complex model. Deciding when to start rendering a page is somewhat of a black
art. If you wait until you are sure you have all information you need, the
browser will appear slow; if you do not, you will have to restart page layout
sometimes.

 _"in a fraction of a second or two"_

Pages that load at that speed are rare. Again taking google.com as example, it
loads almost 200kB here (most of it from cache, but that would not be much
different in what I envision). When running from cache, rendering that simple
page takes about half a second, I guess (FireBug reports 700ms and up, but it
will have some overhead)

------
sreitshamer
He means iOS apps, not desktop apps, right? Desktop apps aren't "silos". The
PC/Mac is a personal systems-integration device with mechanisms like
pasteboards to transfer data between apps. Unfortunately iOS (so far) has very
little of this.

------
thespace
Very basic but there is a way in iOS

[http://iphonedevelopertips.com/cocoa/launching-your-own-
appl...](http://iphonedevelopertips.com/cocoa/launching-your-own-application-
via-a-custom-url-scheme.html)

------
scrrr
I think apps are here to stay, but just like in the Chrome browser they might
be simply links to a web-app. So the title should read "Why native apps are
not the future".

------
zeeed
that's all well and good. the key is that you can sell an app easily given a
unified interface. that beats everything that is being done on the web, hands
down.

We have to understand that apps make money and that this is why people will
have people write more apps, which will fuel the economy and (us)
entrepreneurs. That someone will switch off the web at some point is somewhat
unlikely and when the time comes, probably secondary.

------
charlieok
The URI (or now more correctly, IRI) is a Web concept that is just as
applicable in native apps as it is in HTML/Javascript apps. Use it.

------
perfunctory
> Why apps are not the future

They are not the future indeed. They are the present.

