We explore the difficult process of developing apps for multiple platforms. It's a lot of work, sure, but there are benefits if you dig your heels in.
Scott Powell doesn’t care much for iOS, the operating system powering Apple’s iPhone, iPod touch and iPad. Yet his objections are not the result of dogma as much as practicality: as a developer of mobile applications since the late 1990s, Powell is familiar enough with development on Windows Mobile, BlackBerry OS, Palm and now Android that he can see the issues that iOS introduces to the development process.
“Going to iPhone development feels like a backwards step from programming in managed environments like Java and .NET, where memory management, exception handling and the like are automatic,” explains Powell, a professional developer who has built for both BlackBerry and Android with games like Go Gorilla! and BlackBerry Super Apps Challenge finalist GPS Fox Hunt, which he promotes through his venture SpleenWare
Vlado Grancaric (centre), manager of consulting with Deloitte, with dev teammates Frank Farral (left) and Sadat Rahman (right): “You’ve got to think about the cases where you’re building for different platforms. It’s been a new frontier for our user experience designers, because each device has its own way of doing things, and its own interactions.”
“The iPhone stuff is still in the dark ages in terms of programming environments: you’ve got to keep track of everything,” he continues. “Objective C tries to make sure everybody understands who’s responsible for freeing up what, but it feels like going backwards; being able to have Java-like memory management makes a big difference for developers.”
The multi-platform mandate
In a rapidly-growing market where iPhone support is the de rigeur standard for developers and a necessary step to access the world’s largest and most successful App Store, Powell’s comments may sound like heresy. But with Android having rapidly emerged as a viable alternative over the past year, it reflects the growing realisation among many developers that iOS is no longer the be-all and end-all of mobile operating systems.
Figures from analyst firms paint a very different picture this year than last, with massive growth across the board. Recent Gartner figures, for example, noted Android-based devices accounted for 22.7% of the 296.6m smartphones shipped in 2010, compared with market leader Symbian at 37.6%, Research In Motion with 16.0%, iOS with 15.7%, and Microsoft with 4.2%.
Phone sales and app sales are two different things, however. The success of Apple’s App Store means most developers recognise – however grudgingly – that iPhone skills are all but mandatory to get where the money is. Yet as Android gains legitimacy; Research In Motion works to re-energise its BlackBerry strategy with a tablet-focused derivative; and the implications of the recent Microsoft-Nokia alliance become clear; developers are increasingly weighing up the best strategies for taking their prized apps to more than one platform.
Indeed, it’s increasingly common for major smartphone apps to come in iOS and Android versions, with BlackBerry versions also relatively common for some games and apps that target that platform’s stereotypically business-focused audience. “Most of our clients really want to deploy on two platforms now, whereas twelve months ago it was just iPhone or just Android,” says Daniel Bradby, director of Melbourne-based development house jTribe, which recently added the official Australian Open iPad app to its portfolio.
Needing to build and maintain two or more versions of a smartphone app raises the difficulty level of many development projects significantly, particularly for small developers. “iOS and Android are very different platforms," says Bradby. "Someone who's skilled in Java say, doing Android, is not necessarily and unlikely to understand the Objective C and XCode development environment for iOS. Having a team of developers that can maintain both of those code bases is difficult; there’s no way we can do native development on more than two platforms.”
The net result is that many projects effectively need to be written twice to support both platforms – although lessons learnt from the first instance can typically be applied to the second project, which can be completed in 70% of the time of the first.
This may save money for clients, but it also means developers need to expand their skill sets and their project scopes to keep up with the demands of a market that continues to grow by leaps and bounds. Those wanting to simultaneously manage iOS, Android or BlackBerry versions of their apps – or to explore niche mobile environments like Nokia’s Symbian^3 and upcoming Meego, HP’s WebOS or Samsung’s Bada – need to both revisit their coding strategies and skills, and lay down clear guidelines for managing apps on two or more platforms at the same time.
Depending on the platforms you choose to support, the effort of moving from one platform to another varies significantly. The fact that BlackBerry, Android and Nokia all support Java, for example, means that experienced Java programmers may have a pretty good idea how to transfer application logic between the devices. After all, cross-platform compatibility was one of the original selling points for Java, and having a mature code base in Java can get you a long way ahead in the move to a new platform.
Yet simply working in Java is no guarantee of hitting a six: each operating system has its own idiosyncratic APIs, parameter calls and so on. And, despite commonalities in code that made Go Gorilla! relatively straightforward to port to Android, Powell found that architectural differences – for example, Android sets up its GPS handler like a remote process and has to be called from apps as though it’s on a separate machine – meant that rewriting was far from simple. “The two architectures are so different that I couldn’t share much code,” he says.
Despite their similarities, there are real and practical differences between iOS’s Xcode development environment and Objective C language, and the Eclipse-Java combination favoured by developers on Android, Symbian and other platforms. Not all developers have the knowledge or inclination to learn completely new platforms, however – and this reticence is only getting bigger as so many options come into the market. Little wonder that many developers are looking for easier ways to build apps that run across platforms.
Titanium has proved invaluable for developers like Tammy Butow
, who along with two co-collaborators uses it to build music apps in parallel for iOS and Android without having to worry about the nuances of each platform. "I was originally doing web development but I wanted to build for both iPhone and Android, and make it as quickly as possible," she explains. "I looked at Objective C and bought a book and did a bunch of tutorials, but realised it was going to be easier to use Titanium. I like doing rapid prototyping, which is fun if you're doing it as a side thing as we are."
Titanium has also worked a treat for developer Wayne Buchner
, who recently used it to develop an iPhone app for the Golf Australia’s Handa Women’s Australian Open tournament.
“The Titanium platform is terrific if you don’t want to go to the extent of learning Objective C or Java, which a lot of people will do,” explains Buchner, a long-time web developer who’s making the transition to smartphone development. “My long-term goal is to be a native Java or iPhone developer – but until then, it definitely allows you to use your Web skills to develop mobile apps that Apple has no problem approving or putting up on the store.”
Titanium isn’t the only multi-platform option on the scene: an increasingly popular alternative – and one that’s likely to become even more so as the proliferation of mobile operating systems complicates life for developers even more – is to use industry-standard HTML5 to build web apps. HTML5 is already well-supported amongst web browser makers, and becoming even more so as tablet makers work to refine the user experience in their large form-factor devices.
HTML5 apps need to be hosted, however, and that means stepping outside the app stores where customers can find them. For this reason, many developers are turning to tools like PhoneGap
PhoneGap may provide an important bridge between web development skills and smartphone deployment, but its capabilities vary depending on the target platform. For example, built-in compass is only supported on iPhone and Android platforms; audio recording is only supported on Android; cameras are not supported on Palm and Windows Mobile; and so on.
Butow has also tried PhoneGap but prefers Titanium: "PhoneGap is really easy to set up but I found it a bit hard to do things like calling native components for the iPhone, or calling tabs, and so on," she explains. "It didn't have as much documentation, and Titanium has been way better."
Developers are working closely to extend the PhoneGap libraries to utilise new features as they emerge, but there’s always going to be a gap between the capabilities of the native platforms and those supported by intermediary tools. This gap may be less important to many developers than the benefits of easy cross-platform deployment, but more demanding developers almost invariably find the platforms too limited for their requirements.
“We’re not convinced yet that these frameworks are mature enough to add the value they could,” says Frank Farrall, a partner within Deloitt's consulting arm, which is seeing “almost ridiculous” growth in demand for mobile apps and has recently completed projects for clients including the ANZ Bank, Australia Post and the Victorian government.
There, a growing team of developers has recently been ramping up mobile development capabilities. “It’s a step in the right direction for sharing business logic, but we’re concerned about being able to deliver the same level of user experience that you could through a native app," Farrall says. "You might save tens of thousands of dollars using a framework, but you might also come up with a less appropriate user experience. For now, we’re advising clients to keep a watching brief on these tools and see how they come together – but as it stands right now, they’re not ready for prime time.”
Bradby agrees: “We do all native development, because we want to give the users an experience that they're used to on that platform," he explains. "Our concern with using cross-platform tools is that you're developing with a lowest common denominator that would only allow you to write to something that both platforms would understand, and there would be compromises on the way. Our Australian Open iPad app, for example, provides a very deep user experience and there’s no way we could get that out of HTML or a cross-platform tool. If you’re developing on the Android platform, you want to be close to the metal.”
That expression doesn’t come from nowhere: Google’s new ‘Honeycomb’ v3.0 of Android incorporates a feature called Renderscript that allows for high-performance graphics manipulation by shunting complex graphics processes to any available graphics processing unit (GPU). Programming it requires some intimate knowledge of Android, and it’s unlikely that Renderscript would be easy or even possible to port to other platforms.
The lack of such capabilities is one reason why some believe cross-platform tools will struggle to keep up. “Games will always be performance hungry, and you immediately have to go down from these high-level tools,” says Powell. “There’s just too many layers between you and the hardware or native framework, and typically the performance is just too weak.”
That may change, however, as games engines like Unity and Unreal bring highly-optimised, flexible graphics environments to a range of platforms. Their inevitable transition to tablet operating systems will open up new opportunities for developers like Luke Kellett, whose small team at RUMA Studios is using Unity to build a cross-platform 3D game and is more than happy with its 60 frames-per-second performance on the iPad. “We do have a bit of a performance hit, but we don’t spend 80% of our time developing an engine and just 20% of our time developing the app,” he says.
Look and feel compromises
Indeed, user perception is one of the major areas developers need to consider when crossing from one platform to another. Particularly given the iPhone’s market dominance, many developers start building for a secondary or tertiary platform and get locked into the mindset that they must make Android or other platforms their iPhone counterparts.
This approach may make sense to some developers, but it creates major issues for users that find themselves trying to use an app that doesn’t make intuitive use of non-software features such as button layouts or screen dimensions. An Android app that doesn’t make use of its devices’ back button, for example, is going to come off as counterintuitive for users and affect the strength of the app and its parent brand.
“Before, the frontier was web sites,” says Vlado Grancaric, manager of consulting with Deloitte. “Different browsers did different things. But now it’s the mobile side of things. You’ve got to think about the cases where you’re building for different platforms. It’s been a new frontier for our user experience designers, because each device has its own way of doing things, and its own interactions.”
Catering for these differences can tax the patience of designers, as the Deloitte team found out: while prototyping its new Bamboo incident-response management system, the team not only found out that it had to hard-code some business-related functionality in the Android version that was built into BlackBerry OS, but found that its designers’ efforts to replicate the iPhone version had produced an inadequate final product.
“We tried to replicated it and ended up going ‘That doesn’t work’,” Grancaric recalls. “We went back to designers and said we need an iPhone design, an Android design, and a BlackBerry design. We want to make sure that whoever’s picking that app up knows how to use it based on the device they’re on – as opposed to saying ‘this is just an iPhone app ported to Android’.”
The differences become even greater when considering platforms with decidedly different appearance: iOS and Android have many aesthetic similarities, for example, but Microsoft’s Windows Phone 7 uses a completely different panel-based interface; Nokia’s interface is different still; and BlackBerry OS still de-emphasises complex on-screen keyboards for physical keyboards in the majority of devices that support them.
One way to minimise the complexity of the transition is to architect your apps in as modular a design as possible, so that data structures are kept separate from presentation structures. This makes it easier to map the data onto new presentation structures without having to totally rewrite the code, says Derk Munneke, chief technical officer of 2moromobile
, whose client list includes the Heart Foundation, Nova FM, Murdoch Books, and Toyota.
2moromobile used such an approach for its womadelaide app, which fed relevant and updated festival information from a SQLLite database to an iPhone app that’s now being transferred to Android and, eventually, Windows Phone 7.
“It will be interesting mapping to Windows Phone 7, but it’s a really good example of why the component-based approach works,” says Munneke. “The component encapsulates a behaviour, and we can use an app configuration tool to plug components together. The actual application becomes cross-platform and each component is platform-specific – and designed to act in the way that that platform acts.”
Buchner took a similar approach when designing his golf app: “There are live specials from the sponsors, new backgrounds, and so on,” he says. “A lot of that can be controlled through a remote file that the app goes to and retrieves data that you can’t build into the phones. You just can’t retrieve updates willy-nilly.”
With multi-platform development becoming more and more important, it's worth thinking now about how easily your apps might make the jump. There’s no one single way to break onto another platform, and tools are only one part of the effort. Yet by building your skills, assembling appropriate teams of developers, and following a range of other tips (see sidebar), it’s possible to both bring your apps to a new platform, and keep them at feature parity. Plan carefully from the start and make the effort to keep up with the platforms your clients demand, and you’ll find you really can have the best of both worlds.