- Mobile device market fragmentation, a continuing problem for application developers.
- App manufactures should adopt a combined Web/native development approach.
These are heady days for IT managers with a hankering for mobility. Over the past two years, the usual impediments to mobilizing the workforce have vanished beneath an avalanche of consumer pressure, technological innovation and corporate acceptance. This is particularly true when it comes to supporting a wide array of devices from Apple, Microsoft, Google, Nokia, RIM and others. Gazing at the myriad devices and plethora of software for those devices currently roaming about the marketplace would lead one to believe that it’s a foregone conclusion that mobility has reached a point where users can bring their device du jour to the workplace. Well, yes, this is true – but that’s really where the trouble begins.
Forget for a moment the management side of this equation. Unified management of heterogeneous devices is still a work in progress, but has an achievable endpoint on the horizon. The real danger in supporting multiple devices comes from the future, from the work vendors are doing right now to create the next generation of mobile operating systems (OSs). That danger, in a word, is fragmentation.
Certainly this is not a new concept to anyone who has deployed an operating system or a Web-based application. But in the mobile game, the problem is compounded not just by the number of competing devices in the marketplace but also by the number of OS versions running on those devices. For closed systems like Apple’s iOS, where there are few service providers and only one manufacturer, anyone with an iPhone or iPad can rely on getting the latest OS refresh shortly after Apple releases new software.
It’s not such a simple matter for the biggest rival to iOS, Google Android. Right now there are approximately five valid versions of the Android OS in use across 130 million devices. And the majority of those (more than 80 percent) are running version 2.2 or 2.3.3, leaving three newer versions out in the cold for now. Worse, it greatly increases development costs for enterprise software vendors building apps that run on those differing versions. Google has been working to alleviate this problem, slowing its development pace, working with its manufacturing partners to ensure that new software gets out to users within 18 months of delivery and even segmenting core Google apps such as Mail and Maps from the core OS to simplify development for partners.
Like Google, other mobile OS vendors–such as Microsoft and RIM–have created their own innovation/deployment cycle problems, mostly in an effort to out-engineer Apple. Then couple this with Microsoft’s own disruptive actions stemming from its lawsuit over Android IP and the potential influx of new platforms such as webOS (don’t count this one out just yet) and MeeGo, which could play important roles should current Android vendors such as HTC and Samsung decide to branch out on their own. The result is a near-term forecast of continued fragmentation with more than a chance of spotty application support across the spectrum.
Of course, software vendors can opt to build their mobile apps on top of more generalized foundations, such as the WebKit layout engine, Adobe Flash, J2ME or HTML5. But compared with fully native apps, these approaches either hamstring the application itself or cut it off from what makes mobile devices valuable–their cameras, telephones, geolocation tools etc. Of these options HTML5 holds the most promise, but there, too, fragmented browser support and further maturation of the standard itself will limit its widespread effectiveness for the near future. Until the market steadies itself and standards like HTML5 mature, IT managers should look for mobile app vendors that are:
- Capable of and committed to building across not just multiple OSs but multiple OS versions,
- Actively deploying hybrid native/HTML5 applications, which cuts development costs but retains access to device functionality,
- Providing full UI access using WebKit as a fallback option.
Although this won’t do away with potential incompatibilities for all mobile users, it will ensure a stable of app vendors best positioned to support the widest possible array of mobile devices now and in the future.