Johannesburg, 10 Mar 2014
We work in a fragmented, multi-platform mobile environment - none more so than in South Africa. Our market is heavily skewed towards older 'feature phones', although the major smartphone vendors are increasing their market share exponentially year-on-year.
As such, organisations are faced with multiple development approaches, including native development using platform-specific toolkits and APIs; Web-based development using HTML5 and other industry-standard coding environments; and hybrid development that borrows from both approaches.
Which makes it all the more remarkable that so many organisations continue to make the mistake of looking for the holy grail of app development - a 'one-size-fits-all' solution. Niche use cases aside, it simply doesn't exist, says Nevin Shelley, senior mobile solutions architect at DVT.
Whether your app is internally focused - interfacing with or extending your enterprise applications, for example - or outward facing to engage your retail customers or general consumers, don't lose sight of what should be dictating the development agenda: your business drivers.
Don't make the common mistake of taking a technology-down approach, looking to stretch your app across multiple platforms for the broadest possible appeal by taking a design-once-deploy-many approach. The problem with this approach is that it doesn't take into account the fundamental hardware, software and app store differences between the major mobile vendors. An app developed for older Android phones, for example, will likely fail the human interface standards for iOS, or ignore the advanced hardware features of modified Android, Windows and Blackberry devices.
Should you build mobile apps in native code on each platform, or should you build them in cross-platform code, such as HTML5? Increasingly, developers are sidestepping that debate and just voting for whatever makes sense in each individual circumstance, according to a survey^1 of 3 500 developers, CIOs, and CTOs. That's a bit of a change from last year, when 94% of developers were betting on HTML5 to win.^2
In fact, 40% of developers have started building native, only to switch to HTML5, and 31% have started building cross-platform, only to switch to native.
This isn't because one platform is dominating all others, or consumers are constantly switching between different platforms and devices. It's simply prudent business practice.
According to my colleague, Ronnie Cloete, head of mobility at DVT Johannesburg, the majority of client requests are for cross-platform development, not knowing what the impact of their request entails. It is our mandate to advise clients on what technology selection will best suit their requirement.
The sooner an organisation can publish its app, the sooner it can generate returns on its investment. The quickest way to getting an app published in its native app store is by developing it using native tools. Any other approach often means months of tweaking before the app meets the strict usability and interface requirements set by the different platform vendors.
Moreover, the typical life cycle of a published application is approximately five weeks. That's how long users expect to wait between app refreshes before they start looking elsewhere for more suitable solutions. Native development means that ongoing maintenance and feature upgrades can be added relatively quickly and cost-effectively. Any other approach could result in unforeseen delays, unexpected costs, or worse.
Other factors that play a role in mobile development approach include time-to-market - which takes into account the enterprise application submission process into app stores, an organisation's defined mobile strategy and mobile governance, business mobile policy, infrastructure policy, development capability and enterprise mobile management.
In summary, follow an established process for down-selecting the type of mobile application (native, HTML5 or hybrid), and decide if the intended audience is B2E (enterprise-enabled applications) or B2C (consumer applications). Native development is the quickest - and therefore most cost-effective - path to unlocking the strategic value of a new app. Depending on the use case, there's definitely an argument to be made for choosing a different path, but regardless of the approach you choose, trying to tick all the boxes at once is almost always an expensive, and ultimately futile, exercise.
Share