Why Mobile Apps Will Soon be Dead
technologyreview.com
technologyreview.com
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.
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.
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.
"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.
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.
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
Internet Explorer (43.2%)
Mozilla Firefox (28.6%)
Google Chrome (14.6%)
Safari (6.3%)
Opera (2.6%)
Mobile browsers (4.7%)Google is going in an interesting direction with Native Client, Pepper, Go-lang and ChromeOS. I remember them (might have been Brin) saying web and desktop will merge and looking at Native Client, the capabilities should merge as well.
Mozilla has their own simplified systems programming language, Rust. They're cooperating on with Google on Pepper so far. In theory browsers could just become agreed upon APIs between operating systems instead of the markup/VM legacy mess they are now.
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.
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?
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.
A huge strength of iOS is that most iPhone apps look and behave like most other iPhone apps, and that's because of the coherency provided by the UI framework and HIG. Asking developers to write their own CSS styling for widgets would result in a much more fragmented experience from app to app, which would detract from the platform as a whole (on top of a whole other slew of tiny UI touches added to UIKit, like the surprising complexity of the view-to-view transitions in CoreAnimation, that would be lost on 99% of app developers if asked to develop their own animations).
One of the most interesting things Apple is working on that everybody seems to ignore is iAd Producer. They've basically created a full-fledged HTML5 app-building tool that recreates a large part of UIKit in JavaScript, but it's currently only good for iAd development. I'd love to see what would happen if they would let developers release apps built with the tool.
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.
The article confuses the tech with the marketplace. Not the same thing.
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.
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.
Basically what happened is Windows sucked and the public figured this out over time. So consumers switched to a new OS called "Internet Explorer" which sucks in a lot of ways but at least it doesn't break their computer while costing them a fortune.
"Internet Explorer" also came with a really good online app store, and most of the apps were free to boot. You could just click a "link" and the app would automatically download and run. Hands down a better operating system than Windows.
2. Reduced learning curve. Everyone is comfortable with web pages.
Compare to the VMs you mention. The JVM failed at #1 despite years' head start and doesn't even try to address #2. A better example is Flash, which threaded the deployment needle amazingly well but still ran aground on the remaining barriers.
Mobile is different, though.
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.
Heaviness comes from use cases, not intrinsic
properties.
The Java world is "standardized" (de facto, since
it's not a "real" standards board, but still)
.NET, you have ECMA-335 specifying the CLR and
ECMA-334 specifying the C# language itself;
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 ...
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.
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.
I'm afraid we wont ever get there, not with current implementations / DOM / js, whatever. Which makes me sad.
//Disgruntled js developer
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.
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.
The last 30 years have shown us computing oscillates between thin clients and heavy clients. I have no reason to believe that will change; we just don't know what the next catalyst will be.
I firmly believe it is not Google's web app marketplace (insert joke about app store trademark here ;).
The more things change the more they stay the same.
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.
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?
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?
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?