You have a great idea, you’re working on the business plan and considering all aspects of the business from product development, marketing, capital requirements, sales, and everything in between. In 2019, having a visually appealing and informative website is the bare minimum, but what about a mobile app? It’s pretty obvious on an intuitive level and backed up by this Nielson report that people spend the vast majority of their digital time on smartphones. So, that great looking website you have better look great on phones. If you decide that a mobile app for iOS and Android is necessary in addition to the website, there are quite a few decisions to make after that. What are the pros and cons of working with a development company, freelancer, or college friend that was into computers? How much is it going to cost? How long will it take? I still use a Nokia from 2001 so what’s iOS?
I’m going to keep this focused on another question: Should I build out native mobile apps for iOS and Android or go with a hybrid app?
Native mobile apps are called native because they are built with the native languages of their respective operating systems. Apple’s operating system is iOS and apps are built with Objective C or Swift. Most other phones run on Android, an operating system built by Google, and native apps are written in Java.
The biggest benefit of building native is performance. I won’t get too far into the details, but they open faster, respond to user input/commands faster, perform tasks faster, and did I mention… they’re faster. This performance boost extends to app features that need integration with phone hardware and software. Does your app require GPS, camera, or accelerometer input? How about the ability to make calls, send texts, and make payments? Another place native apps win out is that they store the application file locally on the phone. This means that native apps don’t require a Wi-Fi or carrier connection to open and work. If your app needs to have a connection to work fully, it can store data and requests until a connection is established. All this boils down to user experience. Unless your app is truly revolutionary and your customers cannot live without it, they won’t put up with a lackluster experience with wait times between screens and slow functionality.
Hybrid applications use web languages like HTML, CSS, and JavaScript in combination with native wrappers (these are sometimes called wrapper apps) to allow them to be downloaded from the App Store or Google Play. You can think about these as a desktop shortcut on your computer. It still has an icon like all the other apps but when you click on it, it takes you to a website with screens laid out like an app. No, you can’t see the URL bar or bookmarks or anything like that, but you are interacting with a stripped-down web browser.
The upside here is there is only a single code base to maintain. This translates into faster development times and easier maintenance. However, there are some drawbacks. As for tying into the software and hardware on a phone, the developer has to use a plugin for each one. Most of the time, these plugins are not maintained by the developer you work with so there can be uncertainty with the maintenance quality and consistency. This is especially evident when iOS or Android push out updates or new features. If you don’t have a great technical partner, your app can behave in unexpected ways or break all together.
Two other drawbacks with hybrid apps are their need for an internet connection and an inability to store data between sessions. Since these are web-based, when the user clicks on the icon to open the app, a request is sent out to the server where the app lives, and data is sent back to the phone. This happens in almost every interaction with the app. If the user is in a place where there is a poor connection, this can lead to slow app responsiveness. Also, since these are web-based, the apps open to the home page every time they are opened. This works just like closing and opening a browser window on the computer. If the user is filling out a form, for example, and closes the app for some reason, all that data is lost.
To the Sr Managers and CxO’s reading this
One of the best use cases for a hybrid app is when you are trying to make your employees’ workflow more efficient. If there is a process or task that takes up a large amount of time or is inefficient, an app can be a great way to solve that problem. The downsides I mentioned above don’t apply to a captive audience, like your employees, that don’t have another choice for work-related apps. And, I would be willing to bet that the efficiency created with the hybrid app will far outweigh the relatively minor inconvenience of not having break-neck performance. As an example, we’re working with a distributor whose sales team receives calls, texts, and emails about available stock. The sales team then has to call or email the sales operations team to check inventory and wait for the response. Finally, they get a response and can send that along to the customer. A great way to fix this is to build a simple hybrid app that ties into their existing inventory management system that allows sales to check the inventory instantly. Programmatically, this is a fairly simple project but it made a huge difference to their business.
A note about cost
Developing and maintaining a native mobile app for iOS and one for Android is more expensive than building a single web or hybrid app. However, it’s not double. Applications have three parts, a front end, a back end, and an API. With a mobile app, the front end is what the user interacts with on their phone. The backend is where the data resides on the servers (AWS, GoDaddy Hosting, the old tower in your mom’s basement, etc.…). The API connects the frontend to the backend. To build a native app for both iOS and Android, a frontend and API must be individually built for both operating systems, but a single backend can and should be used for both. I would argue that if your business absolutely needs a mobile app for people to interact with, the cost of native development is well justified.
Summary
Making the decision between hybrid and native is a big one and shouldn’t be taken lightly. One of the toughest (and most expensive) technology mistakes you can make is deciding to switch from hybrid to native or vice versa if the first route doesn’t pan out. I recommend finding a technology partner you trust to help go through your specific business case. I’m a little biased but, I hear FarShore is pretty good in this realm so give them a try… or you can stick with that college friend who’s into computers.
