A lot of systems use a separate native app for each operating system
Most field data collection software apps targeting the construction industry—including commissioning software systems—use separate native applications for different operating systems. This is usually done to provide a user experience that feels right for that particular device and OS. For example, Android users hate it when an app looks and behaves like an iOS app. And the same can be said about Apple users…they don’t want to run an app that clearly “feels” like a clunky android app that was sloppily ported to iOS.
This “separate codebase for each OS” approach creates some issues for both the software provider as well as for the user of the software.
Issues resulting from this approach
Some features are available on some native apps, and missing on others
CxAlloy is a typical example: their iOS app can do certain things, while the company’s Chrome app intended for Android users has some limitations and is missing some of the iOS app features.
With some solutions, if you want to collect field data in offline mode, you have to use a specific app for that, or follow a very specific process. Latista is an example of this: if you want to collect safety data in offline mode, you have to use their browser-based app, and not hit the refresh button until you have internet connectivity, or flip the device into airplane mode when you know that the cell signal will be spotty. If you don’t follow the procedure exactly, you may lose data.
Some software solutions don’t even bother with certain operating systems for their mobile component
Windows used to be King of Everything. Not anymore, at least not on mobile. It’s all about iOS and Android. So a lot of software developers pretty much skip Windows OS for their mobile apps.
But Windows is still in use in many enterprises, even on portable devices such as expensive Panasonic Toughbooks and intrinsically-safe or military-spec laptops and tablets. So you might not be able to get any more use/life out of that very expensive hardware you bought a few years ago if you go with a solution that doesn’t run on Windows as a native exe app that is capable of offline mode.
Adding a new feature means editing multiple codebases, which is time-consuming and expensive
Been there, done that. An important clients wants Feature X, and it’s a great idea that others can benefit from. So you decide to add this new feature to the system, which means adding it to the web app codebase, the iOS codebase, and the Android codebase, plus updating the database layer and APIs to handle this new feature, not to mention checking to see if there are any impacts of such on any other area of the system in each of the codebases.
Adding a new feature to an established codebase is like saying you want to redesign some structural walls on the 12th floor of a tower that was already built. Now you need a bunch of specialists to implement this change: structural engineers to look into the impacts of moving these structural walls, an architect to redesign the walls and room changes, electrical guys to rewire things, and so forth.
Just because you have a wish list for something doesn’t mean it’s easy to do, and this is particularly so for established products that have multiple codebases: the impacts sometimes are unknown until you start editing the codebase and working on that new feature.
It’s easy now to see why some things just don’t make it to a particular mobile version of a software product: it’s a big effort. This has to do with not only the complexity of implementing, but also the size of the audience that would benefit from such a change or feature. If for example, only 8% of your current field user base is using the Android app, while the rest are on iOS, then it makes no sense to spend a buttload of money, time, and effort to add that feature to the Android version of the app.
“Hybrid” apps to the rescue
Frameworks such as Xamarin, PhoneGap, and Ionic are what are considered “hybrid” approaches, where elements of a web app are combined with elements of a native app to allow a single codebase to target multiple operating systems. The nice thing about a hybrid app approach is that you can edit a single codebase and it can be deployed across multiple platforms while retaining the particular operating system’s user experience elements. So the app when deployed on Android looks and feels like an Android app, and when deployed on iOS looks and feels like an iOS app.
The mobile component of XForms is based on the Ionic Framework. Because of this, XForms can be deployed to iOS, Android, Windows Universal, and as a progressive web app fairly easily, all from the same codebase. Whenever we add a new feature to the mobile app, that feature is almost immediately available across all platforms without even having to push a new version of the app to the app stores. In many cases, the updates get pushed out over the air.
What does having a single codebase mean for the end user?
Well, when you can work on a single codebase and deploy it to a bunch of different operating systems, it means that you can deploy things faster and with fewer resources. Instead of having to have a different developer work on each separate codebase (eg, one to maintain the Java code for Android, another to maintain the Objective C code for iOS, etc), you only need 1 resource to do the job of all of those dedicated resources. So basically an org can develop a mobile app system in 1/3 the time and cost of a software shop that does it the traditional way if targeting iOS, Android, and Windows. If you’ve never read “The Mythical Man Month“, I’ll summarize it here for you: Productivity on a software project is reduced as a team size grows, making it even later than it already is. This is due to the exponential complexity of communications between the team members as you add more humans to it.
Cheaper software costs and faster deployment
Fewer resources means that you don’t have to be a ginormous corporate entity with hundreds of developers, product managers, and account managers to build something amazing, and you can do so at a much lower internal cost and timeframe. Imagine full-time software developer salaries…not cheap. If you can shave this by 2/3, that means you don’t have to charge as much to build the system in the first place. It also means deploying features faster than it would take to deploy that new feature to multiple codebases.
More consistent user interface across platforms
Using a hybrid app approach also means a more consistent interface. Yes, the app will look and feel like a native app for the particular operating system it is running on (this issue has mostly been solved now), and all of the elements of the app (eg, the menu nav, the buttons, the workflow, etc) will always be present and not missing from one OS vs another.
So what does this look like, in action?
Rather than continue to write a bunch about it, I’ll show you with a few animated gifs how XForms benefits from a single codebase on mobile. The videos below show a user adding a signature to a table using various different devices. Note that every device illustrated below is running THE SAME EXACT CODEBASE.
Here’s what adding a signature to a table looks like on an iPhone 6s
What it looks like when using the web app on Microsoft Edge on Windows 10 OS
On iPad Air in landscape mode
On a Samsung Galaxy Tab tablet (Android 7.0) in portrait mode
Want to learn more about XForms?
Click/tap on the button below.
