Building tablet and smartphone apps for the enterprise

So you either have a BYOD policy in place, or you're buying a bunch of tablets and smartphones for your staff. How do you let them do something useful with the devices?

The most basic thing you can do is let them dial into a Windows desktop through virtual desktop infrastructure (VDI). The problem with this approach is that you're trying to use a post-PC device to access a PC-era device. It can be very unsatisfying for users to operate systems in this way. It's an approach that works well enough if the user has to make very occasional access to a system, but if you're expecting that as the be-all and end-all of your solution, you should also expect some light rebellion.

A better approach is to expose enterprise systems through front-ends specifically designed to be compatible with mobile devices. This fits nicely into ideas about ubiquitous computing — using devices that are always available and alway connected that the user can dip into and out of at their whim.

What people are actually telling the business when they want enterprise-supplied tablets, smartphones, or good BYOD support is they they want the company's data with them wherever and "whenever" they are. Most of us would do well to be supportive of that need.

In terms of each system you're trying to expose out, if you're lucky, the original vendor will have some sort of mobile solution they're willing to sell you. If you're unlucky (either because the vendor doesn't have a mobility story, or what they do have sucks), or if the system is custom-built, you're going to have to build your own.

Devices

What makes mobile development hard is the spread of device platforms that you have to support. Today, if you wanted to hit everything, you'd be looking at supporting a combination of iPad, iPhone, Android phone, Android tablet, Windows Phone, Windows 8 tablet, BlackBerry 10, and BlackBerry PlayBook. I'll refer to each of these as we go as "device/form-factor pairs."

Even if you pick half of the pairs that you want to support, this problem is still really difficult. The advantage of the PC era is that once the app runs on whatever web browser you put in your standard desktop image, you are essentially done. In the post-PC world, all of these devices are different and fragmented. Each device/form-factor pair that you want to support necessitates discrete specialist development and discrete testing.

Web

The simplest way to deliver functionality down to a mobile device is to expose it as a mobile web app. This is something that enterprises have been doing for at least a decade to get around the heartache involved in writing software that ran on the devices.

This is done in a similar way to how you build web apps now. You just need to pay more attention to making the design sympathetic to usage with touch, and adapt to screen real-estate that varies from smartphone-size to tablet-size.

A huge advantage of this approach is that you can more or less cover every device platform/form-factor pair with one development effort. The two big disadvantages is that you'll need a working Wi-Fi or cellular connection for it to be functional, and that the user experience will be nowhere near as good when compared to that of native apps.

Native

Native apps — i.e. those that are installed on the device — are much harder to do. But if you deliver a good result here, your users will love you for it.

A big disadvantage to native is that every device/form-factor pairing requests specific development and specific testing.

Each mobile platform vendor produces their own toolset that is optimized for developing apps on their platform. They are all different — they all use different languages, frameworks, and tools. If you use the vendor's supplied tooling there is very little scope for "write once, run anywhere." If you want iOS and Android apps and you want to use Apple or Google's tooling, you'll need to build the app twice.

Of course, it could be that you only want to support iPad because you happen to have given every employee an iPad. You may find cross-platform isn't a particular consideration in your own case. However, what I'm about to sketch out applies whether you are looking for a cross-platform solution or not.

The reason why you would want to build a native app rather than exposing out a mobile-aware website is that native gets you the absolute best user experience. If you try and fudge building multiple native apps to hit more platforms using an intermediary tool that makes cross-platform easier, you'll be compromising the user experience.

You can get away with this sort of compromise more in the enterprise space compared to the retail space because of a lack of competition. (You're the only one providing the apps.) Also, in the enterprise space, you have the luxury of dictating to users what tools they have to use.

Cross-platform

There are only two practical cross-platform solutions that I would consider. One is Apache Cordova. This is a toolset whereby you package up an HTML5-based web app as a native app. When the app runs, it loads the browser, but all of the assets that make up the website are locally available. Apache Cordova apps have access to device-local functions, such as GPS and the camera.

Apache Cordova is an open source project. What people typically use is PhoneGap, this being a distribution of Apache Cordova.

People like Apache Cordova because it seemingly solves the cross-platform problem (every device supports HTML5) and also because developers can use open standards.

However, the engineering toolset around Apache Cordova is absolutely horrible to work with. Cordova is almost best-suited as a prototyping tool — you can get up and running very quickly, but getting the last 10% is very hard indeed.

Read: "Here's why HTML-based mobile apps don't work"

My preferred cross-platform solution are tools produced by Xamarin — specifically Xamarin.iOS and Xamarin.Android. These tools are based on Mono, the open source implementation of .NET and C#. Rather than building apps using the vendor's API and their preferred language, you use the vendor's API but wrapped in C#.

The huge advantage of this to enterprise developers is that if you already use .NET or Java (and chances are, you do), most of the learning curve for mobile evaporates. If you're building an iOS app in Xamarin.iOS and you want to, say, create a list of data and sort it, if you're a .NET developer you already know how to do that.

What you do need to learn with the Xamarin tools is anything device-specific. For example, if you want to change the theme of an Android app from white text on black to black text on white, you'll need to know the Android API way of doing that. That knowledge won't translate to other platforms.

There is also more scope for porting code between platforms with the Xamarin tools. Build some business logic in C# for an iOS app and you can port that straight over to Android. Similarly, you can then take that over to Windows. But the only code you can port is device agnostic — the UI layer has to be reengineered for each platform.

Conclusion

All of this, by the way, is why getting retail app developers like Instagram to support niche platforms is so hard — the cross-platform story on the currently dominant mobile platforms is horrible to manage.

Within all this, there is a school of thought that trying to achieve cross-platform capability of any kind is actually overkill and you are better off going through the pain of just learning the vendor's specific tooling.

In all honesty, I'm yet to decide the best option. I think for enterprise customers, Xamarin's tooling makes the most sense as it elegantly bridges the gap between enterprise skills and new, weird platforms.

But, you do at least have plenty of options. The thing I'd advise you to try and get away from is the temptation to just expose out a Windows desktop over VDI. That approach doesn't give you the advantage of a modern, post-PC device. A tablet isn't another form of Windows terminal.

What do you think? Post a comment, or talk to me on Twitter: @mbrit.