Once upon a time, in a galaxy far, far away, there was a company that was finally doing business on the web. Its developers were exhausted after spending years learning about HTML, CSS, JavaScript, and jQuery, and dealing with all the various browsers the company’s silly partners and customers wanted to use instead of the company’s Gold Standard, Internet Explorer 6.
You would think that everyone would have been grateful now that there was no need to install the company’s Windows NT application. But no! Not management, not employees, not partners, not even customers.
What did those silly people want? They wanted to do business from their phones!
It was time to bring back the consultants who had laid out the previous development strategies. Do you know what the consultants said? Fire all the web developers and hire a bunch of hip 20-somethings to build native iPhone apps.
The CFO thought that was a great idea: The web developers were getting enough seniority to be expensive. HR wasn’t so sure about the firing part: What about retraining? The CIO had heard millennials don’t like structured companies and don’t want to work hard, but want to do things that are socially relevant. Wouldn’t they be hard to manage?
In a quandary, my old friend the CTO called me and invited me out for sushi. Over the miso soup, he brought me up to speed on his situation and asked what I thought he should do.
It was fortunate that I had already swallowed my sip of tea and put down my cup, or I would have sprayed the tablecloth green around the third detail.
Here is what I told him.
Not all mobile apps are the same
First, iPhones aren’t the only kind of phone. Second, a phone isn’t the only kind of mobile device that your employees, partners, and customers will want to use. And third, native apps aren’t the only kind of mobile application. So let’s talk about the entire mobile application landscape.
To keep it simple, let’s start with what’s running on the device. Later, I’ll tie that to what needs to happen on your servers to support the device.
On an iPhone or iPad—yes, they are different, but you can write apps that run on both—a native app is typically written in Objective-C, Swift, and/or C++. It is developed on a Mac—yes, I know you’re standardized on Windows, but I’ll get to that—posted on an app store, then users download it to their iPhone or iPad.
Notice I said “an” app store. Consumer apps are mostly on the Apple (capital-A) App Store; enterprise apps are often on private (small-A) app stores or repositories. Sometimes your mobile management company is responsible for the app store—but I’m getting ahead of myself.
On an Android phone or tablet, a native app is typically written in Java and/or C++. People tend to use C++ for system-independent libraries when they are writing apps or games for both iOS and Android. App stores are about the same deal with Android as with Apple, although it’s easier and faster to get an app into the Google Play store.
Notice I said “typically” when talking about languages. Die-hard Windows shops write portable, close-to-native apps in C# using Visual Studio and Xamarin. Don’t run back to your office yet, though—eat your salmon nigiri, it’s good—there are more options for your shop. By the way, you’ll still need Macs to build and debug apps for iOS, even though you can design and code them on Windows.
While native apps run the fastest, make the best use of device hardware, and behave the smoothest, they also take the longest and cost the most to develop, and they’re the hardest to update in the field. The typical cost of one medium-size iOS or Android app built with the native software development kit is $100,000, and adding another platform means reimplementing all the code, though most of the design can be preserved. Those C++ libraries also help to avoid reimplementing code for the second system.
Mobile web apps are much cheaper to develop, about 20 to 25 percent of the cost of a native app, and they would be a better fit for the skills your web developers already have, but there are a few gotchas. They run more slowly, make the least use of device hardware, and are most prone to choppy behavior. On the plus side, they are trivial to update in the field—simply revise your website.
There are other deficiencies of mobile web apps to consider, though. For one, they may not retain state across a context switch or device reboot unless you explicitly save and load state on the device. The issue of choppy behavior, such as jerky scrolling, can be fixed with carefully written JavaScript widgets and by the use of high-performing JavaScript frameworks. Finally, web apps can’t use most of the mobile device’s fancy sensors, except for the GPS.
Hybrid mobile apps can cure that problem. Building a native wrapper for each supported device using Adobe PhoneGap or its open source foundation, Apache Cordova, will get you access to the device capabilities, and it allows the app to retain state across a context switch or device reboot without special coding. Making a PhoneGap app can once again force you into the app stores, but you can bypass a lot of update activity by downloading most of the content from your site and presenting it in what’s essentially a browser window hosted inside the native shell.
There are loads of mobile app development platforms you can use. For example, you might want to consider the 11 “significant” vendors cited by Forrester in this year’s “wave”: Alpha Software, Appian, Capriza, i-exceed, K2, Kony, Magic Software, Mendix, Oracle, OutSystems, and Salesforce. Or you might like an up-and-coming cloud-based mobile development platform, such as EachScape, QuickBase, and ViziApps.
Some of these generate native apps, some hybrid apps, some web apps, and some give you the choice of all of the above. Some involve less work for your developers than others, and some are easier to learn than others. Some run in the cloud, and some run on a desktop. Some are free at least until you deploy, and some will make your purchasing department negotiate a six-figure annual license on day one.
(What do you mean, where can you find out about mobile app development platforms? Don’t you read my reviews on InfoWorld?)
More green tea? Waiter, could we ... ah, thank you.
Mobile apps require mobile back ends
We haven’t even gotten to back ends. You have centralized databases behind all your systems of record, right? Your mobile apps should use those databases, although not necessarily directly.
I’m pretty sure your DBAs would be willing to export some views for your field salespeople to use on their phones and tablets, such as product catalogs. They might even be willing to accept incoming transactions such as orders, as long as they went through the same checks and business logic as your other order-taking systems. They probably don’t want to issue read-write database credentials to mobile devices, though.
A lot of the time what people do is to use an intermediate layer for the mobile database views—often a NoSQL database such as MongoDB or Couchbase Server. In many cases an MBaaS does that part, MBaaS serving as a mobile back end as a service. It’s all common code, and your developers shouldn’t have to waste a lot of time developing it for each application.
An MBaaS may potentially need another annual license, unless you use a mobile app development platform that includes its own back end as a service—yes, some of them do (like Appery.io), and others don’t. Some MBaaS options are pay-as-you-go, which is good if your usage will be low, but not if you’re going to create a popular business-to-consumer app. (I take a deeper look at five MBaaS offerings in “MBaaS shoot-out: 5 clouds for building mobile apps.”)
Beyond a database-of-record back end, an MBaaS might provide hooks for back-end business logic, scheduled back-end code, a JSON key-value store for use by the app client, authorization links for LDAP and Active Directory, and beacon support. It might also provide an easy way to connect to push messaging through Google and Apple cloud messaging services.
Some MBaaS vendors expose their APIs through client-side toolkits and popular JavaScript frameworks, for programming convenience. Almost all offer a REST API that can be invoked through HTTPS requests from any client language.
Offline data synchronization is one of the hardest problems to solve in enterprise mobile apps. Why not simply depend on the server data? You gotta be kidding me.
Suppose you had a field service tech inspecting a customer site. He goes inside a server closet that has no Wi-Fi or cell reception, but he still has to take pictures of a list of items in the server room and write up a report. Ideally, he downloaded the job data before coming to the site, then adds his observations to the records for the customer site as he makes them, with the phone offline and storing information locally.
Meanwhile, back at headquarters, a manager realizes his work order had a misspelling and fixes it. When the tech is done in the server closet and returns to an area with cell service, his app sees the connection and uploads his half-hour’s worth of inspections. When it gets to the database, a flag goes up because of the conflict between the misspelled location name he downloaded and the corrected name in the server.
If the conflict resolution policy is “server wins,” as is often the case when the programmers or CTO are lazy—yes, I am looking at you—then the entire half-hour’s work is lost. If that happens an hour’s drive from the site and he has to drive back, then you’ve lost more than two hours of the tech’s time. That isn’t any way to run a business.
You can’t rely on a “client wins” policy, either. To do conflict resolution correctly, somebody needs to be able to look at all the data and its timestamps and decide what to take on a field-by-field basis. Got it?
What are your mobile app needs?
Let’s now think about your mobile application needs. Do you want to make your big public sales site into an app? I can guarantee you that consumers will want the app to look and feel native, and they won’t tolerate any pauses as the app downloads data from your site over what might be a slow connection. You’re probably looking at native apps for iPhone and Android, plus a mobile web or hybrid app for the less popular phones, such as Windows Phones and BlackBerrys. With some luck, you’ll be able to create a common back end for the site and the apps, as well as write common client code libraries to share between the iOS and Android apps.
What about your warehouse app? The warehouse workers don’t care how their app looks—they only want to be able to access the inventory database and scan bar codes throughout the warehouse—so they don’t need native apps. But they also want their data to persist when they answer their phones, so mobile web apps won’t be good enough. I think the warehouse app needs to be hybrid. And I think it would be good if it supported beacons, so the app could know where the phone is in the warehouse, since GPS doesn’t work there. You might also want to look at the Wi-Fi coverage in the warehouse—if it isn’t 100 percent, then the app will need online/offline data synchronization.
Finally, what about your partner and management apps? If you do them right, they’ll work fine as mobile web apps—and neither the partners nor the managers will ever have to worry about updating their apps.
Do you want the last mochi ball? Waiter, can we have the check, please?