Determining a Successful Mobile Strategy for Your Business - Part 2

Native application drawbacks

The moderation process on app stores has been a contentious issue ever since its inception. If an app on the Apple app store is found to go outside the boundaries of what it deems acceptable, it has no obligation to allow it entry. In fact, the apps are totally at the mercy of the app store gate keepers, which can be a daunting prospect considering how much a client may have spent to develop it in the first place. Whether it is accepted or not is just one part of the problem - the duration of this review process can be deemed excessive. This can be a problem if there is a mission critical update that needs to be applied to an existing instance of an app, or when there is a particular date in mind for app store introduction.

If your app is looking to make money directly from the app store, don’t forget to factor in the commission. With the two main app stores (Apple and Android) both charging 30%, it is imperative that your figures take this into account, on top of any development costs.

The biggest problem with native app development is unquestionably fragmentation - the need to develop across multiple platforms. The budget would need to cover the cost of an objective C programmer (iOS), a Java programmer (Android/Blackberry), a C# programmer (Windows) and so on. Needless to say, this is an expensive proposal, but the costs don’t just stop after the initial development either. The resources required to also maintain and keep all of these separate platform apps supported can be overwhelming. In a report by the BBC, the Financial Times had been quoted as saying that their future app development would be web focused for this very reason.

This has prompted services and tools to be created which aim to ease the development process. Products such as Appcelerator Titanium allow developers to write native apps purely by using JavaScript (with a mixture of native code if necessary). Using a complex process, it is then compiled into the required code for the various mobile platforms. Appcelerator in particular boasts applications built with its technology for the likes of Cisco, eBay and Orange. Whilst this sounds convincing; it can come at a cost.

There have been mixed reports from particular development circles using this process. Some of the more notable points have been that such frameworks will always be slower to adopt access to new features as they are released by the platform providers – meaning fully native developers will be able to use new features first. What is more, there appears to be a theme that with Titanium in particular, an app is developed to a lowest common denominator of features between platforms, suggesting that platform specific features should be avoided. Time spent researching and fixing obscurities between the platforms can even overrun the time it would have taken to develop them natively. This suggests some projects may indeed require a fully native built application pending complexity.

The conclusion to Chris Bell’s mobile strategy article will follow shortly.