So, occasionally when I’m explaining MobileXpeditions to tech-savvy individuals I get asked why we aren’t doing everything as a web app and why we are developing an iPhone application as the first phase. The arguments for going the web app route are basically:
- It gives you a way to circumvent the Apple app store, which many developers find the most onerous thing about developing for the iPhone.
- Web apps are cross-platform and allow you to avoid re-developing for each device.
- Updates are easier to roll out. You don’t need to rely on the end-user to update their application and content can be changed daily if you like.
- There’s an undeniable cost advantage to developing web base applications. You can’t throw a rock without hitting a web developer, while those with the skills to create native iPhone applications are more rare, and scarcity drives up costs.
While these arguments are compelling, and I certainly think there is a place for web applications, there are some distinct weaknesses to that approach.
Let’s take the iTunes store issue, for instance. Sure, you don’t need to supplicate yourself Apple’s standards and approval process if you use a web-based solution, but if you talk to iPhone developers, that process is improving all the time. The approval process is becoming faster and less confusing.
However, even if it were the maddening situation some claim, there are distinct benefits to being in the App store. Many iPhone users only install applications from the App store, and only look for them there. Getting the word out about your application is challenging enough, but if you also have to explain how to get it, that’s just another barrier to adoption.
And, how do you monetize a web application? For some this isn’t an issue, and we really suggest to our clients that they view the iPhone application as a marketing play and not as a revenue stream, but there are those who want to charge for their applications, and Apple just makes the whole process so simple (and yes, you pay for that simplicity). If you sell a web application, you need to figure out a subscription model, or some sort of log in solution, and either way you need to worry about e-commerce and authentication.
Another issue with the web approach is access. Yes, the iPhone is 3G and theoretically can access the internet from anywhere, but we have all found ourselves in situations where we can’t get a signal. In addition, there are tens of millions of iPod touch users out there, who can only access such applications when they’re in range of a wifi hot spot. The new entry-level iPad models have the same issue. So, requiring connectivity to use your application limits usability at best and eliminates a large user base at worst.
The most important reason in my opinion though is user experience. It is easier to create a compelling application that takes advantage of all the platform has to offer if you write a native application. Yes, you can now query the location of the iPhone through a web application, but the implementations I’ve seen of that have been less than exciting, and you still can’t access the magnetometer, accelerometer, directly access the camera, etc. Some of these features we’re already using in MobileXpeditions, others we would like to use in the future.
Besides the phone specific features that are difficult or impossible to access with a web app, you have a performance issue. If the phone is constantly going out to a server for every button press, menu choice, and page load, it’s going to perform in a less than optimal manner. Try playing with Google’s calendar page and compare it to the built in Calendar on the iPhone, there’s a huge difference in quality of interface and in responsiveness.
This isn’t to say that we won’t be exploring web based solutions in the future, but for now, I think we’ll be sticking to native applications.