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 , , &
Play
Cross-Platform
Articles navigation
- Cross-platform for more
- Going cross-platform
- Video: Leo Laporte
- Cross-downsides
- Html5 apps
- Video: Matt Bischoff and Brian Capps
- Conclusion
- Comments
- To top
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.
Cross-platform explosion
When Instagram launched on October 6, 2010, it shuffled into the iOS App Store along with more than a quarter million other apps. Starting with zero users, Instagram quickly built a niche photography-centric community around its iPhone-only app, within three months hitting more than a million registered users. In eighteen months, Instagram - on just the iPhone - hit 30 million users who and uploaded more than a billion photos.
That same month Instagram launched their Android app, the service's first venture outside of Apple's ecosystem. Bringing Instagram to Android more than doubled the potential addressable market of users. In less than a year the registered user count for Instagram had soared to over 100 million.
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.
Q:
What will it take to get every app on every platform?
313
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.
Build all of the apps
Social networks that started on the web tend to be the quintessential cross-platform unified experience kings. Facebook and Twitter have put considerable effort into producing apps for Android, BlackBerry 10, iOS, and Windows Phone that maintain the same look and feel across platforms.
While Twitter has taken the development lead for their apps on the major platforms, Facebook has been content to let the smaller platform builders build do it for them. Both BlackBerry and Windows Phone are responsible for their platforms' Facebook apps, even though they adhere to Facebook's user interface style.
Facebook, for their part, has been busy pushing out substantial updates in the form of their Messenger apps and the Facebook Home replacement launcher for Android.
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.
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.
Q:
Are there apps that shouldn't go cross-platform?
1212
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.
Blending in, standing out
There are two schools of thought when it comes to cross-platform apps: adopt the platform's native user interface language, or chart your own course.
There are benefits and detractions to each. Building an app in the native interface means that it should be accessible to users of that platform, and the fanatics won't complain about it being 'different' (see Android: Holo, Windows Phone: Modern). The developer gets to use the user interface assets of the platform instead of rebuilding them yet again.
While platform familiarity is gained, it's lost for the service. Rebuilding interface elements for each app is a lot of work, but more and more cross-platform developers are building apps that feel more like their service than the platform. It's the difference between using Facebook and Facebook for Android.
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.
Q:
Talk Mobile Survey: The state of mobile apps
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 iCloud.com, 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.
Web to native migration
With more than a billion registered users, Facebook is by far the largest and most successful social network to grace the internet. But until recently, Facebook's efforts on mobile stumbled. Both the iPhone and Android apps were heavily reliant on web-based coding, with the idea that doing so would allow greater flexibility with less work.
In the end, consistency and experience quality proved to be more important, with Facebook releasing natively-coded apps for iOS and Android, and even building a Facebook-style interface for the radically different Windows Phone and BlackBerry 10.
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 Gmail.com and forecast.io, 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.
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.
Q:
Will web apps ever be able to compete with native apps?
1313
Conclusion
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?
