4 Reasons Enterprise Software Should Skip Native Mobile Apps

by Hutch Carpenter

4 Reasons Enterprise Software Should Skip Native Mobile AppsThe desire to “consumerize” mobile apps for their own sake is stoking today’s outsized enthusiasm with device-specific enterprise mobile apps at a time when HTML5 is right there staring us all in the face.

Tony Byrne, Enterprise 2.0 B.S. List: Term No. 1 Consumerization

The runaway success of the iPhone app store has demonstrated that people love mobile, and seek the great user experiences that mobile apps provide. You see these wonderful little icons, beckoning you to give ‘em a tap on your phone. You browse the app store, find an app that interests you, you decide to try it on and see if it fits.

And all the cool kids are doing the native app thing. Path is an iPhone app. Facebook wins high praise for its iPhone app. And Wired ran a story declaring, essentially, that apps killed the web star.

There has been a clear market shift to the apps market, and consumers have gotten comfortable with the different apps on their phones. It’s come to define the mobile experience.

So why doesn’t that logic extend to the enterprise? Because the native app experience isn’t a good fit with enterprise software. Four reasons why.

1. Lists, clicks, text, images

Think about your typical enterprise software. It’s purpose is to get a job done. What does it consist of? Lists, clicks, text and images. And that’s just right. You are presented efficient ways of getting things done, and getting *to* things.

This is the stuff of the web.

For the most part, the on-board functionality afforded by a mobile OS and native features are not relevant for the enterprise software. When trying to manage a set of projects, or to track expenses, or to run a financial analysis…do you really need that awesome accelerator function? The accelerometer? The camera?

The functions of mobile hardware and OS are absolutely fantastic. They’re great for so many amazing apps. But they’re overkill for enterprise software.

2. Enterprise adoption is not premised on the app store

A key value of the app store is visibility for iPhone and Android users. A convenient, ready-to-go market where downloads are easy and you get to experience them as soon as they’re loaded. This infrastructure lets apps “find their way” with their target markets.

An AdMob survey looked at how consumers find the mobile apps they download. Check out the top 3 below:

Mobile Apps - How People Find Them - AdMob

Users find apps by search, rankings and word-of-mouth. Great! As it should be. Definitely describes how I’ve found apps to download.

Irrelevant, however, for enterprise software. Distribution and usage of enterprise software is not an app store process. Employees will use the software because:

  • It’s the corporate standard
  • They’re already using it
  • They need to use it
  • It’s already achieved network effects internally, it’s the “go to” place

Adoption via the app store is not needed. The employee will already have a URL for accessing the app. For example, I use gmail for both my personal and work emails. For whatever reason, the second work gmail will not “take” on the native email function of my iPhone. So I’ve been using the web version of gmail the last several months. It’s been easy, and I didn’t need to download any app. I knew where to access the site.

3. Mobile HTML looks damn good

Visually, native apps can look stunning. They are beautiful, and functional. No limitations of web constructs means freedom to create incredible user experiences.

But you know what? You can do a lot with HTML5. Taking a mobile web approach to styling the page and optimizing the user experience, one can create an experience to rival that of native apps.

As you can see on the right, an enterprise software page presented in a mobile browser need not be a sanitized list of things. It can pop, provide vibrant colors, present a form factor for accessing with the fattest fingers and be indistinguishable from a native app.

Indeed, designing for a mobile experience is actually a great exercise for enterprise software vendors. It puts the focus on simplicity and the most commonly used functions. It’s a slo a chance to re-imagine the UX of the software. It wouldn’t surprise me if elements the mobile optimized HTML find their way back to the main web experience.

4. Too many mobile OS’s to account for

We all know that Apple’s iOS has pushed smart phone usage dramatically. And corporations are looking at iOS for both iPhone and iPads. Meanwhile, Android has made a strong run and is the leading mobile OS now. However, in corporates, RIM’s various Blackberry flavors continue to have a strong installed base. On Microsoft’s Phone 7 OS, “developer momentum on Windows Phone 7 is already incredibly strong.” (ArsTechnica).

Four distinct OS’s, each with their own versions. Now, enterprise software vendors, you ready to staff up to maintain your version of native apps for each?

37signals recently announced it was dropping native apps for mobile. Instead, they’re focusing on mobile web versions of their software. In that announcement, they noted the challenge of having to specialize for both iOS and Android.

Meanwhile, Trulia CEO noted the burden of maintaining multiple native apps for mobile:

“As a brand publisher, I’m loathe to create native apps,” he told me, “it just adds massive overhead.” Indeed, those developers need to learn specific skills to building native mobile apps, arguably having nothing to do with his core business. They have to learn the different programming code, simulators and tech capabilities of each platform, and of each version of the platform. By diverting so much money into this, he’s having to forgo investment in other core innovation.

A balkanized world of OS variants creates administrative, operational support and development costs. Not good for anybody.

While I’m sure there are enterprise software apps that can benefit from the native OS capabilities, such as integrated photos, for most enterprise software, mobile should be an HTML5 game.

Support the blog - Order your copy of 'Stoking Your Innovation Bonfire'

Don’t miss an article (2,750+) – Subscribe to our RSS feed and join our Innovation Excellence group!

Note: this post was previously published on CMS Wire.


Hutch CarpenterHutch Carpenter is the Vice President of Product at Spigit. Spigit integrates social collaboration tools into a SaaS enterprise idea management platform used by global Fortune 2000 firms to drive innovation.

No comments

  1. I would like to disagree strongly with your assertion that HTML5 is the “way to go” for enterprise mobile apps. I would offer that it is a great option for some apps, but to have truly transformational apps that employees will use every day, and enjoy using, native is the way to go.

    1. “Enterprise adoption is not premised on the app store”. True, but enterprises can provide a “private catalog” either via a native app (e.g., EASE) or in-house website. The whole point is that companies want to separate their own in-house apps, websites, and recommended apps from the 400,000 apps primarily for consumers on the App Store.

    2. “Mobile HTML looks damn good”. Indeed, but not as good as a native app. There is just no comparing the capabilities provided by native apps, in the UI, in access to device libraries, and in being able to run effectively offline. (Yes, I know there is offline storage for HTML5). The ability of native apps to get alerts, notifications, and do background downloading is just not going to happen for HTML5. And these are essential to transformational apps.

    3. “Too many Mobile OS’s to account for”. But how many are going to matter? Most enterprises have realized that standardizing on a few platforms, e.g., iPhone, iPad, Android, gives the best ROI on the “killer app” they need to improve their business. There is really little point in supporting older devices when many employees are already bringing their own smartphones to work.

    This is not a “black and white” discussion for sure, and there are many cases where HTML5 is a fine solution. But, with the cost of native app development declining, and the opportunity to use templates and cross-compiler systems, I would consider native if you want truly transformational results for your employees. The motto goes: “don’t create apps that suck, or they won’t get used.”

  2. You miss a few salient points in your analysis.

    1) Not all mobile functionality or APIs are available via HTML.
    For example – on an iPhone, you can’t run background applications or set alerts via web. You can not interact with a user’s contacts or get access to their calendar.

    2) The difference between a desktop computer (or notebook) and a phone are sensors.
    These sensors – such as GPS, gyroscope, camera, proximity sensor, microphone, etc. are not always accessible via a web application. On the iPhone, you cannot access the camera from a web application. When these sensors are available, they are not implemented as robustly. An example, a web application cannot receive location information while running in the background.

    To me, a mobile app is defined as an application that takes advantage of unique mobile APIs and sensors. Otherwise, you are just creating a mobile friendly website. Don’t get me wrong – lots of enterprise data can be surfaced with a mobile friendly website, but not all.

    The truly compelling ones will be native.

Leave a Reply