You can blame it on the late Steve Jobs, or on BYOD programs or anything else that comes to mind, but the fact the remains: In almost every organization around the world, employees are walking around with iPhones and other mobile devices. And so are their customers.
Tech-savvy organizations are turning this into an opportunity by providing mobile apps which their employees can use to be more productive, and which their customers can use to transact business.
So what's the best way for organizations of all sizes to develop these mobile applications?
To all intents and purposes there are two relevant operating systems to develop for: Apple's iOS, and Google's Android. The others - the ones that power Windows and BlackBerry mobile devices, for example - are irrelevant for the moment.
There are a number of benefits to this approach. Using Apple's and Google's development tools enables you to write native apps that can make the most of all the features of the respective operating systems and the devices on which they run. The apps should also look and feel just like the native apps that come with the operating systems.
But inevitably there's a drawback to this approach, and it comes down to cost. Writing native apps takes skilled developers, and if you plan on writing apps for both iOS and Android you're faced with paying up to twice as much as you would if you developed for only one of these operating systems. That's because the code bases are completely different, and aside from the basic design there's little work that can be shared between the two.
Cross-platform Development's Cost Advantage
That's where cross-platform development tools come in to the picture. These include:
Although each takes a slightly different approach, what these tools provide is the ability to work on a single codebase, often in a standard language like C#, and then run the code though compilers that emit native iOS or Android apps.
"If you choose to write native apps, you have to use separate tools, different APIs and different languages," says John Thomas, director of product management at Embarcadero. "That means you have different code bases, and maintenance is very hard and expensive. With a solution like ours you write to just one API, and then compile to native binaries."
The benefit of this approach is that it costs about the same to develop apps that run on both operating systems rather than just on one. And since it is possible to use familiar tools like Microsoft's Visual Studio as well as familiar languages like C# (for example using Xamarin,) it may be possible to use in-house developers with Windows skills to create mobile apps for iPhones and Android devices.
There are, of course, also drawbacks to this approach. Apps developed in this way don't always look like true native apps. While that may not be an issue for apps for employees, the fact that they may lack an air of professionalism and look inexpensive compared to native apps may make them a no-no for consumer apps.
"There's no question that developers of consumer apps prefer to use the native development tools," says Kirk Knoernschild, an analyst at Gartner. "But in enterprise developer teams there is quite a demand for these sorts of cross-platform development frameworks. Organizations don't want the cost of developing for both platforms, so in many cases they are evaluating or have chosen one of these tools."
Knoernshild's observation about consumer app developers preferring native app development tools is borne out by Dan Sensecall, co-founder of multi-platform mobile app developer TappCandy. "We only develop apps natively, as the end user experience is never the same if you use cross-platform development software," he says.
Pros and Cons of Web Apps
"If you invest in native apps, it has to be because you want a really rich user experience. But the side effect is that you are going to have to make an ongoing investment and carry out constant iteration to ensure that it works on new devices and is as bug free as possible," he says. "But our customers want a quick way to get apps out that do simple things."
He says there are limits to what HTML5, for example, can do in terms of accessing low-level functionality, but that these limits are changing. "Last year we couldn't access a phone's gallery or access the accelerometer on the iPhone, but now we can," he points out.
The benefits of apps built using Web technologies like HTML5 is that they are truly multi-platform. They can be accessed on any device that has a suitable browser, including Windows Phone and BlackBerry devices.
One organization that has used Weejot is South Lanarkshire Council in Scotland. Andrew Proctor, the IT project manager, says the council wanted to make more of its resources available to mobile users.
"We engaged with a supplier to do some bespoke apps for us, but we realized that there would be significant overhead involved in maintaining these apps," he says. As an alternative, he investigated other options including creating Web apps with Weejot.
"We got quotes for both, and realized that it would be significantly cheaper to use Weejot. There is no functionality that we need that was lacking." When Weejot applications need modification, it is much quicker and cheaper than redeveloping a bespoke app and then having to resubmit it to Apple's App Store, he adds.
When it comes to choosing the right app development method, the message seems to be that it is very much a matter of horses for courses. If you're looking to craft an app of the highest all-around quality for your customers, it may be worth the expense of creating separate iOS and Android apps using their respective native development tools. If you want to build apps to be used in-house by your staff, multi-platform tools may be more suitable. The Web app approach may be best if you want to knock up something quickly that is simple and inexpensive, but effective.
Paul Rubens has been covering enterprise technology for over 20 years. In that time he has written for leading UK and international publications including The Economist, The Times, Financial Times, the BBC, Computing and ServerWatch.