Why do you need an app for that?

I have recently stopped using the Facebook and Mail apps for my iPad and iPhone in favour of the HTML equivalents offered through Safari. The reasons: Mobile-optimized web applications are now as good, or even better in many cases, as their native app equivalents. In the case of the Mail app, I have found that the gmail mobile version has a superior search feature and is much faster in loading my messages. For facebook, I just found the app limited and more buggy than the HTML equivalent.

In general, I’ve come to the conclusion that if you’re going to build a native app for something, you’d better have a good reason – and good reasons are becoming fewer as HTML browsers improve their support for HTML5. The only valid reason at this point is a requirement for significant client-side processing – e.g. a 3-D game. But as WebGL matures even this will be quite possible in HTML.

So here are some reasons for developing your mobile applications in HTML5:

  1. Increased productivity in most cases over development of native apps.
  2. Real standards-based, cross-platform support so you can write it once and have it work on all major platforms (Android, iPhone, Blackberry, etc…).
  3. True freedom of deployment. You are not locked into Apple’s (or the next would-be gatekeeper’s) store or subject to their sovereign choice of what can and cannot be installed.

The remaining reasons why you may still need to develop a native app:

  1. You want to use a platform specific feature that isn’t available through the web api. E.g. the accelerometer, or the contacts list, or push notifications, GPS, etc..
  2. You need more client-side processing power than you can harness through the web.

The compelling reasons to want to develop a native app:

  1. To get it into the app store and maybe make some money.
  2. Toolkits (e.g. XCode/Interface builder) are developed and promoted specifically for making apps target a specific platform. This can make it seem easier to break into the market since there are lots of learning resources on how to use these tools.

The biggest challenge right now facing HTML mobile developers is that the tools are less promoted and more scattered. This is because the major stakeholders (e.g. Apple) have a significant interest in getting you to develop your app natively so that it will be exclusively available for their platform, and they will get a cut of any revenue through their store model. If you look, however, there are tools out there for building slick HTML mobile apps that look and feel very much like native apps. Some examples include:

  1. Sencha Touch
  2. jqTouch

And there are more where those came from. If you still want to develop a native app and you would prefer to work with open technologies like HTML and Javascript you may want to look at Appcelerator which provides tools to develop applications in Javascript, HTML, and CSS that can be compiled into native apps all the major smart phones (e.g. Android, iOS).

2 thoughts on “Why do you need an app for that?”

  1. I agree with your premise except for one huge annoyance. Safari on the iPhone is limited to 8 “tabs”. On the iPad, they added one more (9 total). These fill up very quickly, often before I’ve had a chance to complete working on something or bookmark it for later. Worse yet, when the limit is reached and a new page is opened, ie from an app or bookmark on the home page or as a popup from another site, Safari immediately replaces one of these existing tabs with the new one. There is no confirmation for this action, no way to go back, and no way to tell which tab was closed. It is seemingly random and very frustrating every time to lose a tab without knowing which one just disappeared. This has been my biggest complaint with Safai over the past 4 years since the iPhone first came out. Because of this, I always prefer to use apps instead of web links, since they remain “open” (background) indefinitely.

  2. @Alan Dobkin – Yes, that limitation on number of tabs is an annoyance – and perhaps a limitation. For HTML apps there are workarounds, though. You can use cookies or client-side storage to keep track of where the user currently is in the application in order to simulate multi-tasking. Then even if the tab is closed or replaced, you would still be returned to the same part of the app when you click on the app icon.

    I don’t think I mentioned specifically in my post about the ability to add web links to your home screen, but this feature helps to level the playing field for mobile apps. You can access your mobile apps from an iphone/ipad the same as if they were native apps. If used this way, the opened tabs in safari is a non-issue.

Comments are closed.

comments powered by Disqus