Apps Must Be Cross Platform

This is a copy of a guest post I wrote for GeekWire. View the original here.

Maybe there are a few Robert Scobles out there who still believe that a significant number of successful apps in the future will be unique to any one client platform.

Connected experiences across all devices is where the growth is and it would be insane for anyone, from a major brand to an early-stage startup to believe they don’t have to build for at least iPhone, iPad, Android phones, Android tablets, and Windows 8 tablets.

Developers at agencies, big brands, and startups, are all saying to me:

“We have to do cross-platform. It sucks. I want to poke my eyes out. But we have to do it.”

The way I see it, mobile developers have three alternatives:

  1. Believe in the Write-once, run-anywhere pixie-dust and end up creating slow-performing, shitty user interface with lowest-common-denominator approaches such as HTML5.
  2. Spend a crazy amount of duplicated effort going completely native on each platform.
  3. Be smart and use an approach that combines native UI with a cross-platform technology for non-UI components.

I wonder if my bias came through in that list?  Just in case it didn’t, let me drill in a bit more:


Here’s the deal. Nobody actually wants WORA. Nobody.

Platform providers don’t want WORA

I designed the <OBJECT> tag (sorry!). In working with the The World Wide Web Consortium, I saw first hand the positioning. Each company said they wanted an HTML standard across all browsers, but each of them wanted their browser to be unique and better.

Today, the world is a better place because HTML5 exists. I love the capabilities it provides as I’m building MileLogr. Cross-browser compatibility is orders of magnitude better than it ever has been.  But do not think, for one moment, HTML5 is going to EVER lead to WORA Nirvana.

Consider this: You can basically give Apple credit for creating HTML5 with their work on webkit. However, HTML5 is not in Apple’s best interest and they are obviously dragging their feet with compatibility and performance.

Why? Because websites that run as apps break Apple’s strangle-hold on their walled garden.

Platform providers say they want WORA, but they don’t mean it. This will always be true.

Customers don’t want WORA

Facebook gave “write-once, run anywhere” an honest try. But in the end, their customers rebelled and forced them to rewrite their HTML5 based iOS app as a native app. Customers notice poor performance and they notice when apps don’t ‘feel native.’

Today less than 10 percent of Android phones support the latest released version of Android. This is more than months after “Ice Cream Sandwich” shipped. The latest version of the Android operating system lets you build ‘ok’ Android apps using HTML5 because the browser engine in Ice Cream Sandwich is fairly modern. What percentage of Android phones will support REALLY good HTML5 apps 12 months from now? I think 15 percent would be super aggressive.

That means that 85 percent of Android customers can’t run such an app. Customers love that! Not.

Developers don’t want WORA

Ok, fine. They do. They really do. But only if it lets them also take advantage of unique platform capabilities. Oops.

In an extremely ironic twist of fate, Microsoft might end up being the biggest proponent of HTML5.

The Windows 8 “Metro” app model allows for multiple ways of building apps: Using HTML + Javascript (HTML5) or XAML + C# (cough, Silverlight). But the UI code you write in your HTML based Metro apps is hardly useable on any other platform because the Metro UI model is so different. Is that what developers want?

I picked on HTML5 here because it’s really the only technology out there today that anyone ever suggests might enable WORA. I’m all ears if you think there’s something else; I’ll happily pick on it too.

Going Native

This is just math. Given infinite resources there is no debate that building clients using native APIs will result in the highest quality user experience on each platform.

Who’s got infinite resources though? Facebook, I guess. Microsoft appears to be doing a bit of this (the iOS version of SkyDrive and Bing appear to be completely native).

For the rest of us, the math simply doesn’t make sense. A typical high-quality app on iPhone, Android, WP7, or Windows 8 (I’m just talking client code here) will run $50-100k per-client platform. That’s serious coin for a small company or typical brand campaign.

Mixed Model (Native UI + Cross-platform Core)

I obviously think this is the way to go. For a Mixed Model app you still have to have some expertise with each platform’s UI APIs and you still write a lot of platform-specific code. But you use a cross-platform technology that allows for the lion’s share of your “core” code to be shared.  The UI is “native” and the guts are “cross-platform.”

Ideally we’d call this model “Hybrid – Native UI” and the inverse “Hybrid – Lowest Common Denominator UI” but last year the hype machine firmly established that the term “Hybrid App” means “slow, mostly compatible, non-native HTML5 UI packaged as a platform specific app.”

This is what PhoneGap does. This is not what I am talking about.

I herby coin the new hype-term: Mixed Model Mobile Apps.

There are currently several alternatives (that I’ve found) for creating Mixed Modelmobile apps

  • Mono (C#)
  • Javascript

Xamarin’s Mono tools are fairly complete and widely used. In my own experience using them, and talking with other developers they work really well.

There are quite a few popular iOS and Android apps that are built with Xamarin’s tools including Rdio. The tools and technology is mature and vetted.  Performance is great (particularly because your UI is native) and reports of the amount of code sharing illustrate my point about developer efficacy. The following blog posts give some insight:

  • iCurcuit: ~80% code re-use across iOS, Mac, and WP7.
  • TouchDraw: ~60-70% code re-use across iOS and MacOS.

I’ve yet to find a professional grade Javascript solution that really does what Mono does, but it should be theoretically possible to build a tool chain that lets you write most of your lower level (model, view model, controller) code in Javascript and keep your UI (view) code using the native platform. Given how ubiquitous Javascript has become I’m sure you’ll see some comments below around solutions out there that do this.


Both the dream of being able to focus on a single client platform and the dream of being able to write-once-run-anywhere are just that. Dreams.

If you want to reach the largest audience with a quality experience, you must target all popular client platforms. The UI models of those client platforms are so different from each other that a last-common-denominator approach will not provide the quality customers expect. Going fully native on each client platform is prohibitively expensive.

The solution is to take a hybrid approach: Mixed Model.

I started writing this post before Xamarin announced they had received $12 million in Series A financing. I think the fact that they are now so well funded makes the case for using Mono even stronger. What do you think?

© Charlie Kindel. All Rights Reserved.


Comment on this post

This site uses Akismet to reduce spam. Learn how your comment data is processed.