I’ve been hearing a lot lately about why iPhone/Android/Symbian/<insert mobile platform here> apps won’t make you money and have a lot of other drawbacks, especially since I work at Wapple, a mobile web solutions provider. Whilst I agree that apps are overrated in their potential to actually make you money, that there are a lot of crap apps, and that apps are not the solution to every problem, I do feel that I should give the other side of the argument.

I’m a big believer in the mobile web. A well designed and usable mobile site should be an essential part of any agency’s package to a client and anyone wanting to build or maintain a brand in the 21st century. It’s not good enough to have a brilliantly usable, beautifully designed, content rich web site, if it looks like a stretched mess when people access it on a mobile device. Having said that, there are some good things to be said about native mobile apps.

One time Vs Common activities

Suppose I want to find out what films are showing at my local cinema, find a few reviews, and then book a ticket for tonight. Now, I rarely go to the cinema, so I wouldn’t want to have to download an app just for this simple task. I’d like to point my browser at birminghamcinemas.com, imdb.com etc., and have a usable interface to deal with. Job done.

However, suppose I was a regular cinema goer, I have a cinema loyalty card, and I know the popcorn man on a first name basis. In this case, an app to manage my cinema tickets, recommend me films, claim my loyalty rewards etc. would be a handy tool to have on my mobile. It’s all about frequency of use. For me, the overhead of downloading an app is not worth it for the number of times I want to perform the task. For the cinema goer, the app would significantly improve their entire cinema going experience.

Somewhere this has affected my recently is in micro-blogging services. I use identi.ca, but having deleted Twidroid during my divorce with Twitter, I’ve found myself having to load up my browser, point it at identi.ca, log in, then click on home just to check on my dents. With Twidroid, I could press a button on my desktop and my tweets where there. The second was a much faster experience, and since this is a common activity for me, it makes sense to have a handy tool for it (read ‘app’).

Speed

Apps run native code on a device, albeit a device with low performance. They may communicate with web services to get some data, and store it locally for future offline reference. Mobile sites require me to send out a page request, have the server run some processing on it, and send back a page over the interwebs.

The second process in itself may or may not be slower than rendering a new screen on a native app, but this is not the point I’m trying to make. My point is that the app requests some data, the mobile site requests a whole page, images, CSS and maybe some Javascript. Going back to the identi.ca example, I have to make 3 entire page requests to get to my dents, reloading the page each time. With Twidroid, the app caches my recent dents, and to obtain any new ones it just sends a single request, which responds with a little bit of JSON or XML. The second is a much smaller payload.

Apps can also be faster in terms of user interaction. The extra step required to open my browser and click on the “GMail” bookmark leads me to use the native Gmail app for checking my email. It’s one press as opposed to two — maybe not a massive reduction, but users (including me) are lazy.

On my desktop, I use Open Office for my word processing. I could use Google Docs, but I don’t. Among other reasons, this is because Open Office is faster, and doesn’t rely an internet connection. For email, I use my browser, as I find it quicker and more usable than any desktop client available. There’s no reason why this paradigm can’t transfer to the mobile device. I don’t see it as apps Vs mobile sites, but more whichever is more appropriate for the task.

Rich Functionality and User Experience

HTML5 is going to bring us some cool stuff, for example geo location. HTML5 is, unfortunately, a long way from being reliably implemented across mobile devices. In addition, why use a slightly shady IP based geo location lookup, when my phone has built in GPS? My phone also has a built in camera, allowing for uber-cool apps like TorrentDroid and Wikitude. Both are fantastic examples of what can be achieved using the rich functionality and hardware APIs available on mobile platforms. Mobile sites can have a good stab, but they’re a long way from competing at the same level.

Native apps are also in a better position to take advantage of hardware specific interaction techniques. The iPhone was for me revolutionary in how one interacts with a phone, making great use of natural gestures and tangible interactive screens. Developers of apps can now take advantage of the work that Apple has put in to provide far superior user experiences than can be found on the web.

Native apps also maintain a common look and feel and use system-specific widgets and controls which are familiar to users. You may or may not think that this is better than the flexibility provided by the web, but certain users find the consistency comforting. One of the reasons I like GNOME is that all the applications look the same, use the same icon set and maintain familiar toolbars.

Conclusion

As I mentioned earlier, I don’t understand the apps Vs. mobile sites debate. I believe that both provide benefits and both have their drawbacks. One doesn’t need to ‘win’ over the other.

I’ve taken a rather one sided approach here, in order to put across my views on the other side of the argument to what I normally hear, but it doesn’t mean to say I don’t have views on why apps are bad, or the benefits of the mobile web.

The mobile web is an extremely powerful and valuable platform, but native application platforms can also provide huge benefits. My advice is simply not to jump on either bandwagon without first assessing the suitability to whatever it is you’re building. Do your research, and make an educated decision based on the value each would provide you.

The future

One of the main areas that mobile sites win over native apps for me is that apps are far harder to port, to update, and to future-proof. I’m pretty sure that 10 years down the line, if I get an iPhone out in the pub I’ll be laughed out of the door. Devices are moving forward so quickly that keeping up with the next big app platform will be a tough challenge. In an ideal world, the mobile manufacturers would build a standardised set of APIs and layout markup languages that work on all devices. Realistically, I’d be willing to bet a few packets of flying saucers that this will never happen.

So, the future is in the hands of the development community. At the risk of being wrong having not played with it yet, PhoneGap sounds pretty cool if it does what it claims to do, and I suppose it makes sense writing stuff that developers are familiar with, i.e. HTML and Javascript. My only concern is that the use of HTML and Javascript will lead people to think building an app is just like building a mobile site, when in reality the two are quite different tasks. The future of mobile apps will be interesting, and I hope to see more standardisation projects like PhoneGap emerging in an attempt to standardise the process of building apps.