If I were a manufacturer, retailer, or MSO, the one thing I'd avoid like the plague is an HTML or HTML5, connected, mobile application for field sales and service. This post will detail my thoughts on why.
1. Connected HTML apps rely on being, well, connected.
Over the years we watched as over 100,000 of our end-users have struggled with WiFi in stores. For years many didn't have it. Then when they did get it, coverage was spotty, equipment was often in disrepair, and worst of all, the stores would throttle bandwidth.
Cellular is better -- but adds significant expense -- and not perfect. There are plenty of stores where cellular service has issues.
So when apps rely on being connected and then can't get connected, bad things happen -- resulting in frustrated users, lost productivity, and lost data.
Many HTML app developers' solutions to these issues are to try to use a feature of web browsers called 'local storage,' but that solution is also fraught with peril. For one thing, the web browser only has very limited local storage. Retail field apps tend to use a lot of storage, and that leaves nothing for pictures of the kids, grand kids, etc. Heavy social app usage will use up all the storage and that will cause the HTML app to stop working until all that stored data is cleared. And let me tell you, that you don't want to be the one telling people they are going to have to reset all their passwords, and re-download all the stuff they have stored in their browser's local storage.
Dedicated mobile apps suffer none of these problems. If they have connectivity, great! Information can be collected in real time. If not, no problem. They work off line seamlessly until they have connectivity -- then send all the data as soon as they can.
2. HTML is intentionally limited in what it can do -- for security
In the early days, it didn't take hackers long to find out that if they could get you to click on a website, they could take complete control of your computer. Honest and excited programmers writing the first web browsers thought it would be a great idea to let your browser access your computer's hard drive without oversight, access device components that became available over the years such as cameras and microphones, and to launch programs for maximum use of your computer.
Hackers used these features to create 'zombie' computers -- basically, turning your computer into a machine that went out and infected millions of PC's while you slept.
The computer industry responded by greatly restricting the capability of web browsers to prevent hackers from stealing your computer from under your nose. That's great, except, that now when you want a powerful app, programmer have to jump through lots of hoops to deliver it -- and in many cases there are things that just can not be done with a web browser. So you end up giving up powerful functionality -- and that's not good.
Mobile apps, on the other hand -- and I would say most especially the iOS apps from the Apple Store, are safer to install. They are signed by their developer -- so not just anybody can put an app in the store and trick you into installing it -- and in the case of Apple, scanned for malicious programming and even things they think you should be aware of.
So deciding on mobile apps instead of HTML means that you're getting the most powerful programming, with the least amount of 'hoops' the programmers are jumping through (i.e. more time for productive features, and less chance of weird things happening as a result of what the industry calls 'hacks.' So you can avoid all kinds of hacks (for your good or bad.)
3. Lack of browser standards mean hit-or-miss reliability.
It's sad, but there are no good standards that all browser publishers agree on and adhere to. So what that means to you is: maybe Chrome works perfectly, but Firefox doesn't. Maybe Internet Explorer works (although probably not as they tend to least up to standard).
Because of this, you get hit-or-miss reliability in the field and you and your provider become burdened with tech support trying to figure out which automatic update to which browser has caused what problems -- and more importantly how to get the end user working again.
Mobile apps don't suffer from these issues nearly as badly. Yes, a new version of Android or iOS can cause problems, but there is much more advance notice to developers and many fewer issues overall.
So if HTML(5) is so bad why do they even exist?
Development cost. On average it costs ESP about $500,000 to create an app. And that cost is duplicated 3 times because there is the cost for the iOS app, the Android app, and the Web version of those apps (note that the ESP Web version is only intended to be used by people who don't have a (or lose their) mobile device.
So if a developer creates an HTML(5) version of an app, they only have to do it once, and that saves them tons of cost -- but the end user is who pays the price for that.
In summary, if I were a retailer, manufacturer, or MSO today and I were looking for apps, the #1 thing that would kick off my search would be separating all the HTML based apps out of the possibles and continue my search from there.