Ten years ago, the web browser was going to render the operating system obsolete. Applications would run on a standards-compliant, internet-connected web browser, instead. The only thing the user would have to worry about was whether the machine they were using had sufficient “grunt” to run the application they wanted to use.
Then the Apple iPhone happened and the epicentre of popular “app” development shifted to the proprietary environments provided by major mobile platform vendors.
But companies that have taken the plunge have been faced with a number of unexpected challenges: the development environment is limited - as is the hardware - and the large variety of differences between operating systems and devices further complicates matters. Furthermore, porting applications from one environment to another is far from straightforward.
“In the ‘normal’ development environment, you are generally writing for either Microsoft Windows or Linux, possibly for Apple Mac. In mobile, you have got at least Android and Apple iOS - and BlackBerry, Windows Phone and, possibly, Symbian,” says Tim King, chief technology officer of mobile application software toolkit vendor 5app.
On top of that, developers need to consider both iOS5 and iOS6, as well as the differences between Android 4.0, 4.1, 3.0, 2.3 and 2.2, he adds, not to mention BlackBerry 5, 6, 7 and 10, which is coming soon. And then there are the various screen sizes they need to take into account - in the browser world, of course, cascading style-sheets (CSS) can easily simplify that process.
In addition, the kind of backwards compatibility that desktop app developers routinely take for granted just doesn’t exist in the mobile world. While both Windows and Linux operating systems contain plenty of mechanisms for ensuring a high degree of backwards compatibility, in mobile apps backwards compatibility is a more capricious matter.
Microsoft, for example, has orphaned its “old” mobile operating systems with regularity. For example, Windows Phone 8 apps won’t work on Windows Phone 7 devices, while the apps built for Windows Phone 7 won’t work on Windows Phone 6.
When Microsoft released Windows Phone 7, a spokesman had claimed, “the cost of going from good to great is a clean break from the past” - before it did exactly the same just two years later.
BlackBerry, meanwhile, will be doing the same when it (finally) releases BlackBerry 10 - the operating system intended to help arrest the company’s sharp decline. On top of that, though, it will also require an upgrade of BlackBerry Enterprise Server to version 10 to support it.
On the device, though, mobile app developers also only have the proprietary development environments applicable to their chosen platforms to develop on - there isn’t the kind of eco-system of tools that, for example, helped to establish Microsoft Windows as the de facto standard on the desktop in the 1980s and 1990s.
“In the mobile environment, you are limited to the languages that the manufacturer will support you with. And that’s it. So the language that you write your apps in is not your choice. If it’s iOS, it’s got to be Objective-C and nothing else will do. You have no choice whatsoever,” says King.
Android, though, is a little less restrictive and, furthermore, apps are based on a derivative of Java - which ought to be familiar to a large number of developers.
A real turn-off
However, the peculiar demands of mobile app development may come as a surprise to developers more used to conventional application development.
For example, many mobile environments turn off services running in the back-ground by default in order to preserve battery life. Microsoft’s Windows Phone environment, for example, will only check for emails every 15 minutes. That cannot be changed, says King.
“In the normal environment, you know you are connected and can open a connection to the database. In mobile, though, it’s the exact opposite. You have to worry all the time about whether you are connected or not,” adds King.
One company, Smith Electric Vehicles, used message queuing software, based on the open source advanced message queuing protocol (AMQP), to ensure that the data from its electric vehicles, which are running all over the world, could be sent back to base for analysis via customers’ local mobile networks, regardless of connection quality.
Furthermore, the knowledge and skills required to code around these differences and difficulties is not necessarily something that someone in IT can quickly pick up. Not only have specialist mobile app development companies proliferated in recent years as a result, but so have specialist testing companies, which have hundreds of different devices that they can test newly developed software on.
Over time, perhaps, the development tools available on mobile platforms will incorporate message queuing and become more like conventional enterprise application development. However, the restrictions in competition on the various mobile developers’ platforms means that may take longer to arrive than it ought to.
This paper seeks to provide education and technical insight to beacons, in addition to providing insight to Apple's iBeacon specification
Focus on cost efficiency, simplicity, performance, scalability and future-readiness when architecting your data protection strategy