Lately, there has been a rush of activity around building native applications for the various mobile devices. The latest explosion of activity started in 2008 with two events: Apple opened-up the iPhone to 3rd party development by releasing the iPhone SDK, and Google released Android as open-source software. In 2010, of course, Apple fanned the flames with the release of the iPad, and Microsoft Windows Phone 7 looks like it will be a strong platform for mobile device custom development. But even before these events, there had been waves of popularity of mobile development coinciding with the rise of Blackberry and before that, Palm devices. It even used to be the case that something didn't have to be a phone to be a mobile device. But now that most mobile devices are network-capable and the bandwidth available to them has expanded dramatically, the question becomes, "Do we need discreet native mobile applications, or can a single web application perform the same function for multiple device types?" After all, most of these native applications are probably exchanging data with a server somewhere - why can't they get their user interface as well as their application data from a server?
This question is eerily familiar to those of us that remember the beginning of the sea change from "client server" technology to "thin clients". Powerbuilder, Delphi, Visual Basic, and other tools were strongly entrenched and the discussion was about the richness of the user experience, how much data had to move over the wire, and the relative weakness of the HTML/HTTP environment for doing complex workflows and transactions.
We all know what approach won in that debate, yet many of us who either went through it or studied it, find ourselves advocating that new enticing iPhone or Android native application. Why is that? The reasons are varied:
- "Taming the beast" - Many of us who are programmers at heart enjoy the challenge of making a new device perform exactly the way we want. Myself, I must admit I have never owned a programmable device for which I have not written at least one application, even though in many cases I could have found or bought cheaply an application that did the same or better.
- Performance - There is no question that for some applications, performance can be better in a pure native application. But with higher bandwidth and faster mobile processors, does this category include anything but games?
- Local Data Storage - If an application has heavy data requirements and must be used off-line, then this reason is valid. However, HTML 5 offers local data storage to web applications, and how often are most mobile devices off-line anyway?
- Image - Everybody does web applications these days. Sexy mobile applications are new and enticing. It is perfectly understandable for an organization to make an iPhone or Android application just to show how up-to-date they are.
- Marketing Opportunities - Sometimes there are purely economic reasons for developing a native mobile application. This comes out of the strategy of the device provider for controlling the application landscape. A case in point is Apple's strong hold on applications via the App Store, which is the only way for developers to get their product to new clients. Even if a web application is the best way for a company to provide its product/service to clients, just the fact of having an application in the App Store where clients can find it can be a marketing approach. Many applications in the App Store seem to be there just for that purpose. An example would be Geico's GloveBox application, the functionality of which could easily be matched by a pure web application.
Likewise there are some very good reasons for not doing a native application:
- Deployment model - Apple already uses the iron fist approach to application distribution for the iPhone and it looks like Microsoft will be adopting a similar model for Windows Phone 7. So far these models have offered no capability for role-based purchase or download that would allow an organization to determine who can download its apps. Apple does have an enterprise distribution option outside the App Store, but it is probably only useful to fairly large enterprises.
- Skill-set - The skill-set required for mobile development can be quite different from that of your typical web developer. Can you say "Objective-C"? Even though Android is Java-based, any developer will tell you knowing the language is a minor part of their job. Knowing the libraries and API's is what it takes to be a good developer, and these are completely different between web and native development.
- Duplicate effort - Many organizations have mobile apps that do exactly what their intra- or extra-net web sites do, but to get at least the user interface onto a mobile device requires duplicating the effort that has already gone in to developing the UI for the web application.
Some would argue that with the disparity in screen sizes, browser capability, etc., that it is just as hard to develop a web application that supports multiple devices as it is to just go ahead and build the discrete mobile applications. While I will be the first to admit that these differences are challenging, they are much easier to manage than changes that will be inevitable on the hardware devices themselves. And not everyone is developing for the multiple-device market. My recommendation is that even corporate IT shops that are targeting just one mobile device think twice before committing to write a native application. The initial effort and ongoing maintenance are likely to be much lower in creating a mobile-friendly web application. In fact, if you are limited to a single device, the challenges are fewer and it is even more possible to make a web app that is elegant and useful. For example, Apple specifies some HTML markup tags that will enhance the look of a site for iPhone users, but be ignored for other web browser types.
In conclusion, I am not against all native mobile device development. Sometimes it will be the correct approach. Just make sure you evaluate your reasons for doing so, and make especially sure your primary reason is not just an instinct to "tame the beast".