Computing research: Routes to mobility
Source: John Leonard

The sudden arrival of smart mobile devices four years ago proved to be a real shot in the arm for the art of software development, inspiring a massive creative surge among amateur and professional coders alike.

Similar spikes occurred during the previous IT gold rushes in the 1980s when home computing arrived, and in the late 1990s with the start of the commercial internet. Then as now, many businesses were left floundering as to the best strategy to take. There are big differences between both PC and mobile and consumer and business applications.

Like many of the early 8-bit games and utility applications coded in bedrooms and garages back in the day, there are far more lumps of useless rock than there are nuggets of gold in the online app stores, but for the consumer this is not a problem. The availability of lots of free alternatives means that people have become accustomed to downloading an app, trying it for a minute or two then deleting it if it fails to live up to expectations. So user experience (UX) is all important.

This take-it-or-leave-it behaviour is only one of the differences between the mobile world and the deskbound one it is displacing. Mobile apps are generally designed to perform a single function and to do it well. They often take advantage of device features such as geolocation, always-on networking and web connectivity and are used in a more personalised way.

There are differences in the development lifecycles of PC applications and mobile apps, too. Without the need for complex integration with back-end systems and with their limited functionality, consumer mobile apps are typically quicker to develop and can be updated more frequently. This means that they are often released with a few rough edges and bugs still in the code, with the public effectively acting as beta testers over the first couple of releases.

Perhaps the biggest difference is the existence of multitudes of competing hardware platforms, operating systems and even versions of the same OS that the developer must take into account �C a marked contrast from the world of the PC, which Microsoft has dominated for two decades.

The wild west of creative destruction arguably works rather well with consumer apps. Apps arrive fast, change fast and succeed or fail fast. Successful apps may get ported to other platforms and begin to attract other developers to build supportive ecosystems of apps around them. Failed apps are seen as lessons learned as their creators move on to something new.

Serious business

For businesses, however, rushing an app to market before it is ready is a recipe for disaster. RBS bank found this out last year when customers who could not access their mobile banking app vented their rage on Twitter and NatWest endured a similar experience in May when its banking app failed around the time of the monthly pay run for many UK workers.

“We can put men on the moon but #Natwest can’t run an app!” tweeted one angry customer.

While they might have fewer choices, users of banking or other commercial mobile apps will nevertheless uninstall them with as few qualms as any teenager ditching a dud game if it’s not up to scratch. And with its brand intimately tied in with its app, an enterprise will find it more difficult to dust itself down and start again once the reputational damage has been done.

As well as being subject to similar take-it-or-leave it behaviour there is the issue of complexity.

Even the simplest customer-facing enterprise app is likely to be more complex than its consumer counterpart, and not just because of the layers of security that need to be built in and attention to brand and design details. Complexity also results from the number of stakeholders involved, code ownership and consistency, integration with other business apps and websites, and quality control.

Enterprises need to balance all these factors against speed to market and development costs. Different approaches will be appropriate according to the purpose of the app.

Computing surveyed 80 business decision-makers involved with mobility to find out about the approaches they are using. These businesses had developed mobile apps either in house, via a third party, or most commonly a mixture of both. Customer-facing apps were about twice as common as internal staff-facing apps, with apps to communicate with the supply chain a distant third.

We were interested in the architecture these businesses had chosen: native, mobile web, or hybrid. There are advantages and disadvantages to each of these approaches.

Native apps are designed specifically for the device on which they are running and thus tend to be faster, richer and easier to use. However, their inherent inflexibility makes them expensive from a support and maintenance point of view �C particularly if they need to be made accessible from more than one type of device.

Web apps run in a browser. Generally easier to maintain, the trade-off is that they have a more limited scope. They are unable to access device-specific features and there will be no shortcut on the screen by default. Furthermore, if they need to run on multiple browsers, then the support and maintenance gains may be less than first thought. Most importantly, if there is no connectivity via Wi-Fi or 3G/4G there is no content.

Hybrid apps, as the name suggests, lie somewhere between these two. Easier to build than native apps they are nevertheless able to take advantage of device-specific functionality. Typically developed in cross-compatible web technologies such as HTML5, CSS and JavaScript they also feature some native code to allow them to plug into proprietary functionality. To make a hybrid app compatible with a different operating system, only the native code needs to be replaced.

Computing’s survey respondents demonstrated a fairly even split in terms of these choices. Twenty-seven per cent opted for the web route compared with 24 per cent going native app; 18 per cent chose the hybrid route, and 24 per cent selected more than one of these options.

However, when asked whether they thought it was better to develop apps for a native platform or take the mobile web approach, the single largest proportion of respondents (47 per cent) stated that mobile web (including hybrid) was their preferred route as opposed to 20 per cent choosing native. This split may reflect the preponderance of customer-facing apps.

“It depends on use case,” remarked one respondent. “We use web-based for prospective customers in a B2C [business to consumer] space, native for specialised B2B [business to business] or existing B2C.”

Other reasons given for preferring mobile web centred on future costs in terms of supporting different devices and platforms.

The drawbacks inherent in native apps in terms of device proliferation and obsolescence were also apparent by the fact that 60 per cent of those who had developed a native app stated that they had plans to develop for other devices; only 18 per cent did not. Many companies were keen to pursue a multi-channel strategy for app development (figure 1).



For this reason the future of MEAPs (mobile enterprise application platforms) seems assured �C they are evolving and maturing to become more open and allow the use of more developer toolsets. Also important in a multi-channel world are the sort of virtual test environments that allow apps to be road-tested to destruction before they are ever given the chance to fail in a brand-damaging fashion.

@_JohnLeonard