Most likely, you’ve seen The Polar Express. The animation technique used in it resulted in animation that is said to result in the Uncanny Valley effect. The Uncanny Valley theory says that while human-acting robots/animations or other non-human reenactments can very closely mimic the actions of a human, they cannot truly portray the emotion of the human face. The resulting coldness or unemotionality evokes a strange feeling in observers, who will find the character to be insensitive, unmoving, or sometimes just creepy.

For years, technologists have struggled to create a “universal runtime” that enables an application to run on any computer, regardless of operating system. A framework that would let application developers write applications once, and run anywhere. Surely you’ve seen examples. Java is of course the poster child for this effort, even having the phrase, “write once, run anywhere” attached to it, whether that’s true or not is a separate conversation. Before that, Smalltalk. Beyond Java, Adobe Flash and Microsoft Silverlight are also cross-platform runtimes.

Each of these runtimes suffers from the same problem – it’s the same psychology involved in the uncanny valley. When you run an app in any of these runtimes, or in the Java Swing toolkit that attempted to resolve this, or even in Delphi, which isn’t actually cross platform, as you use the interface, if there is a platform you’re used to, something is wrong with the UI. Buttons, menus, radio buttons, context menus, sliders or other UI widgets; sometimes it’s subtle nuances, sometimes it’s huge inconsistencies with the way Windows, or the Mac, or Linux, would present the UI. sometimes a platform looks most at home on one platform, sometimes it hoses them all equally. But with “universal runtimes”, this is a common dilemma. You’re attempting to build a layer above the native functionality of the OS using external language specifics, and you have to include UI widgets that fit each OS, even specific derivations of the OS. Buttons change shape in almost every release of Windows – what version do these cross-platform languages choose? It varies. Even the Java Swing toolkit that attempted to fix some of these issues still has inconsistencies depending on what version, and what version of Windows, are in use.

Though most wouldn’t think of it this way, Microsoft Word 6.0 is also an example of this. Word 6 was designed for Windows first, and “ported” to the Mac using Microsoft developer tools intended to take Windows applications to the Mac (I remember seeing the tools to do this in the MS company store and thinking, “that’s so cool!” Mac users didn’t agree). XUL (the XML User interface Language) used by Mozilla shares many traits with Word 6. They attempted to create a single user interface that could work on more than one, and as a result, it, like Java, compromised everywhere. It’s the old expression, “Jack of all trades, master of none”. Sure, you get an application that runs “everywhere” (that you have a runtime) but does it look, feel, interact with the user exactly as a native application would?

No. No, it does not (my favorite example is in Mozilla, how it insists on providing underscores for menu accelerator keys, even though Windows has abandoned that actively being shown for almost a decade).

HTML (HTML5, XHTML, other standards, it doesn’t matter) suffers the same fate. Either it’s chemically bonded to the operating system (as Windows 8 appears to be – you won’t be able to run a Windows 8 app, as-is, anywhere else), or it’s got quirks on one or more platforms. Native apps on iOS have, and will continue to have, huge benefits to HTML or Flash-based apps, whether those apps run in Safari or use runtimes like PhoneGap, Titanium, or in the case of Flash, Adobe’s packager. HTML or Flash apps must work excruciatingly hard to match UI widgets, element interactions, dialogs, iconography, etc – to ensure they don’t look out of place in a world of native iOS apps. Users can tell the difference – it’s apps that just don’t go with the rest of the OS – cut and paste doesn’t work the way they expect, certain sensors aren’t available, it doesn’t rotate between landscape and portrait reliably – pick one. It’s these kind of nits that create an “uncanny bevel” between iOS native applications and HTML or Flash-based apps that have been contained to run on iOS. Windows Phone apps do, and Windows 8 apps will, suffer from this same malady, except worse, Because of the strictly defined Metro user interface, and because it is so fundamentally different than iOS or Android, apps will either be ported and look… strange, or go to WP7/Windows 8 and take more work to Metro-ize. Combine the platform specifics of the HTML-based apps on Windows 8 and their “Metrocity”, and they really become useful only as first-class citizens on Windows – they won’t port well anywhere else, or apps ported from elsewhere will always look strange on Metro.

I’ve heard many people say that HTML5-based apps are the future. The effect I’ve mentioned here will keep iOS native as the first tier target for most developers, Android as a second (or possibly PhoneGap, Titanium or Flash packager), and Windows Phone 7, purely from an economic potential perspective for some time. iOS is constantly evolving, elements changing, things like iCloud being added – third-party platforms will lag, so it’s beneficial for app authors trying to make the most of the platform to “go native” – to avoid the uncanny valley effect, fully expose platform features, and simply to provide the best user experience possible.