Now that I’ve had a few weeks to play with my Nexus One, I’m starting to grok the gut-level experience of living with a smart phone. I understand why people download apps, how it feels to have the Internet with me everywhere, and what it’s like to experience the web by touch on a screen that’s only a few centimetres square.
Past
Device-specific apps are sweet and shiny at first, but after a couple of weeks, it becomes obvious that many of them are the encore of the floppy-based PC shareware world of the 1980s and early 1990s (SEND $5 TO GET RID OF THE ANNOYING ADS! ONLY $10 FOR THE FULL VERSION!).
Discovering an interesting app through Apple’s or Android’s market (or taking a picture of a barcode on your computer screen) is surprisingly awkward compared to just following a link from one web site to another, and as we’ve learned from the postal service, the telegraph, the telephone, email, and the web, connectivity always wins in the end.
Future
Web apps run everywhere and connect to each-other seamlessly, and HTML5 allows a well-written web app to do almost everything a closed, device-specific app can do on a smart phone — many of the mobile web sites I’ve used (hello, Google!) are as good as or better than the corresponding device-specific apps. There are some things, though, that make mobile web apps stand apart:
- The built-in buttons on your smartphone are tied to the browser, not to the app, so the Android menu or search button (for example) brings up a browser menu or search box, not an app one.
- For good security reasons, a web app will probably never have as much access to the filesystem and device hardware as a closed device-specific app (do you want a malicious web app to be able to turn on your video camera when you’re browsing in bed? do you ever consider that when you give a downloaded app access to your camera?).
- While HTML5 supports notifications, you have to actually be on the web page to receive them. That can be fixed by allowing the browser to launch web pages automatically on start/restart, but it’s still more awkward than an autostart app.
- Web app processes need to be managed from inside the browser, not from a device-wide process manager.
- As far as I know, there’s no way for a web app to install its own icon on the device home screen — the user has to install it manually (though it’s pretty easy).
I don’t consider most of these to be a big deal, but they do point to the fact that no matter how much extra functionality HTML5 provides, web apps have a different world view: they’re nodes in a huge network, not standalone silos.
Present
I’ll probably have to continue to use a device-specific app for anything related to playing music or capturing photos/video for a while longer, and I’ll hang onto the Android WiFi analyzer I’m running on my phone. Android has a lot of the same apps that show up in iPhone commercials (like Urban Spoon), but while they’re pretty, they’re limited in the end — there’s way more out there on the web than there will ever be an an app store.
If you’re an person or organization that wants to interact with people on mobile devices, you have two choices:
- You can develop and maintain separate apps for iPhone, Android, Blackberry, Palm, and any other smart-phone OS’s that may come along, and let the phone vendors be gatekeepers between you and your users.
- You can run a single mobile web app on your own server, one that’s only a click away from any other web site that links to it.
The first option lets you force an icon onto the users desktop, but the direct development costs and opportunity costs of losing inbound links and search-engine love just seem too high.
Quoderat 
Take a look at phone gap. It allows you to take the same HTML5 application, and “package” it for all the devices out there. This includes an “installer” so that the application icon appears on the devices desktop. http://www.phonegap.com/
Web apps are the future. Even if you cobble an app together using Phonegap, what about getting it accepted, updated, etc? What about Android, Blackberry, Nokia or WebOS? Can a small team keep up with hardware fast enough? Apps have their place, but look for the rise of the mobile web app and the relative decline of the native app.
At the same time, the “write once run anywhere” mentality of web apps isn’t as useful as it sounds, since the interface guidelines on iPhone, Android, webOS, and Blackberry are often radically different, writing an app based on just one or some weird hybrid won’t be satisfactory in the same way as at least customized apps will.
Having worked in the mobile industry for a bit, I’ll second osten’s opinion. Realistically, it’s just as much a pain to try to write a web app that works well on all mobile devices as a native app. Companies like Volantis, et al., exist because the misconception that web apps will all display the same on all devices with a browser.
Web apps are good for some things, native apps are good for others. Solutions like PhoneGap, Appcelerator, etc. provide some degree of “portability” with regards to creating native apps, but if you dig down into the guts, you still have to potentially customize the UI for each device, which should come as no surprise at all. There are performance issues as well that are tied to cellular network performance (which is almost always worse than WiFi or a LAN connection), processor speeds, memory, etc. Also there are the issues associated with browser implementations (and don’t even get me started on the fragmented nature of JME on devices).
Pundits claiming that web apps are the future are speaking from a desktop/laptop perspective. They obviously don’t get the issues around web apps on mobile devices. It’s a nice goal, but it hasn’t happened yet and I’m not sure that it will happen in the way the rosy picture has been painted.
It is a beautiful post . Now, This is really great. Really very great blog this has given me all the information that i needed, good for visiting daily it will increase our knowledge.Best luck for future.
@BigLinuxGuy wrote “it’s just as much a pain to try to write a web app that works well on all mobile devices as a native app”
I remember, a bit over a decade ago, when the same thing was true on the desktop. Desktop browser compatibility is still far from perfect there (IE6 is the monster that will never die), but in general, write-once-run-anywhere is a reasonable goal for a desktop web app, and it’s easy to do a web site that runs well in IE7+, Firefox, Safari, Chrome, etc.
With both iPhone and Android using web kit, and RIM about to move to it, it might not take nearly so long to get the same level of compatibility for mobile sites — non-web-kit browsers are going to be forced to follow the same standards and specs as web kit or risk being left behind, and there are many more accepted standards in place now than there were in the late 1990s. It’s already very easy to create a mobile site that runs nicely on iPhone and Android, unless, of course, you expect it to look like a native app instead of a mobile web site.
There’s actually quite a lot of the functionality that separates mobile apps from desktop apps coming down the standards line. More importantly, that functionality is making its way into the browser at a respectable clip. There’s a W3C working group that’s helping move the state-of-the-art forward: http://www.w3.org/2009/dap/
In a similar vein to your post, I wrote a post last week suggesting three things that browser developers could do that would bring us much closer to HTML5 Apps being a reality: http://blog.romeda.org/2010/05/three-simple-things-that-browser.html
@BigLinuxGuy You must work on a very demanding type of web app. For OurAirports.com, I might have 3-4 lines of browser-specific JavaScript (I don’t remember), but definitely not 3K! Leaving IE6 out of the picture, I find that I can almost always use the same HTML, CSS, and JavaScript (if required) for IE, FF, Safari, Opera, and Chrome these days.
Granted, I’m not trying to write an online office suite or photo editor, and no doubt there’s a lot of browser-specific JS in Google’s code that runs when I embed Google Maps, but the browser-incompatibility problem on the desktop is 99% solved for 99% of sites. I’m hoping we’ll be able to say the same for browsers on mobile devices very soon.
BTW, if you design your site properly, JavaScript and CSS will cache, so the extra bandwidth shouldn’t be an issue (maybe a few KB/month/app).
@david Well, let’s say we see the world from different perspectives and I disagree. If I have to cram 300K+ of Javascript to make a page render correctly across all browsers, it seems like a loss to me, not a win. Bulking up the browser and adding larger versions of HTML , CSS, and Javascript don’t seem like a win either. Why? Those “unlimited” data plans are not really unlimited, they just have a high cap (~5GB/month or so). If I write a native app, I only need to pull data, not display information and data. There is also the speed issue associated with wireless networks, or rather, the lack of speed. It’s far too easy for folks from the wired world (WiFi counts as wired in this case) to not understand the issues of (comparative) scarcity in the mobile world and do a hand wave that “in xxx years the networks and hardware will be there to support our advanced apps.” Maybe that statement will be true in the future, but it’s not true now, and now is when I need to build apps.
But your mileage may vary.
@Blaine Cook The browsers continue to attempt to evolve into its own meta-platform. At some point, it will be as big as Adobe Flash and most likely as processor / memory intensive. What I like about the approach taken by PhoneGap and Appcelerator is that they’ve embedded a browser within their application, so development becomes much easier since you don’t have to worry about browser versions.
I’m not adverse to having a standard presentation layer, but I am concerned about the increasing girth of HTML, CSS, and Javascript (see my post to @david). Most wireless carriers are planning to implement quality of service controls based on policy in the next 2-3 years. What that translates to is degraded performance for large consumers. I have yet to see anything in the current web standards that indicates things will become more compact. They just keep getting bigger, and that will become a real problem when those controls are in place.
mobile websites will surely grow in the following years’–
hmmm, i would love to browse mobile websites from now on, “`.