I’ve been working for the last few weeks on a mobile application that’s rather niche (so not an app store favourite), but will be used by a lots of users in a large firm to get their job done quicker and more efficiently. Before we started, we wrestled with the “how to do it” – what technologies we should use etc – and damn it, it’s been a really hard call.
On one side, you’ve got the ardent supporters of the native application, and on the other, the cross platformist web based applicationistas slinging vitriol at one-another.
Both side have their good points (which they endlessly prattle on about), and bad points (which are avoided at all costs) – but each side is very far from perfect. So how can you hope to navigate a path without becoming a fundamentalist?
So, what seem to be the current options?
1. Write an application in the devices’ native language
This will probably provide the best user experience, but throws up so many pitfalls that you have to question if the improvements in UI/UX are worth it. Our biggest moment of consternation was the target platform (as it had to be a tablet) – and this is by far the least clear cut of all arguments. At the moment, the iPad is the clear winner in regard the market share stakes; but a lead is never unassailable. So if you have long term plans for an application (i.e. it’s more than a 15 minutes throw-away endeavour), what camp do you pitch your tent in?
This can’t be swayed by ones love for a platform or language because the real world doesn’t care for such things.
There seems to be lots of talk about this of late; as the web browser is the only truly cross platform engine currently available (or course it has it’s problems – all browsers aren’t equal), but it’s hard to beat the single source implementation of this approach.
The biggest pitfall is the UI/UX – you just can’t quite do everything that the platform does natively – and in this case that’s proved to be a pain. Storage space is also limited, and connectivity is trixy (the application was going to produce and require and awful lot of data), and needed a rock solid offline mode.
3. Cross compile
But before I start sounding like a convert to this third way, the outcome hasn’t been as easy as we first thought. Firstly, support for Android has been somewhat sketchy, and the documentation doesn’t highlight this at all – so I’m constantly needing to find ways to get something that was easy on the iPad version, working in Android. Secondly, it still doesn’t solve which version of Android to target, and unless you make hard calls on which one/device to choose, you’ll end up driving yourself mad (perhaps that’s a little melodramatic), at least a little crazy. You are also locked into the fortunes of Appcelerator – though this is slightly mitigated by having the native code to use later if you so desire.
So why Appcelerator?
When we considered the above, it turned out the be rather simple. The first reason was the ability to use native UI (which was something of a client requirement in the end), the second was the storage space, and the third was that it left the options open down the line to take the code in any direction required (single source).
But that’s not going to be right for everyone – this was our experience, hopefully the things we considered will be useful in helping you to make a choice.