Mobile is on the rise, and one of the early decisions in building a mobile app is which platform to go after, using which technology -- iOS or Android, native or translation layer (aka "HTML app").

Translation layers are a great option because of the promise of being able to target different platforms with a single codebase. I'm a fan of Appcelerator's Titanium platform for businessy/workflow apps -- basically everything except games. I hear that Unity is the choice for games, but I have no experience with it.

I like these platforms under certain circumstances, even though they've gotten a bad rap. Those complaints usually take one of two forms: the app is slow, and the translation layer adds bugs. I think these complaints are invalid for a few reasons.

I personally see a lot of apps. I see fast apps built with the translation platforms, and slow apps built with native code, in direct contradiction to the stereotypes. One of Cloudspace's iOS engineers has shown me a demo where some simple settings in native iOS code has a huge performance impact, and most developers don't know to use them, which means their apps run slowly! There are reasons to choose native iOS, but native doesn't necessarily mean fast.

The "bugs" complaint is equally dismissible. In a surprising number of cases, the bug is actually in the native platform, but the translation layers get the finger pointed because they're the ones displaying an error -- even though it isn't their bug. It's a case of shooting the messenger.

There's a better way to approach the native-vs-translation-layer question. A translation layer like Titanium is a very good fit under certain circumstances:

• simple UI - when the UI is straightforward translation layers can be a good fit. Complex UIs must be re-built for each platform to meet UI guidelines, and translation layers don't help with nonstandard UIs. If the UI is simple and won't require extensive re-building, it's a sign that a translation layer is a good fit
• complex backend logic - Unlike UI guidelines, logic is very portable. This is where translation layers shine. If you have to produce a complicated algorithm, or have many data types being handled, being able to port that with few-if-any changes is a huge time and cost savings upfront, as well as during maintenance.
• multi-platform targets - If your target market is necessarily spread across multiple devices, a single team working with a cross-platform solution is more effective than one that needs to know several languages and platforms. Software businesses whose end-user is at a company with a BYOD policy should especially consider translation platforms for their apps, given the variety of devices they may have to handle.
• limited development bandwidth - Similar to the multi-platform point. Some companies can afford 2-4 separate development teams. Others cannot, but still need to target many devices.

This discussion is bound to get more complex and relevant in the next 12-24 months. Blackberry isn't dead yet (platform #3), Windows is likely to grow (platform #4), and there's the (still early, but interesting) Firefox OS, giving us #5. Translation layers are going to become more relevant.

If you've decided that native is the route for you, or you already have an app but want to target another platform, please get in touch. We can port your app from iOS to Android, or Android to iOS.