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:
- 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.
- Spend a crazy amount of duplicated effort going completely native on each platform.
- 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:
WRITE ONCE, RUN ANYWHERE (WORA)
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.
Conclusion
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?
RSS - Posts
I wouldn’t even talk about HTML5 as an option for anything serious. Don’t get me wrong – I love the concept of rich cross-platform web applications – but usability-wise they throw us back to where we have been many many years ago. So they are really a no-go.
Xaramin definitely has the best of both world and they really got it right when they decided to let you go down to native Objective-C any time you need to. So you can basically share as many code as you can without being afraid of making compromises in terms future device-specific features.
Love the article, but you are not giving HTML5 a fair shake IMO. I create native experiences all the time in HTML5. The only thing really holding it back is like you say the platform vendors wont get thier act in gear and support the device APIs and even that is not a total killer. I have a litmus test, do you need to shake your app to make it usable? If the answer is yes, then native is probably for you. Do you want to give 30% of your revenue to APPL, GOOG or MSFT, if yes then native is probably for you. Do you absolutely want to do deep dives into the details of 3-5 unique platforms and expend massive resources developing for each, then native is for you. Do you want to hit all the platforms quickly, deploy updates quickly and keep all your revenue, then HTML5 is the platform for you.
Great article. I love it when someone articulates accurately the issues that I have tried to explain to others. One of the reasons I ventured into SilverLight architecture/ development was to push SaaS applications to a new level from that of being dependent on browser/ HTML/ JS — basically trying to create a cross platform native app. The lesson I learned, however, is what you state above “If you want to reach the largest audience with a quality experience, you must target all popular client platforms”.
What’s your take on RIM/Blackberry and their approach to Development on BB10 platform?
Seems like mr. Kindel is not familiar with Flash platform, and specifically Flex.
I would like to ask him if he even create fully cross platform application with Flex, and then try the performance, and capabilities on the all test platforms with the result application.
The situation with Flex is the same as with HTML5 – Apple dont wana Flash, because it is THE TRULLY CROSS-PLATFORM WRITE ONCE – RUN EVERYWHERE – LOOK THE SAME WAY.
This is the dream of all users, but not Apple, which wana keep closed.
That’s why Jobs create his famous offend againt the batery issue with Flash platform statement, which main idea was to drag it down.
Later he tried to get a benefit from HTML5, while he thinked that they will be the leaders on the market, and this will bring them more profit ( Windows 8 was still in design mode ).
I would say – HTML5 isnt what the users looking for. Flex is, and it always was.
but as you said Apple don’t want Flash. So what is the point of talking about Flex when IOS is most important platform?
I really wish Flex was the holy grail, but sadly it didn’t work out for
us. The problem with Flex is that it’s hideously slow, especially on
older devices. We’ve made quite a few Flex apps for iOS devices, and
there were a few problems:
* General Flex component performance is pretty poor, especially on the iPad 1
* Pure AS3 applications are fast, except for when you have fast
inner-loops. Taking an image from the camera on an iPhone 3GS and saving
it as a JPEG took up to 30 seconds out of the box. Using 3rd party
libraries we managed to get it down to about 10-12 seconds, but the user
obviously doesn’t want an app to freeze for that amount of time.
* Native extensions cause hideous compile times. To fix the JPEG issue
we wrote a native extension to do it all natively in C. Problem is each
native extension adds many minutes to the compile time. We had a compile
time of about 10 – 15 minutes for the app (had a couple of ANEs).
* A bit crash-happy. When interacting with the camera we found the app
would crash every so often, whether custom ANE or Adobe’s built-in
implementation.
On the other hand we’ve been experimenting with MonoTouch and largely
have only praise for it. The performance is exceptional, and I really
mean that. If you start messing around with ‘advanced’ features, I would
say MonoTouch is faster than Obj-C, even if only because the .NET
collection classes muller the Obj-C ones performance-wise. Obviously
C/C++ is faster, but it’s been really pleasant being able to use a
modern language like C#. I’ll have to run some benchmarks one day, but I
wouldn’t be surprised if C# with the LLVM compiler outperforms Obj-C in
many cases. Interestingly Mono for Android is much faster than writing
‘native’ Java apps:
http://blog.xamarin.com/2012/05/01/android-in-c-sharp/
The only problems are the entire .NET framework isn’t available for
obvious reasons, code generation isn’t supported (and therefore no
on-the-fly generics), and libraries have to be compiled for
MonoTouch.
Still, the amount of code sharing is very high.
http://www.GLBasic.com is also a very good and fast way for mostly graphics driven Apps.
Mixed Model sounds like a good approach as it covers needs of both users and developers.
Obviously fluid UI bound to platform rules is much more important than cutting development expenses with HTML5 based UI (even if this UI doesn’t require hack for specific platforms).
On the other hand sharing core code makes it both easier to develop initial version and (what is more important) develop updates and fixes.
I don’t agree. I’ve been a developer for way too long – and only knew a couple who tried this approach with PCs and Macs. Basically companies have been comfortable committing to apps for PCs while essentially ignoring the Mac, and in fewer cases – developing apps for Macs and ignoring the PC.
I think that’s the natural way. iOS comes out with new versions fairly often, my instinct is that most users upgrade, and a cross platform development environment will take time to release a version for the new version. Plus, as you said, the UI is so different, as is the functions provided by the iOS.
While it sounds good – something a good PM would say – I don’t buy it.
I’ve been a PC developer for 35 years, and my plan is to become an expert at iOS and not try for Android at all.
Great article. One approach is to ignore Android and WP7 and target iOS for mobile apps using Obj-C. You’ve noted before that Android is a problematic platform and Microsofts offerings for mobile/tablet are either unproven or still an unknown quantity.
I think the Flash platform is great for simpler games and kids UI but was never sold on Flex, the apps were cross platform, AS3 is strongly typed but the UX wasn’t great and not native feeling.
Writing cross platform apps in a wonderful language like C# seems like a great way to go with the caveats noted above. Also Unity uses C# so maybe that’ll help and I’ve heard that long term even Apple wants Obj-C to be more like C#.
HMTL5 seems to have just to much legacy from it’s past for complex complex UI, maybe I’ll change my mind if JavaScript gets proper classes. JS devs keep insisting this isn’t an issue but I can’t believe what they put themselves through.
Here’s the scorecard for our app:
Windows – common core C/C++, UI C/C++.
Mac – common core C/C++, UI Objective-C.
iOS – common core C/C++, UI Objective-C.
Linux (on our own web server) – common core C/C++, UI C/C++.
Android (in progress) – common core C/C++, UI Java.
Windows Mobile (legacy, obviously) – common core C/C++, UI C/C++.
Windows Phone – C/C++ is banned, so no development is possible.
I keep on hoping that Microsoft will reconsider this suicidal decision, but nothing so far.
In Windows Phone 8 you are supposed to be able to code in C/C++.
And I would like to add:
MoSync – common core C/C++, UI JavaScript (Native UI)
Take a look at MoSync, they do native ui from JavaScript/HTML code, not mature yet but promising.
For those of us who have to write web apps a conservative use of HTML5 is an improvement over past HTML standards. But I see MSFT’s support for HTML5/js as more of a way to lure non-.NET developers into developing for Win8.