Why Cross-Platform Products Fail

Alex Payne has written a wonderful article about why cross-platform development environments ultimately fail to deliver what customers really want; a great experience. Alex says:

This post is about platforms and doing the right thing by your customers. It’s about the one big thing that I think HipChat and some other great companies are doing wrong.

He nails the reason that cross-platform development tools and environments like Adobe’s Flash and AIR products are attractive from a business perspective but end up failing from the customers perspective. Ultimately, that circle of life will come back to haunt the business.

Many businesses are attracted to the idea of writing software once and deploying it across multiple platforms. From their perspective they have one development team, one code base, and one release cycle. What’s not to love?

That’s where most businesses stop their investigation. They fail to even think about what their customers want. They’ll quickly jump up and say, “What they want is our product on their platform. We’re giving them that!”

Yeah, but you’re giving them a turd and that’s insulting. I hear the next bit of verbal diarrhea spilling out of their mouth … and this part kills me.

“Well, at least they’ll have our product on their platform.”

Ouch. I think I just threw up a little while typing that.

What you’re communicating with a poorly-done AIR app is that your business priorities – namely, saving time and money – are more important than what your customers want.

Ironically paradoxical in nature because without customers there is no business.

Alex points out a few very well known products such as TweetDeck, Pandora, and Remember the Milk, where their users are begging for a native application. Sadly, the folks screaming for a native application for Remember The Milk have been flat out ignored by that company since 2007. Actually, that’s not ignoring them. That’s giving them the finger.

My team experienced a number of the usual problems one has with AIR applications: lousy performance, odd interface bugs, key combinations and UI elements that didn’t conform to our operating system. AIR apps exist in an uncanny valley between a web application and a desktop application, and the result is unsettling and annoying. Pretty soon, we were itching to go back to Campfire (via the native Mac client Propane), even though HipChat has better features and the promise of improved reliability.

Why are these cross-platform products so bad? Do users even know if a product is using a cross-platform development environment? Yup, they sure do. Users, even if they’re not geeks or developers like me, can smell a cross-development turd. I love how Alex wrote this:

Humans are gifted with extremely sensitive bullshit detectors. The average computer user may not internalize the difference between an AIR app and a native app, but he knows when something doesn’t feel right or work correctly. Your tech-stunted uncle may not ever request a native application with that terminology, but he’ll sure complain about his computer acting funny when he experiences the oddities of an AIR app.

Just read the comments at this site and you’ll quickly see the common threads:

  • Slow
  • Sucks up CPU cycles better than a Dyson
  • Doesn’t conform/take advantage of native UI
  • Lack of support for native OS features. Instead, uses the least common denominator solution that works across all-platforms
  • Security issues

With comments like that, do you really think “investing” in that type of development environment is going to save you money/time in the long-run? Does this seem like the path to huge business profits and long-term customer loyalty?

Is it more expensive to create native applications across all of the different platforms? Yes and no. Yes, because it is an investment in the development of your product. No, because unless you’ve misjudged the market, this investment will more than pay for itself.

“We don’t have time” is the common excuse for delivering an AIR app instead of a good native app. Money, though, can buy someone else’s time. For a price, you can find a great contractor to build a native app for any platform under the sun. It’s an investment. Eventually, unless you’ve misjudged your market, the investment should pay off.

What should a company do when they don’t have the time, resources, or expertise to deliver a native application? You start by clicking on the link above.

About the author

Terry Blanchard

I'm the Vice President of Engineering at Readdle, ex-Apple, design evangelist, drummer, and gadget junkie extraordinaire.

3 thoughts on “Why Cross-Platform Products Fail”

  1. It’s true that non-native apps can feel like duds. Mac users have famously punished non-native intruders. I recall some Java-based “native” widgets that had an “evil twin” feel to them.

    But the web is kind of one jumbo cross-platform app. Google.com, for instance, might be decent on a variety of devices with capable web browsers. Do you see the web converging and evolving sufficiently to make more sophisticated apps palatable on a wide variety of devices? HTML5+WebGL looks promising…yet it’s still percolating across the web, and the foundation classes are far behind native appkits like iOS from the standpoint of developer convenience and high production value.


  2. I don’t think of the web as an app; it’s information. The app is the browser. Even if you just consider the differences in support between the browsers, web apps ultimately commit the same sins.

    Quality and innovation comes from people who know the platform and know how to take advantage of it. Cross-platform development changes that mindset. It changes from innovation and leading-edge to portability and compatibility. That’s a lose-lose in my book.

Leave a Reply

Your email address will not be published. Required fields are marked *