Photo via Bigstock

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:

WRITE ONCE, RUN ANYWHERE (WORA)

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

Platform providers don’t want WORA.

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,000 to $100,000 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?

Charlie Kindel is founder & CEO of a Seattle startup doing innovative things where space and time collide (www.bizlogr.com). He is an active angel investor, mentor and advisor in the Seattle startup community. Charlie was previously the GM for the Windows Phone 7 app platform at Microsoft. During his 21 year tenure at Microsoft, Charlie built a broad range of products and technologies ranging from Internet Explorer to Windows Media Center, Windows Home Server, and Windows Phone 7. He started his first software company while in high school in 1983 and built some of the earliest shareware apps for Windows. He is passionate about customer focus, lean methods, going deep technically, soccer, and cars. Read his musings about startups, technology, and other random things on his blog and follow him on twitter @ckindel.

[Tablet photo via Bigstock]

Comments

  • brookstalley

    A very insightful tech article. Too bad there’s no mention of revenue, ROI, or business models. In my experience, commercial developers care about these things.

    • http://twitter.com/TroyMc Troy McConaghy

      Some things don’t have to be said because they’re implicit. In this case, one reason for wanting a cross-platform development toolkit is that it reduces development costs (expenses). If you reduce investment and your return stays the same, then you increase the return on investment. QED.

      • brookstalley

        I’d be wary of the obviously implicit. For instance, I have seen plenty of cases where cross-platform development toolkits increase costs by requiring more man-hours and tweaking to produce reasonable platform-native results. Similarly, the assumption that the return stays the same is taken on faith. I’m skeptical of that, too.

        In my experience, my businesses have made more money by doing native development on each platform and reaping the benefit of truly native experiences and paradigms on each platform. Your mileage may vary.

        But you have to realize that both assertions (that cross-platform toolkits reduce costs, and that apps developed with these toolkits generate the same amount of revenue as truly native apps) aren’t supported in the article. And in my experience, neither assumption holds water.

  • http://www.jeffkibuule.com Jeff Kibuule

    Interesting read, though as a developer and a consumer, I always want native apps and think lowest common denominator approaches are trash (just my opinion of course).

    Developers are going to have to get out of the mindset that they are building an app and instead think about building services. With several platforms to develop for, the victor will be from the shop that took the time to support all platforms equally so that their data moves with them, regardless of the end device they are using.

    • Mike M

      Jeff, at least for MonoTouch it is not lowest common denominator. You are writing against the exact same SDKs that the Objective-C developer is, just with a .NET wrapper. And it compiles down to native ARM with no “runtime” of any kind. But of course there is no free lunch: Hello World is large.

  • http://twitter.com/TroyMc Troy McConaghy

    Another option is Marmalade SDK, which lets you use Native UI (which varies from OS to OS) and write all your code in C++. There are many other options. See http://www.mobilechameleon.com/

  • http://about.me/samirsshah Samir Shah

    I agree.

  • http://www.facebook.com/larserik.aabech Lars-Erik Aabech

    Hear, hear!

  • Jason

    You might like to take a look at Adobe Air (http://www.adobe.com/products/air.html) It’s very capable of creating cross platform experiences that work both on Mobile (iOS, Android, Blackberry) as well as on the desktop via the Flash plugin all from a singular code base.

    • http://twitter.com/icosadodeca Joseph King

      Unfortunately adobe air doesn’t support native interfaces :(

      • Jason

        Correct. For the kinds of things I’m interested in creating, the native interface doesn’t really factor in to the equation. It would certainly be nice to have, and hopefully Adobe are listening to the developers that are requesting this sort of functionality.

  • http://www.facebook.com/jonathan.vandeveen Jonathan Van de Veen

    An interesting read indeed. However I do think it depends on what type of app you’re building. I work for a (relatively) small company that makes HR and payroll software and I can tell you that we can’t afford to spend time on building and maintaining expertise and code on the range of platforms our users work with.
    We are going down the WORA path (and have been for the past months) and although I won’t deny it has been a challange and not always a fun one, we do have
    an application that works great across a bunch of platforms (we support Windows (including Windows 8), Mac OS, iOS (both iPhone and iPad), Android (both phone and tablet) and Windows Phone).
    The challenge has mostly been about how to get a proper user experience on a specific device form and not about how to get stuff to run quickly and smoothly.
    My point is not that you should always do WORA. I think it depends on what type of user experience fits your solution. In our case WORA was the only viable option. In other cases I can see how Hybrid is the most viable option.

  • Brandon

    Charlie, curious what you think of projects like MonoCross that further develop on top of Mono to make it a single layer for your biz logic, which further extrapolates down to MonoTouch or MonoDroid for you…

  • http://www.facebook.com/ricky.bon.7 Ricky Bon

    I hope “Boot to Gecko” succeeds. :(
    http://www.mozilla.org/en-US/b2g/

  • Adam MacBeth

    #3 has been the right way to do cross-platform for a long time, so I’m glad you agree.

    Unfortunately, your thesis is dangerously wrong, especially for startups. Startups need to focus on building a product that users love. That means rapid iteration on a platform used by early-adopters and people who demonstrate willingness to pay. iOS is still the only game in town for this stage of development. Android users don’t buy apps. Windows 8 isn’t a real target yet. Reasonable Android tablets are just coming online.

    Any startup that truly believes it needs to start on all platforms will end up burning far too many cycles getting cross-platform – regardless of which development method they choose – rather than getting the product right. Once you have a great product, think about whether you can expand your market by adding new platforms.

    If you’re big enough to have a global audience that spans many platforms (e.g. Facebook) or the central purpose of your app is to handle cross-platform issues (device-to-device data migration), go ahead and start cross-platform. Otherwise, see you at the bottom of the deadpool.

    • http://ceklog.kindel.com/ Charlie Kindel

      Adam, you and I actually agree on this fundamental point: Startups must focus on building a product that users love.

      The nice thing about Mono is it allows a startup, where the founders maybe have a C# background (many do!), to build a kick-ass iOS app with no compromise.

      There is no perfect answer. Every startup, every brand, every developer has a different story. In some cases going pure native for iOS first is absolutely the right thing to do.

  • http://twitter.com/toddhooper Todd Hooper

    Great article Charlie – we share the same opinion. For games, I would add Seattle’s own Moai solution as a good cross-platform solution with 95% common code in one language (Lua) across game client and cloud. http://getmoai.com

  • http://www.viafo.com/ David O’Neill

    I’m wondering if an interest in C++ is down to a ‘Seattle’ effect as there’s a lot of experienced C/C++ developers here. Generally speaking we’re seeing more ‘pull’ globally for reference code and examples that follow a web model as ‘plug ins’ for Hybrid Mobile apps using JavaScript. While, generally speaking,the performance on Android for all HTML5 wrapped apps sucks, we’re still seeing huge pull and demand for this an an approach over other techniques. And looking at the skill sets of developers entering the mobile app space, most of them seem to be coming from the web world and JavaScript.

    Looking at the focus companies like Qualcomm (and others) are putting into HTML5, I suspect for most applications (gaming aside) that’s going to get a lot of momentum and be hard to shift.

    My suspicion is we’ll have a Betamax v. VHS effect where an inferior technology will potentially ‘win’!

    We don’t really mind though, our stuff is platform agnostic – which is why we walked away from platform specific SDKs last year.

    • http://twitter.com/halberenson Hal Berenson

      The “coming from the web world and JavaScript” is precisely why Microsoft put such a priority on the HTML5/JavaScript model in Windows 8 Metro.

  • Eric Bobo

    Anybody remember Java when they hear “Write Once, Run Anywhere”. And then recall ugly, slow applets and applications.

  • Björn Sveinbjörnsson

    I must be missing something. What is the problem?

    I am in the process of writing an iPad/iPhone app, after I finished a couple of Mac (Cocoa) applications. We have an Android version in the pipeline as well. The applications where ported from win32. We are three programmers at the company and have been programming since the the mid 80s. I, myself is an old Win API SDK programmer (Petzold type).

    The core is written in portable C. The GUI on android is in Java and on iOS in Objective-c. Come on. How hard is that?

    The only problem arises if you insist on writing it in C#. Why would you do that?

    This sound like being stuck in Visual Studio (using C#).

    Happy coding,
    /björn

  • http://www.facebook.com/people/Donovan-Kliegg/100001187341261 Donovan Kliegg

    Mono is nice. It is coming close to replacing what C++ used to do for cross platform coding. Even so, cross platform coding is not cost free.

    However, there is a lot of historic precedence for the approach you outline. Whether it was CPM wars, PC Wars, Unix Wars, PDA Wars, or the Browser Wars the choices have remained the same. Unfortunately, you missed out on two other approaches that been used by companies big and small to great success.

    1. Build an application on the platform you believe will have the most success. If that works out, pay Ukrainians to do a port. The great thing about off-shoring a port is the existing product, with its source, unit tests, and QA test scripts presents a perfect spec.

    2. Wait for a copy cat(s) to appear on the other platform(s) and then then use the threat of suit to lower the costs of acquisition of the copy cat. After the acquisition, the engineers just re-badge the booty.

    Products, currently phone apps, bomb in droves. After the hit iPhone app has manifested then make a business decision based on the expected performance of other platforms.

  • Walt French

    Charlie wrote, “You can basically give Apple credit for creating HTML5 … 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.”

    This is quite directly contradicted by year-old information:

    When iOS 5 was released over 6 months ago, the security concerns that motivated the JIT limitation were relaxed to allow comparable speeds:

    Some speculated that Apple had done this deliberately to make Web apps seem like they perform worse than native apps. However, the difference ended up being credited to iOS’s security model, which requires that executable code be digitally signed by the developer and verified by Apple.

    Source: http://arstechnica.com/apple/2011/06/ios-5-brings-nitro-speed-to-home-screen-web-apps/

    Yeah, Apple’s walled garden *IS* in their interest. It is also in the interest of its target user base, who want to be exposed to a bare minimum of security risks, a concern that Apple also applies to OSX, where apps need not be signed, but don’t nag users the first time they run, if they are signed.

    Now you not only have your theory debunked, but an obvious and credible alternative explanation for how they played catch-up with javascript performance, and only secondly made it available to the relatively few apps that took the cheapo route of html5, after they figured out the security issues of letting apps run JITted code.

    You should not have trusted the self-interested disinformation from Massey that apparently forms the basis for the cockeyed theory in the article you linked, where even Xamarin’s Icaza poo-poohed the conspiracy theory.

    Since Ars debunked this BS over a year ago, let me recommend that you remove this embarrassment to your credibility.

    • Jason

      I agree with Charlie – there’s a concerted effort to steer users to their walled garden. The only contradiction here involves Steve Jobs original comments regarding open standards, which Apple clearly has no intention of adhering to. When’s WebGL coming to mobile Safari? More importantly, why ISN’T it coming to mobile Safari…? The answer to that lies in what Charlie said and I concur with.

      • Walt French

        I didn’t say Apple doesn’t want its users to have the security cocoon, despite power-users’ disdain for it. I said that the claim that Apple had intentionally sabotaged HTML5 performance was bunk.

        Per Charlie, HTML5 owes its existence to Apple (stronger than I’d say), and Apple has created a highly-secure and high-performing versions of it that first ordinary browsing, and now web apps, can use.

        You can’t make as positive a statement about Microsoft’s Win8 tablet environment (which, two years later, is still in the labs). You can’t say that about Android, which offers up no way for users to be protected from drive-by html5-based malware.

        So even if Charlie were pandering to anti-Apple bigots (which seems beneath him), his speculation about Apple’s motivation is really damaging to his case. It is false, it is irrelevant to his case, it makes him look clueless about a long-buried false claim and it distracts from his point about how serious developers can best address the market.

        • http://ceklog.kindel.com/ Charlie Kindel

          Walt,

          Neither you, nor I, really know what Apple is actually doing. You are speculating that Apple will continue to be as free-and-open with innovation in webkit as they have in the past.

          I am speculating that things have changed for them since they first invested in webkit. Back in 2007 they had a primary goal of creating the best browsing experience on a smartphone. Today they are printing money based on a vertically integrated model that has become dependent on their walled garden. I am speculating that the pressures to maintain those gross margins directly impinges on innovating in free and open web standards.

          Time will tell who is right, as usual. But you’ll note that Apple had the opportunity to improve HTML5 based iOS apps in iOS6 and didn’t do so. In the next turn of the crank, the canary in the coal mine will be whether they provide first class support for such apps. Today they don’t.

          • Walt French

            No, I’m saying that the conspiracy theory you explicitly claimed (“dragging their feet”), was bunk, originated by a person with an ulterior motive. I’m not saying Apple has no such incentive, merely that you were citing some seriously dishonest BS.

            Of course developers want a wide-open playing field without Apple’s restrictions, and of course, compatibility could always be better. But the fact that the standards have been evolving for many years is an obvious counter-point to the claim that Apple hasn’t been supporting them… supporting what, exactly, that are so widely adopted that they’d work well on the scope of devices you mentioned?

            Time HAS TOLD what Apple would do with regard to the source you cited.

  • Gabe Martin

    There are several problems with Mono for Android. Here are a couple that stick out:

    While they create nice wrapper assemblies around the Android SDK APIs at last check they don’t make available a way to generate similar wrapper assemblies around the Android Support library or other jars that you might want or need to build into your mixed model app.

    Using Mono for Android means having two managed runtimes (and two garbage collectors) for your app. This can create some interesting object lifetime and memory exhaustion scenarios.

    Also how well does Mono for Android support native libraries? I’m guessing you still need to use the Android NDK to generate .so files to be packaged with your app but then access them via C# P/Invoke all the while making sure you loaded the proper binary for the device architecture you’re running on.

    In general I agree with your mixed model solution but the cross platform business logic should be implemented in C++ and then accessed from the platform layers via Obj/C and JNI.

  • http://twitter.com/dotpeople dotpeople

    Any opinions on http://www.mosync.com/ ? Open-source, backed by MySQL founders.

    • Ali

      Well Mosync supports both HTML5 interfaces and Native interfaces through JavaScript, you also code in C++ if you want to.

  • Oren

    Can anyone recommend a good JavaScript dev platform for the Native-UI/Single Core application, where the core is JS?
    We’ve been seeking for this for some time, since we already have that JS core at hand from a prior desktop web app. We’ve come across this package, but I’m not sure about it’s maturity: https://github.com/KirinJS/Kirin/wiki
    Any pointers are welcome! Thanks!

  • ChuksOnwuneme

    Good article. I am yet to try out http://xamarin.com/, but if it’s as good and ubiquitous as you describe, that’s god news. I have seen some success with SenchaTouch (http://sencha.com) based “hybrid” apps, so to say. Their 2.0 version has seen some really awesome improvements. I dabbled with Titanium’s Appcelerator a few months ago, but abandoned that and stuck with Sencha (+ Phonegap just because of the easy integration with xcode).

    From my experience, everything really depends on the type of apps you are building. The most glaring differentiation comes to gaming vs “everything else”. Take a look at the app gallery for Sencha Touch and try out some of the apps to see what I mean https://sencha.com/apps/

  • Trolleur

    Nice Shit Sandwich.

  • Alexander

    Nice article, we did a comparison on HTML5 vs. Native on Youtube’s app:
    http://www.service2media.com/blog/comparing-the-youtube-html5-web-app-and-the-youtube-native-ap/

    Thus I think Service2Media deserves a mention here when we’re talking about cross platform development. http://www.service2media.com/

    We incorporate native runtimes and interfaces in their platform thus giving the scalability of HTML5 but the native UX and design.

    Definitely worth a look!

  • http://twitter.com/MartinGandar Martin Gandar

    Charlie, I thing the team at http://www.service2media would go along with a lot of what you say. You need all the capabilities of native with the best possible user experience. I guess you have never looked at M2Active, it’s rather European, but it might well appeal to you and anyone else with the understanding of how to use native components and runtimes in an intelligent build environment.

  • http://www.facebook.com/oprufssor Lello Romano

    There are many cross platform tools on crossplatformti./en one of this is marmelade

  • http://www.halosystechnologies.com/ Saurabh Saxena

    The idea behind most cross platform is to save time over the development and coding becomes easy over the different platforms and it can easily be complied with multiple platforms. Even if, these frameworks are easy to use and compile with, it got few pros and cons using it. Appcelerator Titanium is one such platform that comes in everyone’s mind. Now, it becomes easily possible to develop wonderful and fruitful applications for Android, iPad, Blackberry devices with the help of titanium mobile application development service. One of the biggest benefits of Titanium on other multi platform solutions; it is an actual native application that fits well in every native’s ecology that it supports. There are a range of features that offered by Appcelerator Titanium.

  • http://www.mobilepundits.com/Cross_Platform_Mobile_Development.html Astoria Johnson

    Interesting read, in present time cross platform mobile apps saves a lot of time and money for developers as well as business. If any businesss having cross platform mobile apps then business can target a large user base by using this approach in a short amount of time.

    If you need cross platform mobile apps then try
    http://tinyurl.com/oy4swpa

  • doniking

    Embarcadero just released xe6 that support android using c++ and android ndk.

Job Listings on GeekWork

Find more jobs on GeekWork. Employers, post a job here.