Presented by Blackberry

Talk Mobile Gaming

What will it take to get every app on every platform?

There are three ways to select your smartphone experience: by carrier, by device, and by apps. Choosing by carrier places the quality of your cellular service first, whereas making a decision based on the device means you're after a specific platform experience and hardware features. But choosing by apps can be trickier.

The current array of mobile ecosystems is simultaneously fragmented and unified across platforms. Some major apps are available on many platforms, as are apps from smaller developers. Other apps are exclusive to a platform by virtue of features unique to the operating system or the resource constraints of the developer. But if you really need that one app, then the carrier or the device don't matter so much.

But what if all apps could be available on all platforms? Is cross-platform development something that developers should be concerned about, and are there pitfalls to be faced in doing so? Is it better to build an app specifically for each platform, or should the app be built with a cross-platform web-based framework?

Users and developers alike can agree that having an app available regardless of platform is a great ideal. But at what cost?

Let's get the conversation started!

By Daniel Rubino, Kevin Michaluk, Phil Nickinson & Rene Ritchie

  1. Daniel Daniel: Single platform success, multi-platform glory
  2. Kevin Kevin: If you can go cross-platform, you should
  3. Phil Phil: Changing is hard - fitting in on multiple platforms
  4. Rene Rene: The HTML5 app is a lie

Daniel Rubino Daniel Rubino Windows Phone Central

Single-platform success, multi-platform glory

In reality, the question is more complicated. More often than not "the next big thing" has been created by one really talented developer or a small team who simply don't have the resources, skills, or abilities to program cross-platform. We saw this early on with Instagram and Android - the company behind the app famously only had thirteen employees. Such limitations delayed an Android Instagram app for some time, and even now after being bought by Facebook for a billion dollars they still haven't released an app compatible with BlackBerry 10 or Windows Phone.

The platform must often hit some invisible and ambiguous metric by which it is considered as 'accepted' by the masses.

The small firms aren't alone here, as we often see massive media companies hesitating to build cross-platform apps. The platform in question must often hit some invisible and ambiguous metric by which it is considered as 'accepted' by the masses and only then will companies consider making an app for it. Occasionally developers who are "fans" of a particular operating system will build an app for that platform first, even if the giant marketshare isn't there. This happened with the official Disqus app for Windows Phone, which was the first (and so far only) mobile platform to get an official app from the commenting service.

So yes, companies should always strive to go cross-platform when they can, and if they can't they should reach out to developers in that community to work on a partnership. Foursquare did this when developer Zhephree independently made a Foursquare app for webOS back in 2009 and the app became the de facto Foursquare app for the platform. Unfortunately that's a rare occurrence, and too often consumers are saddled with app selections that don't include the latest or greatest simply because of their choice of mobile platform.

Would a cross-platform programming language like HTML5 or Unity for gaming help? Standards are certainly better than chaos, though as we've seen with HTML5 so far, it's been mostly hype rather than a success.

Kevin Michaluk Kevin Michaluk CrackBerry

If you can go cross-platform, you should

While there are exceptions to every rule, I really want to live in a world where the majority of mobile apps are cross-platform and just work when and where I want them to. Take the web for example. I can get to almost any web site from almost any device on the market. Facebook's website doesn't care if I'm on a Mac or Windows PC, on a smartphone or a tablet, on Android or BlackBerry 10.

As long as the platform has a modern web browser, I can get to pretty much any site I want. I can build and deploy a website to a full range of devices and everyone can see it. For the most part, if the site sticks to standards, it really does "just work".

The state of cross-platform mobile apps is quite different.

Take Android Central, CrackBerry, iMore, and Windows Phone Central. The sites use very similar code and work on most desktop or mobile browsers. Four websites, all browsers. Good deal.

But doing that with apps would mean using separate, substantially different, frameworks for Android, BlackBerry 10, iOS, and Windows Phone for each of the sites' apps. Four apps times four platforms for a total of sixteen apps. Not such a good deal.

The same can be said for accessories that rely on connected apps. The Nike+ FuelBand launched as iOS-only, yet for the investment Nike put into their hardware they ideally would support all platforms. A lot of non-iOS users could have bought one for 2012 holidays, but that the FuelBand didn't and still doesn't support other platforms limits its potential market. Users wouldn't care about cross-platform - all that would matter is that it works with their device.

Watch Leo Laporte talk about HTML5 apps and his hopes for their future.
Leo Laporte, Chief TWiT, TWiT.TV

I'm hopeful that HTML5 will be powerful and flexible enough that you can produce near-native apps in it. And if that's the case, I'd prefer HTML5.

- Leo Laporte Chief TWiT, TWiT.TV

No one wants an app on BlackBerry 10 that looks exactly like it does on iOS, and doesn't include support for BlackBerry 10 gestures.

Games are often the furthest ahead on this thanks to cross-platform engines like Unity and Titanium. However, games tend to have their own non-platform-conforming interfaces. Non-game apps are different. While apps can share common features, services, and even code between platforms, they need the platform look and feel, and can benefit from platform-specific features. No one wants an app on BlackBerry 10 that looks exactly like it does on iOS, and doesn't include support for BlackBerry 10 gestures.

In the end, if you take platform owners, manufacturers, and even developers out of the equation, people just want the apps they love on the devices they love. That means every major app needs to support every major platform. Now.

Phil Nickinson Phil Nickinson Android Central

Changing is hard - fitting in on multiple platforms

Theoretically, having the same apps on all the platforms should be a no-brainer, right? More apps in more places. But the disappointing truth is that even today not all apps are created equal.

Different platforms do things differently. Sometimes it's a matter of hardware. BlackBerry 10 and Windows Phone don't have the pure processing power of Android. Apple's iOS is arguably easier to develop for and can do more with less. And, so, an app that's available for the iPhone and iPad may have different functionality than it would on Android or BlackBerry 10 or Windows Phone. In fact, we've seen instances of popular apps that lose a significant portion of their functionality when ported from one platform to another.

The disappointing truth is that even today not all apps are created equal.

It's not always that deep, however. Sometimes it's just a matter of appearance. Maybe an app just doesn't look as good on one platform as it does another. Superficial? Perhaps. Apps should have a consistent experience across platforms. Or at least attempt to have the same experience. But they still need to have a platform experience as well. It's a tough hair to split.

The good news is that apps are fluid beasts. They're constantly changing and improving. Probably not as quickly as we'd all like, but rare is the popular application that never gets updated, never improves, and never redesigns itself.

Rene  Ritchie Rene Ritchie iMore

The HTML5 app is a lie

HTML5 apps are built using web-standard technologies like HTML, CSS, and JavaScript. These apps run in browsers, like Google Maps or, or on local devices like Chrome OS or the late, lamented webOS. Because so many developers already know how to build rich web experiences, it's generally assumed that HTML5 apps will be the easiest path to get those developers onto mobile. Hence everything from Apple's original "sweet" solution of apps in the iPhone browser to Palm's Mojo and later Enyo frameworks to BlackBerry's WebWorks.

It's led to the presumption, generally from non-developers, that HTML5 is the last, best hope for a utopian future where apps are written once and deployed everywhere, cross-platform, from desktop to tablet to phone and to everything and anything in between.

And it's a bunch of BS.

Apple's original "sweet" solution worked out so poorly that they scrambled to release the native App Store a year later, the calendar app on webOS 1.0 took twenty seconds to launch, and Google is producing far better experiences with natively-coded apps on Android and iOS than they are on the web. Even the best mobile web apps, like and, pale in comparison to their richer, better-performing native cousins.

Native apps will benefit from new hardware and new frameworks. Their lead will remain, if not grow.

Some say that as hardware gets more powerful, and JavaScript is improved, web app performance and functionality will increase. That's absolutely true. But native apps will benefit from new hardware and new frameworks as well. Their lead will remain, if not grow.

That's why HTML5 apps are called the future -- it's always coming but never quite arriving.

Trying to make an entire app in HTML5 is like trying to make an entire app that exists totally offline, in airplane mode. It's not impossible, but it's not ideal, and it greatly limits the scope and experience that can be provided.

Watch Matt and Brian talk about the difference between indie and big company developers.
Matt Bischoff and Brian Capps, iOS engineers, Lickability

If HTML5 ever becomes more prevelant than native apps, that's a world I don't want to live in.

- Matt Bischoff and Brian Capps, iOS engineers, Lickability

It comes down to this: the internet is best at providing dynamic data, and native apps are best for interface and interactivity. Great apps will use the best of both. Like iTunes. Like Google Maps for Android and iOS. Like the new native version of Facebook for mobile (even Facebook learned that lesson the hard way).

HTML5 is in no way the be-all, end-all future of apps. But it's an incredibly important part of that future.


Cross-platform applications are a tricky endeavor. Developers must navigate SDKs and APIs and UI and UX guides, while trying to maintain the unique look, features, and experience of their own app. It's a balancing act of requirements and desires, of expectations and constraints.

Ideally apps that make sense to be cross platform would be, and it would be easy to do so. But it's a cutthroat market and there's little interest from the bigger platform owners in making it easier to build apps that will work on competitors' devices, while the smaller players want to make it as easy as possible to port those very same apps.

Cross-platform frameworks and tools exist, but they're limited in scope and power. They make it easier to build a consistent experience across every platform, but sacrifice what makes each platform unique and compromise on quality and performance. But building a platform-customized apps takes time and money that not all developers have.

There's no good answer - but what's the best one?

Read more