Building tablet and smartphone apps for the enterprise

Building tablet and smartphone apps for the enterprise

Summary: If you want to give your users the absolute best experience when accessing enterprise data, you may find yourself building apps for private use. But how?

SHARE:
Mobile Platforms
Here's just a few technologies that you'll have to get your head around in order to deliver private smartphone and tablet apps in the enterprise. Phew!

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.

Topics: Tablets, Enterprise Software, Smartphones

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

16 comments
Log in or register to join the discussion
  • native development

    we tried phonegap development at first but had to cancel it as you end up tuning for specific platform anyway, so only native development for both ios and android. supporting "new, weird platforms"? thats one nice reference to wp8 :) but easier to ignore those two people among 100 who use such device

    i dont know about xamarin but i know that marmalade users for example encounter the same problem as we did - first you believe it is "crossplatform" but end doing plenty specific adaptations, its a pain and doesnt work smoothly.

    well it is not true for simplistic apps but serious corporate apps are usually something serious
    polarcat
  • If we could get everyone in the industry ...

    to play well with each other, maybe they could then work on some standards and embrace a cross-platform way of doing a lot of the basics (an API) to allow some amount of basic functionality to be done on all major platforms (and those that are up and coming could work toward them also). A big must would be the integration of proper security in the implementation (as we have seen with Java, if you don't have it, people shy away from using it). Unfortunately, the lawsuits of the last 2 years have all the big players in no mood to cooperate, so we the consumers suffer.
    jkohut
  • Programmers

    Another point: it's tough to find good, proven app developers who aren't incredibly busy. So do you train your own - and suffer as they climb the learning curve?
    beau parisi
  • Editors / Autocomplete

    This article is a perfect example of why I hate BYOD / tablets at work, in the current generation.

    I'm assuming you created this on a tablet and you had auto complete on and/or the editors are on holiday this week!

    A few autocorrect funnies in such an article are okay, but when they start cropping up in ERP systems etc. where errors can quickly cause big problems, the solutions have to be very good!
    wright_is
  • Absolutely and 100% wrong

    "A tablet isn't another form of Windows terminal."

    No, it is far more accurate to say that an ipad isn't another form of a Windows terminal since it is the only device that simply can't work this way, it isn't good enough.

    Smarter organizations will realize that they can roll out Androids or Surfaces and while taking the time to create good native apps, can allow their users to access the existing functionality without any issues. The bonus is that the Surface apps they write will run without modification on the desktops they have. None of this silly:

    "But the only code you can port is device agnostic -- the UI layer has to be reengineered for each platform."

    Funny how you just kind of dismiss the UI as if it is something to be whipped up in an afternoon. You are talking about a MAJOR amount of work that has to be reengineered for each platform, unless you are smart enough to go with Windows 8 / RT.

    It is only organizations that have been foolish enough to go with the ipad that have to frantically rush to get something, ANYTHING into production so that their business doesn't grind to a halt. You end up with horrifically lousy, rushed ipad apps at which point the mild rebellion that started with "Why can't I do my work on this ipad?" grows into "I waited 6 months for THIS? I quit."
    toddbottom3
    • You are talking about a MAJOR amount of work that has to be reengineered

      for each platform, unless you are smart enough to go with Windows 8 / RT.

      Idiot.

      If you do that then you are NOT CROSS PLATFORM.

      What works for Win8 pro won't work for Win8 RT... so redevelop.
      And it won't work for Android or IOS either.
      jessepollard
      • Not exactly true

        Win8 and WinRT can be cross platform if you develop an RT app. If you develop a desktop App it is not cross platform as a desktop app will not run on RT.

        so by building a RT app you technically are cross-platform as win 8 and WinRT is not the same platform.
        AceOfClubs
    • Pointless comment

      If 90% of the tablet and smartphone market is occupied by iOS and Android, you have to be able to develop for these platforms. These smartphones and tablets are already in the enterprise, ignoring this fact is rather pointless.
      If you, like me, run a software company that build apps for a living, you cannot say to your potential customer he should replace all smartphones and tablets.
      No enterprise could just sit and wait from the day the iPad was launched until the day Microsoft eventually launched Windows RT.
      A lot of enterprises have serious doubts about the viability of Windws RT, especially those active on a global scope. In a lot of well developed countries there currently are just no Windows RT devices available (Samsung just announced not offering Windws RT devices in Western Europe).
      So get real.
      cropr
  • Developing on SAP

    if you intend to develop for SAP you should have a look on www.sapmobileappspartnercenter.com.
    Stefan Wenzel
  • Just isn't worth it...

    Given that the tools are in their infancy I don't think it's worth the bother.
    NoAxToGrind
  • Apps and Responsive Websites

    The company I work for has both an App and a responsive website for iOS and Android. To me, an App is good because the interface is preloaded, I've seen many "apps" that were just URLs to websites that looked like apps. And I do not mean responsive websites. The downside is that any change to the app requires a push to the market/store and all phones to download this update.

    I'm finding Responsive web sites can do the same thing most Apps can do already. If a site is not built correctly, it will take longer to load then an app. On the other hand, there are no pushes to phones. Games are a bit tricky though.

    With CSS3 and HTML5 being widely implemented, I'm starting to have more bookmarks to websites in my Chrome browser on my phone than I do apps. Unless the app is some type of game or interface that a website cannot implement, I don't see having them necessary anymore unless it's a shortcut to a website or game.
    Maarek
    • It depends

      Responsive Web sites are great as long as you don't want to use any device functionality like GPS or access to the local filesystem. But even then developing responsive web sites can be challenging. If 3G (or even worse 2G/EDGE) connectivity is part of the customer spec, you cannot afford to use most of the javascript libraries as the loading of page takes too long. For a customer of me I had to replace jQuery, because the home page took more than 30s to load on a smartphone. And because jQuery solves a lot of Internet Explorer issues, this created new challenges (damn you Microsoft). Native apps don't have the issue of load times.
      cropr
      • Actually, Cropr not true

        There are many things from a Software standpoint you should be doing. First, jQuery is almost ubiquitous nowadays. Therefore, if you simply point to Google API's CDN of jQuery, it is first very compacted and minimized. If, however, you are simply inserting the non-minified, non-encrypted, non-cached version into your website you will have a problem. Remember, by pointing to the CDN you also have a high likelihood the library will already be cached in the browser since it is more common. Secondly, you should start to investigate Require.JS which effectively performs AMD (asynchronous Module Definition). In effect, it will lookup the individual modules within jQuery as you call them, almost like a DLL in Desktop apps. Finally, you can always tune your jQuery library to only include the modules you want if you don't want to learn Require. Therefore, the download (if minified and compressed) is almost nothing. There is no way for a jQuery library to take 30 seconds. Have you actually run Chrome developer tools on it to see??? I don't think you know what you are talking about???

        Last, in regards to Device API's like GPS and phone, the HTML5 spec is slowly getting more API's built in natively. Geolocation works very well, as long as your browser supports it, which is everyone but IE8 and below. Camera is easily accessed. And as far as file system Local Storage within the browser has been around in all browsers since IE8. People just don't know how to use Local Storage, or even WebSQL, indexSQL etc. It just takes someone with knowhow.
        JarrodEast
        • Oh yeah

          And also, jQuery should probably load at the bottom in the header, so the rest of the Dom is ready. In fact, loading it OnDefer is even better, unless absolutely necessary. But things like Modals, Date pickers, dialog boxes and such, even in UI, can load later, since the code isn't initiated until an event occurs (on Click). This is why Require.Js and JQuery work so well too. Anyway, food for thought.
          JarrodEast
  • True Multi-Platform Capabilities ? Absolutely !

    Kony provides true multi-platform capabilities and TRULY Native apps without compromising the user experience or scalability.
    We are the fastest growing company in the mobility industry because of the capabilities we provide to the enterprise.
    gschwartzberg
  • Webinar - Mar 28, 2013 11:00 AM EDT

    An educational webinar on the dynamics of building enterprise mobile apps; will cover the "how-to" of making cross platform native apps; for people experienced in mobile programming as well as for those with no mobile programming skills.
    Link to join: https://attendee.gotowebinar.com/register/1213645681940317184
    Inga Kletsova