Hedge your bets when you make your apps mobile

Every smartphone platform is different, but the tools you use might not be Credit: image credit: http://www.flickr.com/photos/garryknight/

With Mobile World Congress just round the corner, smartphone adoption hitting 50% in the US, and BlackBerry 10 and Jolla soon to join the list of smartphone platforms, what should you be doing if you have a tool you'd like to move to mobile?

Start planning first.

Think you only have two or three platforms to consider with mobile? Leaving aside the perennial argument over whether Windows Phone 8 or BlackBerry 10 is going to take third place behind iOS and Android (and ignoring Firefox Mobile, Jolla, and next year's Ubuntu phone for the moment), you still have to think about HTML5 (different on every mobile platform) and cross-platform frameworks (like PhoneGap and Sencha) and engines (like Unity and Marmalade). Or you can use cross-platform tools like Appcelerator and Xamarin that try to take you from development to deployment and management -- something that's more important when you're developing apps to get used inside a business.

Worldwide, Android leads the Smartphone market.

Add in all the different SDKs and app development tools you might be using, and there are over 500 options that might be the right one for you. With around 500,000 mobile app developers across the different platforms, that's one developer tool supplier for every 1,000 developers -- which is a sure sign that plenty of those tools won't be around for long.

So how do you pick what to use?

Even if you're creating apps to help you get your job done rather than to make money, Vision Mobile's Developer Economics reports (and the accompanying Developer Economics site) are full of useful insights into what's working for mobile developers. The latest report, out this month, concentrates on what tools mobile developers are using and why -- and the tools that make them the most money translate into the tools that should give you the best results too. (It's also a handy guide to what those 500+ tools actually do.)

If you know your users, or if you're mainly developing for yourself, it may be obvious which mobile platform to develop for first. Developers who are selling applications concentrate on iOS and Android, which have 46% of smartphone marketshare, 98% of handset profits, and 80% of developer attention. Worldwide (the survey behind the report includes Asian developers who are less interested in iOS), 72% of developers are writing for Android, 47% of developers are planning to create apps for Windows Phone, and 15% say they will adopt BlackBerry 10 as their next platform. Bad news for Microsoft: developers still see BlackBerry as a main platform and Windows Phone as a platform they develop for "on the side."

But there's already a strong "third platform" for developers: HTML5.

50% of developers use HTML, either to create mobile web apps or to write HTML code that they wrap to build a hybrid or native app. Half of those consider HTML to be the main platform they develop for; the other half treat it as a way to take an app they make for their main platform to other devices.

Developers see HTML as a significant mobile platform -- but it's not just one platform.

Not all those HTML5 developers are happy with the state of web development for mobile. They like the portability and low cost of development. And mobile developers earn more revenue a month than developers crafting apps for one platform (or one platform at a time); factor in the cheaper development costs and that should mean even higher profits for developers using cross-platform tools. That's not just for games, either -- in fact, developers using cross-platform game engines like Unity and Marmalade are earning slightly less-than-average revenue, and developers using tools like Appcelerator, AppMobi, Brightcove, PhoneGap and Sencha are earning significantly more revenue.

But these developers say they want better tools, better debugging, and more access to native APIs. Better API access is always challenging because cross-platform tools like PhoneGap and even in-house web development tools like BlackBerry BBUI.js (which replicates the BlackBerry 10 Cascades interface) don't get access to those APIs until after they're available to native development tools.

How developers choose cross-platform tools

Some cross-platform tools have more native APIs and let you make the interface of your app look more like one that's built specifically for each platform; developers who pick their tools to get those features make more money than the ones who pick tools that support more third-party extensions and programming languages. That makes sense. Being able to use your favorite language and your favorite library makes your life easier as a developer --  but an app that looks, feels, and works as if belongs on my phone makes me happier as a user.

Don’t mistake WebKit for the mobile web

If you pick HTML5 as your mobile development platform on the grounds that every phone has a browser, remember that not every mobile browser is based on WebKit. Even if every mobile browser you care about has the WebKit rendering engine inside, Mobile Safari, Mobile Chrome, and the Android browser aren't the same -- let alone BlackBerry 7 Torch, BlackBerry 10, Tizen, the Amazon Kindle browser, Bada's Dolfin browser, WebOS, LG's Phantom, Nokia's Symbian and S40 browsers (the Quirks Mode site has a handy cheat sheet covering the older mobile WebKit browsers).

You'd expect capabilities of the different mobile browsers to vary, even when they're based on WebKit; use the comparison option on the HTML5 Test site to see how they stack up, three at a time.

For instance, this is Android 4.0, Windows Phone 8 and iOS 6 and you might be surprised at the scores. But you might be even more surprised that the WebKit-based layout engines don't give quite the same result; different Webkit browsers don't even have the same layout bugs. The Quirks Mode test results for selectors and columns alone show the lack of compatibility between different WebKit-based mobile browsers.

Do your users -- and your future self -- a favor. Don't assume you only need to care about mobile WebKit browsers. Use unprefixed HTML5 tags whenever they're available and use libraries like Modernizr to get the prefixed versions of tags for all the main browser vendors. Although it explicitly covers only Microsoft prefixes, the tips in this guide to adapting a WebKit-optimized site shows what you should be doing for all browsers.

Don't have all the phones you want to test on? Sign up for three free months on the BrowserStack service courtesy of Microsoft at the Modern IE site. This doesn't get you every mobile browser, but it covers iOS up to version 6, Android on multiple phones and tablets, Opera Mobile and the touch version of IE 10 on Windows 8. The Windows Phone SDK includes a phone emulator with the mobile version of IE 10 and if you want to test in the BlackBerry and PlayBook browsers you can do it with the Ripple emulator (it's a Chrome extension that also emulates PhoneGap).

And if the thought of testing on and supporting multiple mobile browsers makes you think twice, remember that "write once, run anywhere" is a myth. Your choices are "write once, suck everywhere" (pick the lowest common denominator), "write once, optimize everywhere" (which gives you the most control but also the most work) or "write once, outsource the optimization" (go back to thinking about cross-platform tools like PhoneGap and Appcelerator). 

Join the discussion
Be the first to comment on this article. Our Commenting Policies