Tag Archives: mobile

No -> Packaged HTML5 Apps: Are we emulating failure?

Packaged HTML5 Apps: Are we emulating failure? | groovecoder.

The simple answer is “no.” But just some nitpicks.

The Problem Is Contrived/Misapprehended 

  1. If you already have a QR scanner in place, you skip half the problem.
  2. Android?
  3. The pizza place could just have their own app, easily searchable or linked (as in the captive wifi situation).
  4. If it’s an FB, they could say, “just search for ‘incredible pizza tulsa’ to get to our FB page” in the app. It worked fine on the iOS FB app search…

Just because one place offers a sub-par way to find them on mobile FB does not mean, “apps suck!”

The Web is a Bigger App Store

Claiming that discoverability is bad on the app stores may be true; however, the Web is essentially just a bigger app store, and discoverability is worse because it’s not just apps, it is all kinds of content, much of which is not pertinent nor optimized for your device.

There are many good reasons to go native or even PhoneGap. They may not be compelling for everyone, but the reasons given in that post simply show the bias of the writer.

Tagged ,

HTML vs. Native Apps: The Jury is Still Out

Allow me to disagree with my esteemed colleague.  A few thoughts–just my opinion. He echoes another article I read recently (can’t find it now) that basically argues against native and for HTML5-based apps. I’ll offer a few points to the contrary here.

First, you don’t need a plugin for native phone apps, and often native apps run more smoothly. They also still tend give you a better chance of being discovered than, e.g., a pure Web search. AND, with a native app, you can get both Web coverage (host a Web page talking about and linking to it in the app store) and whatever app store coverage you get.

Another point in native app’s favor is that they tend to be optimized for particular platforms from a Design perspective, i.e., they feel native, they feel like the experience that the platform promises–the one that the person decided to buy over the others. They are also (usually) consistent, following platform patterns.  These points are not typically true for Web apps–especially since a major benefit (from the app creator’s perspective) is the whole “write once run anywhere” thing, so you end up with a vanilla app experience that is either native for one platform or for none.

About IE10 and HTML5–it’s not going to be immediately adopted. It’s not clear when, for instance, touch/gesture support will be pushed out to WinPhone yet. Even then, it will take some time for folks to update their phones, and you can’t effectively “be sure” it is there for some time yet.

This adoption problem is much more an issue on desktop. Saying HTML5 doesn’t require a plugin doesn’t tell the whole story because it requires a current browser, which for all intents and purposes serves the same function as a Silverlight or Flash plugin–the user has to have special software installed to use it.  And both of those plugins have much more of an install base right now than HTML5, and will for some time yet (a long time, in software years).  It would be very surprising to see major enterprises all moving to IE10 right away.  It would be nice, but I’m not holding my breath.

Three years from now, maybe it will be true that HTML5 is the obvious winner on the desktop, but I’m still not convinced it will ever be on mobile devices.  Most likely, the best strategy will be to come out of the gate with a mobile Web app OR choose a platform you think gives you the best bang for your buck initially, and then you can fill in the gaps (either building native for other platforms or Web app for your non-primary target).

Just my 2c.

Tagged , ,