I think the current conversation about mobile and native apps for learning has gotten a bit into the realm of mythology and wishful thinking about the state of HTML5 and its ability to deliver on the promise for using mobile devices in education. I do like HTML5 and I’m working to implement many things using the awesome frameworks like sproutcore, prototype, jquery and dojo that are really providing great capabilities in client development. I start as a product manager and occasional developer though thinking about creating software this quarter and I think there are a few myths out there worth challenging on the state of the technology worth discussing. As always these are personal opinions, not necessarily those of my employers, etc.

I think vendors and purchasers will be using native apps for the near future, though I’m hopeful that over the long term standards will allow us to run on more platforms at a lower costs. I’ve come to this conclusion and advised my peers based on the following 3 points: current content delivery packages, the advent of multi-touch as the dominant user interface, and the relative costs of platform specific native vs HTML with native HTML.
Consider the state of web delivered today. A large amount of high value, highly produced materials are in PDF, Flash®, PowerPoints® and such. Even the after almost 20 years of HTML we still have enormous quantities of stuff being produced beyond the limits of HTML. We’re slowly getting materials and capabilities into more open and flexible formats, but this is still many years out. At the IMS Learning Impact Conference I spoke with employees from Cengage, Pearson and other traditional education powerhouses. The people I spoke with are passionate about standards, but also working to sell content. On the one hand they are aware that more and more is possible in ordinary HTML, on the other hand DRM concerns, existing development practices and risk management forces them to take a more conservative approach. They have all made very large investments in Flash, and spent billions producing great interactive content using this technology. It will take significant time for them to revamp their production processes and develop materials in pure HTML5 formats. This may create an opening for more nimble providers. At the same time with native apps like the iPad Elements app generating significant revenues, we may see a rapid move by publishers to develop these titles. The fact that Apple apps come with a built in business model for content vs the more loosely defined web model will draw lots of interest. The reality is that a publisher today can build an app for the iPhone and model a return based on marketing, sales and adoption patterns. In the pure HTML5 DIY approach publishers are left with a much smaller set of data to build their model. When one is making multi-billion dollar decisions about platforms, there is a current advantage to the native app model because of the existence of a single user experience built around the App store.
My perception of the content space (a push from existing proprietary development based on HTML’s perceived limitations, and a pull from known business model of Apps and Ebooks); leads me to conclude that native apps have a current advantage that will take many years to overcome.
The second myth around native vs. pure mobile web is view that the transition from pure HTML for a desktop web browser to a multi-touch user interface (also driven by HTML) can be done at no, or limited costs. In fact each mobile device has a different browser version and different set of capabilities. With mobile web we’ve gone from testing a few operating systems and a few web browsers to trying to understand the user experience across a large set of devices and device makers. Andriod’s touch capabilities vary across different phones and screen sizes and pixel densities are different. If we couldn’t make one form of HTML across every web browser and OS, how are we expecting this to be different on the phone interface. I’d be super happy if the dream of write once run anywhere libraries was a reality, but my experience has been that they never live up to the hype, or one ends up with a terrible user experience. Consumers choose their mobile devices because they love the user experience and the “look” of the device. As a small example consider the Blackberry Curve vs. the iPhone. The curve has a trackball and a keyboard. The iPhone has a touch screen UI and virtual keyboard. It is more efficient on the Curve to point and click, but on the iPhone you sweep and drag. A mobile web app designed for curve should be totally different from the one designed for iPhone. Just scaling down your site so it renders well on both smaller screens is simply not acceptable. A native app can overcome much of this.
Now you might say, well why not just render your app in different ways and use HTML as your underlying technology. This leads to my third myth; that the costs of native apps is higher than mobile web. If I have to build two mobile web views; or (n) depending on the platforms I support; then how am I saving any real costs. Many applications are built on a Model, View Controller design pattern. As a developer I can use HTTP transport and XML or JSON as a my data transport behind the scenes and port views and some controls to support various native apps. This results in a higher quality user experience at about the same costs. I hope that as form factors, user input controls and HTML5 features converge we can reduce the number of distinct interfaces we have to support. However in the short term I think that Native Apps will play a dominant role in mobile development for the near future 5-7 years.