
Why Mobile Apps Will Soon be Dead - Osiris
http://www.technologyreview.com/blog/mimssbits/26778
======
ChuckMcM
I think its a silly piece, and not really a cogent argument. The author claims
'mobile' apps will be supplanted by 'web' apps (presumably running in a
browser which is running on a mobile device). The reasoning breaks down into
three claims;

1) There are many more web users than there are mobile users (author claims 2
Billion vs 50 Million)

2) There are some browser apps (Angry birds and NY Times cited) which give you
'offline' access.

3)The HTML5 in the browser will become a unifying API to local functions which
will ease development.

So lets take these claims one by one and see how they hold up.

Market Size - ok there are a lot more web browsers than mobile users. And yet
if you look at growth rates (especially if you count 'tablets') the number of
users with 'mobile' capability is growing faster than pure web browser seats.
If you look at user capability the 'mobile' user may want to do things like
'check in' (location based) or navigate which the generic browser user doesn't
do. Finally if you consider the underlying UX tools its just as painful to
make an App which works well on 1920 x 1080 screen with mouse/keyboard as it
does on an 800 x 400 screen with just touch points.

Browser Apps with offline access - This moves the browser closer to hosting
the 'OS experience' of the device away from the underlying OS. Google would
love to do that since they would realize Sun Microsystem's dream of being able
to ship a browser which was the OS can cut out the OS provider (either
Microsoft or Apple in this case). However adding this layer not only impacts
performance, it also impacts compability since browsers with the same name and
version work differently from platform to platform. Not so with mobile apps.

HTML5 will develop access to native APIs - I read this, and I imagine all of
the zero day exploits that will come of it, if it comes to pass. You take two
engineering teams in two separate companies, one providing an OS API and the
other providing access to it, and you get Flash all over again. Both
development teams come from the problem from different directions and create
unexpected problems for the other.

Bottom line for me is that I'm not convinced the browser can kill anything
except other browsers. That being said, I also think there are big
opportunities in mobile / tablet device space for innovations in the operating
system, the UX frameworks, and the distribution mechanisms.

Disclaimer though is that I was one of the Java guys and I had completely
bought into the notion of 'write once, run anywhere'. Making that true turned
out to be impossible for a number of reasons, not the least of which that the
underlying OS providers were hostile to the idea. So creating an HTML5 uber-
alles experience for developing apps seems optimistic to me.

~~~
Teckla
"Disclaimer though is that I was one of the Java guys and I had completely
bought into the notion of 'write once, run anywhere'. Making that true turned
out to be impossible for a number of reasons, not the least of which that the
underlying OS providers were hostile to the idea."

The company I work for uses Java and targets Windows, AIX, HP-UX, AS/400, and
Linux. We have remarkably few portability problems with our Java code. It all
"just works", as advertised.

I'd be curious to know where all your Java portability problems stem from. The
UI (Swing)?

In any case, I do share some concern and skepticism that web apps will rule
the roost. At least one company, Microsoft, would seem motivated to make sure
web apps cannot completely replace desktop apps, and thus will always subtly
cripple IE, the dominant web browser.

~~~
ChuckMcM
So if you run a Java program, under the JRE-xx you will get the maximum
possible portability. I was the Director of Systems at FreeGate (an internet
Appliance company) and we decided to do our 'UI' in Java, in the browser.
(feeling it would give us wide reach) but at that time in particular (1996 -
2000) there was a lot of churn in the browser market and point releases of the
browser could change significant behaviors.

Today that is less of an issue as pretty much everyone has punted on supplying
their own version of Java for the browser and instead relying on the Snoracle
version. However the UI compatibility is tied up inside the support for CSS
and/or HTMLx where x is 4, 4.1, or 5 even.

Mobile apps for say Android which use their toolkit, and written in Java of
course, are reasonably compatible across Android devices. However challenges
with Honeycomb seem to have highlighted what happens when you change around
some base assumptions. Even the migration from Android 1.6 and 2.0 was fraught
with issues around new capabilities (and diverse capabilities) between
handsets.

Configuration Management is a Hard Problem (tm) on any system and people see
the Windows eco-system or the MacOS eco-system and feel like they should be
able to do that cross-platform. I agree that if that problem gets solved in a
meaningful way it will forever change the way we interact with our machines,
but I don't think browsers are the great hope for cross platform
compatibility.

~~~
MichaelEGR
@ChuckMcM - "Disclaimer though is that I was one of the Java guys and I had
completely bought into the notion of 'write once, run anywhere'. Making that
true turned out to be impossible for a number of reasons, not the least of
which that the underlying OS providers were hostile to the idea."

"Configuration Management is a Hard Problem (tm) on any system and people see
the Windows eco-system or the MacOS eco-system and feel like they should be
able to do that cross-platform."

\---

I'll just pipe in here real quick as cross-platform Java apps are core to the
open source / middleware product I'm releasing called TyphonRT this summer.
It's something I've personally worked on for many years well before Android's
emergence. Fragmentation is difficult to solve alone across the variety of OS
and device differentiation in the Android ecosystem without even considering
cross-platform compatibility with the J2SE.

TyphonRT is one such effort though and is built with a scalable configuration
system via a component architecture. Major engineering of the client SDK /
runtime will hopefully wrap up by the end of June with a closed beta for those
interested w/ public launch end of summer / Q3.

To support distribution across the Android ecosystem and desktop
configurations part of TyphonRT is a PaaS system such as when a TyphonRT app
is installed it will download any OS or device specific modifications /
alternate components to "patch" or provide a stable middleware layer in
attempt to keep that write once / run anywhere promise or get as close as
possible.

Of note I'll also be dumping over 10 years of solid Java real time app / game
dev knowledge too through an expanding tutorial series w/ lots of code
examples styled in a similar manner to Khan Academy.

<http://www.typhonrt.org/>

Ok not to hijack this thread, but the work I am doing as an indie / startup is
relevant to this discussion. This kind of solution with the current landscape
surrounding Java is only going to come from the open source / indie area.

~~~
ChuckMcM
Sounds kind of like Marimba on steroids. I like the notion of it running on
Android 1.6, if I could drive the price down for a 1.6 capable module to sub
$25-$35 I think I've got an enterprise use for it :-)

------
jasongullickson
_(think of the Newton, his first attempt to create an iPhone-like device)_

FWIW, Jobs didn't create the Newton, he killed it. You don't have to look to
hard to know this - <http://www.pencomputing.com/frames/newton_obituary.html>

As long as native apps have access to parts of the platform off-limits to web
apps there will be a place for them.

~~~
cageface
I agree, although I expect that will be a dwindling proportion of the apps
people actually use. All but a small handful of the things I used to do with
native apps on my laptop I now do with web apps.

~~~
jasongullickson
I agree to some extent (the interesting and innovative applications will tend
to be native, because they will be using the device in ways unanticipated by
the browser vendors). There is another angle to native apps that these
articles rarely mention and that is the "channel" created by the app store.

For example, many common applications I'm asked to develop for corporate
clients can easily be written as HTML5 web apps, and it makes sense to write
them this way for cross-platform reason, but all of the clients I've spoken
with decide to go the "PhoneGap" route because they want their app to appear
in the App Store because this is where there customers are going to be looking
for it.

There are plenty of practical reasons to host your web app off a wing of your
regular website (bypassing App Store approval being the big one) but so many
users have become accustom to getting their apps via the App Store that making
your app available in an App Store, even if it's HTML5 wrapped in a native-
code package, makes sense (at least for now).

Of course there is also the monitization issue, but I believe there are some
solutions to that already?

------
roc
It's always seemed to me that the shift away from native desktop apps had a
lot more to do with Windows headaches, rather than any inherent consumer
preference for web apps.

And for the average user, today's mobile platforms don't have much at all in
common with the Windows software life cycle [1]. So I'm not sure why it would
be in the users' interests to move to web apps. And thus I'm puzzled at why
people _expect_ it to spontaneously happen. Particularly when evidence seems
to suggest the exact opposite, people moving _toward_ native apps, on console-
like devices.

[1] finding, vetting, scanning, installing, using, moving to new machine,
syncing, fiddling, repairing, upgrading, cursing, uninstalling.

------
toddh
Without bindings to hosted mobile functions, like sensor access, etc. you are
just making a website. So that's an argument for why mobile apps won't go
away.

~~~
mcantelon
It seems just a matter of time before APIs for these become part of HTML5.

~~~
toddh
It's been quite a while. Apple started down that direction, but then the app
storm hit and that has been the end of that. And HTML revs much much slower
than any phone API, so the native experience will always be superior.

~~~
loire280
This is a key advantage of native code, but it is being eroded by the rapid
development of WebKit and Gecko. Browser makers are driving the environment
faster than we initially expected, with the tradeoff of potential
fragmentation.

------
dstein
Mobile apps will die off for the simple reason that it is too expensive for
businesses to create and support 6 mobile platforms in addition to their
websites. How many businesses are going to pay top dollar for an Android
developer to port their IOS app? Dollar for dollar they're better off adding
mobile capabilities to their website and support every platform.

------
ryannielsen
What's the interest in the "Web vs. Mobile App" fight? Both sides are
converging towards each other. Hell, look at Google itself – they're
sponsoring both Android and Chrome OS and both teams are adding features
"claimed" by the other.

Solve the problems faced by your users, using the technologies that best
amplify your expertise and meet their needs. Period. In the end, almost all
users won't give a damn whether they're using a web or native app – they just
want something that works well.

~~~
555imon
Fully agree. Question is on what distribution channel will be used for web
apps. Will it be in the browser or applications including a WebView? Users
seem to like/get used to the concept of stores as distribution channel for web
apps.

------
JofArnold
There's several billion radio listeners. And yet for some reason Amazon and
Apple have billions of MP3 downloads.

The article confuses the tech with the marketplace. Not the same thing.

------
king_jester
There are many apps that could be just as easily done with current web
technologies, so in a sense some of the mobile app space will die. Do I really
need a native app for every single website out there that already has a rich
web app? As more and more hardware features are exposed through the browser, I
think a lot of app programmers will move to web interfaces and technology.

That said, there are still several classes of apps that can use the resources
provided by native frameworks. Streaming media, high power games, and apps
that can be accessed quickly on the local device without network connections
all still have a place on the various mobile platforms. Like every new
platform, there is an artificially high demand for native apps from developers
and hiring companies, but that desire will subside eventually.

------
bartl
The reason why app developers will only reluctantly leave apps behind in favor
of web apps, is because of the money. It's very easy to moneytize apps, it
comes with the territory; but for web apps? People are used to "free" for web
apps, and no wishful thinking can change that.

~~~
bad_user
People get used to whatever you ask them for. I've got 5 active subscriptions
to online services, and barrier to entry is indeed higher, but that's only
because the competition is tougher (you can't really sell fart apps on the
web, but to me that's a feature) - just wait another 2 years and the iTunes
store will be filled with freemium.

------
davidw
Desktop apps aren't dead, but I sort of hope things trend this way. I had fun
playing with mobile stuff, but... I don't like the idea of rewriting
everything 2/3/4 times.

~~~
Hoff
This is the same sort of application churn that was underway before the bulk
of the PC market largely settled on MS-DOS and then on Windows, or the morass
that was the then-current and then-far-more-fragmented Unix market, which led
many vendors to support multiple then-current platforms. With the associated
costs.

Split your application into its core pieces (written in something reasonably
portable, and kept modular where you can) and partition the rest into the
platform-specific frameworks and calls, assuming that you can't find an analog
to what was once called a "4GL" that meets your requirements and your budget.

And from the last time that the third-party 4GL schemes and their sales-
critters were prowling the areas I was then working in, it was easy to end up
looking at Morton's fork choice. More than a few folks saw their "portable"
applications locked into the 4GL frameworks and its continued development
plans. Which wasn't a whole lot better than getting tied to the platform,
if/when the 4GL vaporized, or raised its rates, or otherwise became less
desirable.

All common-sense stuff, of course.

------
adrianN
Can someone explain to me why people think it is reasonable to try turning the
browser into a cross platform VM when we already have quite capable and
optimized cross platform VMs like Java and .Net/Mono?

~~~
bad_user
Both VMs you mention are too heavy and not real standards.

~~~
daeken
The Java world is "standardized" (de facto, since it's not a "real" standards
board, but still) by the Java Community Process. For .NET, you have ECMA-335
specifying the CLR and ECMA-334 specifying the C# language itself; standards
by an internationally recognized body.

As for too heavy, I think that's a pretty silly argument, especially
considering that Java runs on everything from phones (there's J2ME and
Blackberry, plus Android's Dalvik is just an alternative way to look at Java
-- register-based rather than stack-based, which speeds up interpretation
considerably) to big iron, and .NET runs on everything from microcontrollers
(I have a Netduino board sitting next to me) to the 360 to desktops to phones
to servers. Heaviness comes from use cases, not intrinsic properties.

~~~
bad_user

         Heaviness comes from use cases, not intrinsic 
         properties.
    

Use cases are precisely the reason Javascript is better for the web. And the
current web standards broken as they are, are real standard as in nobody owns
them and everybody can improve on top. That's the reason you aren't stuck with
IExplorer 6.

    
    
         The Java world is "standardized" (de facto, since 
         it's not a "real" standards board, but still)
    

Windows is a de facto standard too. A standard is meaningless when Oracle
threatens with patents the development of alternative implementations. A
supposedly standards body is meaningless when the voices and votes of members
can't do shit (until Apache Harmony gets access to the TCK, the JCP is
basically a lie).

    
    
         .NET, you have ECMA-335 specifying the CLR and 
         ECMA-334 specifying the C# language itself;
    

It's not really .NET, but rather the CLR + C# 2.0.

Silverlight, the new stuff from C# 3.0 and onward (Linq, dynamic), haven't
been added to ECMA yet and there is no deadline (C# 3.0 released in 2007, 4
years ago). Even the W3C moves faster lately and I'm not holding my breath
that Microsoft will ever add anything else to those 2 standards.

    
    
         Java runs on everything from phones ...
    

J2ME is a piece of shit. Android Dalvik is not Java - unless you can also say
that .NET is Java (checkout IKVM).

Java SE is good for server-side and an all-around good VM, but getting
anything usable done for desktop consumers is a frustrating experience at
best.

------
yalogin
This is exactly why I thought PalmOS had the best app model of all the
platforms. Was very surprised to see at the Palm developer event when most of
the devs complained about the JS app model.

~~~
orangecat
_Was very surprised to see at the Palm developer event when most of the devs
complained about the JS app model._

I'm not. HTML was fundamentally designed to display static documents. After
years of hacks, we've managed to turn it into a somewhat usable application
framework, but there's always going to be an impedance mismatch compared to
APIs designed for apps from the beginning.

~~~
swix
This, this is so true. It's a pity, it's like we have come this far with HTML5
and all, but we just can't get the last 100 miles, where.. a webapp can do at
the same speed what a native app can.

I'm afraid we wont ever get there, not with current implementations / DOM /
js, whatever. Which makes me sad.

------
swix
I highly dislike the fact that native is still more awesome than webapps. It's
just not quite there, canvas is slow, webgl is slow to its native
counterparts. I mean come on when will this change? Will it ever? Until that
day it just feels "meh" to develop "cool" webapps. :(

//Disgruntled js developer

------
joejohnson
Markup and javascript are simply too slow to generate crisp, engaging user
interfaces. To do that, you need a plugin, which is a)not portable and b) not
functionally different from an iOS or Android app.

Can you load a web app and its attendant plugins from any old web site? Sure.
But by the time you figure out how to monetize the app via some clearinghouse,
you've pretty much got the equivalent of an app store, albeit without the
clean search and publication tools available to such a store.

The bottom line, though, is that the idea of totally portable, script- and
markup-driven apps has been a complete failure so far, and is unlikely to
change much in the future. Hard coded apps--albeit with increasingly
sophisticated porting and distribution tools--are here to stay.

~~~
doublerebel
The slowness is not in the JS and markup itself, but because in the past the
rendering engines (browsers) didn't know how to interpret most of the JS calls
as defined UI changes. With requestAnimationFrame, CSS animations, and WebGL
this is changing -- Browsers are now being told directly which code is UI-
specific, so it can be accelerated with hardware and the timing can be
synchronized.

Translating JS into these more 'native' UI calls across multiple devices and
software stacks is already shown as profitable with tools like Appcelerator
(iOS, Android, BB, Desktop) and PhoneGap -- which appear native to the average
user.

Also don't forget that internally the Mozilla suite and many other desktop
'native' apps are built largely with JavaScript, not to mention Palm's WebOS.

JS itself is very fast and creating fluid UIs was always possible with a
native wrapper (or plugin, as you mention) but now that the tech is making its
way into the average browser we will be seeing more and more 'crisp'
interfaces on 'average' websites. 'Hard coded' apps will always have their
place, but look out: many portable, JS-driven apps are very successful, and
are already changing the future. Many people who just think of JS as browser
script are being left behind.

------
adaml_623
So really they are describing Mobile Apps that run on the browser rather than
directly on the OS.

The more things change the more they stay the same.

------
k7d
This reminds me "Shortchanging Your Business with User-Hostile Platforms"
<http://news.ycombinator.com/item?id=2108294>

It's about drawbacks of using Adobe AIR as kind of a cross-platform shortcut
for building apps. From such perspective HTML is really not that different. If
you want to deliver the best possible user experience, native apps is the only
option in a lot of cases.

In a way that is good news for developers since it creates niches.

------
MarkMc
The Roman empire analogy is upside down - the 'web apps' are the Romans, and
the 'native apps' are the Visigoths. Three years ago the momentum was with web
apps - nobody was developing new 'native' apps. That has all changed.

Even websites whose content is perfect for a browser (eg. newspaper and
magazine websites, real-estate listings, train timetables, etc) are producing
native app versions of their product. How does the author explain that?

------
haseman
I think I've read this exact article dozens of times since almost since I
began writing mobile applications in 2003. The message is always the same 'Web
Apps are Coming! They're going to take over! Steve Jobs thought so!'

In reality, we'll probably see something that's half-way between a web-app and
a mobile app. In the meantime, can we stop predicting the doom of mobile
software and get on with fixing what's broken about it?

------
checker
Why is it one or the other? Can't they just be different views for the same
model (assuming the app doesn't need access to lower-level functionality)?

------
kin
i'm pretty sure you can't replace something graphically intensive as Unreal's
Infinity Blade with a cross-mobile-browser web app.

~~~
czhiddy
I think the proponents of web apps only consider the twitter/facebook/etc type
of apps in these arguments. If the types of game you're interested in are
relatively simple affairs (Angry Birds/Cut the Rope/etc), sure, you could
probably make it performant with HTML5. Good luck doing anything more complex
(Unreal, PhotoSynth, GarageBand, etc) with javascript without at least 3-4
generations of hardware improvement.

------
ignifero
Amen to that. I wonder how long we have to wait for the w3c to create APIs for
all sorts of device capabilities, like camera, compass etc. Open standards
FTW.

~~~
peter123
The standards for access to device capabilities are already defined. Just
waiting for platforms/browsers to adopt them.

------
DrCatbox
I remember 20 years ago when File > Save page as... > html archive would make
me a very nice web app on the fly.

App is the latest craze that has replaced the cloud, suddenly even the direct
opposite of an app, the web, becomes an app. Strange. Didnt people know that
you could save a web page and access it when you are offline before starting
to call it a web app?

