If you want to develop smartphone apps across multiple platforms and devices, how do you go about it? Here are seven top tips to keep you on track.
1. Consider why you’re doing it
Just because Android is funky doesn’t mean you have to port your iPhone app to it. In Australia, iOS is still far more utilised than Android despite what the vendors want you to believe; and make sure you don’t forget other popular platforms like BlackBerry OS or even Nokia’s Symbian.
“I’ve had a number of times where I’ve got a client that desperately wants an Android app and you say 'why?' and they say ‘Android’s cool; I have an Android phone’,” says Frank Farrall, a partner within Deloitte's consulting arm. “It’s not that Android has any penetration in the Australian marketplace or has any strategic relevance to what they’re trying to do; it’s because they think it’s cool. And that’s not the right way. If our clients are doing a consumer app, we tell them iPhone; if a business app, BlackBerry. And they should keep a watching brief on the others."
2. Architect carefully from the start
As with all things, consider the structure of your final application before you start coding. Monolithic apps are a real pain to recode or adapt for a new platform, but by separating business functions you can simplify the process and speed your move to another platform if you want.
“With Go Gorilla! I’d already isolated the game logic,” says developer Scott Powell. “By the time it came to the BlackBerry version it was trivial to write; I had written implementations for how you load and play sounds, draw bitmaps, and so on. Before you write your code try and isolate the various parts of the program, and abstract it as much as you can. Especially if you know you’re going to be hitting multiple platforms, it saves you a lot of headaches."
3. Abstract your data
Just as you can design your app’s architecture more flexibly, it’s a good idea to consider where your data should be stored, and how. 2moromobile, for example, built its music-festival apps so all application data is stored in a SQL database that can easily be updated remotely, or accessed by clients on different smartphone OSs, without having to be re-ported. This approach is also typical of web apps, but in both cases it’s important as always to consider mobile coverage in the intended usage area.
“Each code is a separate rewrite, so management is through a configuration interface and it all reads off a centralised configuration interface,” says Derk Munneke, chief technical officer of 2moromobile. “In the repository we’re keeping different data and components for each platform. If I want a bio summary page I’ll tell it this is the URL to read, pattern to read the data from and so on. It’s not really sharing code; it's sharing configuration and data.”
4. Manage your image assets
No matter what app you’re building, you’re going to have some or lots of images within it. However, not all platforms make it easy to reuse the same images. Make sure you know exactly what images you need – and in what size, format and colour depth – for the platforms you’re targeting.
“Apple makes it easy to work across iPhone and iPad,” says Deloitte senior analyst and iOS and .NET developer Sadat Rahman. “With different users and assets you just make them different sizes and don’t have to touch the code; Apple’s APIs pick them up. But if you look across different platforms, it’s actually fairly tricky.”
5. Consider HTML5
Sure, there are a number of apps that need low-level access to your device’s hardware. But many apps are more than acceptable when built as HTML5 apps. Although it’s a good idea to be competent in building for at least one smartphone OS, ever-more-capable HTML5 may be a perfectly acceptable common denominator across numerous other platforms.
“HTML5 and browser capabilities are getting better and better all the time,” says Daniel Bradby, director of Melbourne-based development house jTribe. “We would do web apps before taking on another platform. The libraries need to mature a bit, but what I like about it is it's an industry specification rather than something from a single company. Because it’s an industry-wide specification, there are more likely to be libraries and support in the long term.”
6. Watch the user interface
When moving from one platform to another, it’s important to avoid building exactly the same user interface. Android phones, for example, are big on buttons while BlackBerry apps tend to favour keyboards in many situations. Make sure your designers realise this, and don’t let your developers simply rebuild your iPhone app on another platform. In the end, the functionality of any app should reflect the visual and interactive design conventions of the platform it’s running on.
“Even when people do underlying code ports from iPhone to Android, they get stuck trying to develop the app in the style of the other platform. You’ll see a few Android apps that look like iPhone apps; they’ve had to work against the grain to make that happen, and there’s no reason for that to occur,” says Farrall.
7. Manage your team skills
It’s extremely difficult for one developer to be fluent in a range of platforms, but a team of developers will cover the bases most effectively.
“You’ve got to have at least two platforms under your belt because it just makes you a lot more flexible,” says Farrall. “When you’re hiring guys with skills and pairing them with guys that have interests and relevant skills, within months you end up having a 10 to 12 person development team. Each may do a Java-based CMS project, then maybe a BlackBerry app, then go back to the CMS; it keeps your skills fresh and ties in your mobility skills to the traditional online channel.”