by Steve Tarzia
Perhaps the biggest challenge that today’s software companies face is in supporting the multitude of mobile platforms on the market. Everyone wants their software to run on dozens of popular Android phones, iPhone, iPad, Blackberry 7 and 10, Windows phone, etc. But these platforms are all drastically different.
Software companies and indie developers have two basic choices:
Writing “native” apps, meaning a different codebase for each platform. That’s a lot of work.
Writing a “cross-platform” app using one of several tools to write code that runs on several platforms.
In this post I’ll explain why we chose the first. This “cross-platform” question comes up again and again because the potential cost savings are huge. We’ve done a lot of research, so here goes:
The summary: You can’t do better than native
None of the platform vendors (neither Apple, nor Google, Blackberry, Microsoft, etc.) make your job easy. As far as development goes, they all live in their own bubbles. The platform vendors expect you to be writing native code using native libraries. If you’re obsessive about your app’s design and user experience (and you should be!) then you have no choice but native.
A footnote on Blackberry 10
Blackberry 10 is an exception to the bubble rule – they acknowledge that you might have already written an Android app, and they must have realized it would be great if you could just run it on Blackberry 10 as-is. Blackberry 10 was so late to the game that they had little choice here. However, there seems to be a lot missing from their Android support, and, after all, your Android app will look out of place on a Blackberry. We tried it – no dice.
The deal-killers
I’ll focus on the disadvantages of each cross-platform approach because the advantage is obvious – reduced development effort. This could mean either hiring fewer developers or putting more resources into new features and improvements. We experimented with various cross-platform development tools, but the bulk of my conclusions come from downloading and playing around with apps featured on each of the tool vendor’s web sites. The logic is that these featured apps must represent close to the very best you can achieve. We tried these featured apps on both Android and iPhone.
PhoneGap, Sencha Touch and other HTML5 approaches
HTML5 is a powerful tool for creating rich web content. Unfortunately, it renders incrementally like a web page. That is, the buttons, text, and graphics pop on the screen individually, from top to bottom and with some re-layouts occuring while it was rendering. This rendering process only takes a split second but it is still noticeable and unacceptable. By contrast, screens for native apps are rendered before they are shown. Untappd (representing PhoneGap) and Getographer (representing Sencha Touch) seemed to be good examples of their respective technologies.
Marmalade – converting to native controls
Marmalade allows you to write apps that magically look native on each platform. Your switches, buttons, and tables are converted into the native equivalent on each platform. The problem here is that the size of these controls is different on each platform, so the layout is never going to look quite right on all platforms. It’s difficult enough to get the layout precisely correct in a native Android app (because of the variety of screen resolutions, pixel densities, and keyboard sizes); you really don’t want to exacerbate this problem. I’m talking about difficult layouts involving dynamic content such detail popovers or auto-completion tables. Tweaking the layout to work on every Andoid device plus iOS, Blackberry, and others sounds like a nightmare.
OpenGL
Game developers actually have an easier time supporting multiple platforms because they generally don’t use any native controls. Most games use a full-screen OpenGL view and use custom-drawn buttons, scrollers, and popup windows. Of course, game design shops have the graphic design resources to do this, and there is no expectation that the app will look native. In fact, games are meant to be immersive experiences – the developers want you to forget you’re using an iPhone at all and custom controls help to achieve this immersion and distraction. So, you could write a cross-platform calendar or file-sharing app in OpenGL using made-from-scratch controls but it would be difficult and would create the wrong experience.
Conclusion
The various cross-platforms tools are each very sophisticated and are brilliant technical achievements in their own ways. If your app is a game, then go for it. If your app has simple, static screens and rendering performance is unimportant, then, by all means, use one of the cross-platform tools. But if your app is the primary way your customers interact your brand then you need more than a simply functional app – you need a carefully-designed, native app.