This blog originally appeared on Mendix.com on June 10, 2013. Check it out here.
A place exists in the enterprise for both mobile and hybrid applications, beyond the native applications that you’ve used for several years. I’m speaking here of business applications; Angry Birds doesn’t count as business software even if you play the game while waiting to get through the security line for a business flight.
But first, what the heck is a “native” application and what are the main differences between it and a hybrid app?
First, let’s define what a mobile application is. A mobile application is software written for mobile devices (i.e. tablets or smartphones) that perform a specific task, such as a game, calendar, or music player. Seems simple enough, so what’s the deal with this Native vs. Web (or Hybrid) application all about? I’m glad you asked.
- Native application: Software runs on the device’s internal software and hardware, such as iTunes on an iPod.
- Web application: Software runs through a Web browser (Internet Explorer, Safari, Google Chrome) and relies on Internet connectivity to accomplish its task. If you ever accessed Gmail through a browser and sent a file, you were using a “web app” for Gmail.
- Hybrid application: Software runs on a device’s internal software but utilizes Web connectivity to accomplish certain tasks, such as syncing contacts across devices. One of the more popular hybrid applications in use today is the LinkedIn mobile application.
Ok, that seems simple enough, so what’s the big deal?
Really, there isn’t one. There is actually a purpose for each of these architectures. When it comes to responsiveness and graphics (such as gaming), native applications are the way to go. Once the application initially loads (like the startup time for Temple Run (I hate those monkeys!) or Angry Birds) you are off on your own little handheld adventure. For the developer and the business, native applications are great because you can “maintain a presence” in an app store (like Apple’s App Store or Google Play) for all your clients to see.
So if I am a business decision maker, Native apps are the way to go, right?
Not necessarily – and most of the time, I would argue No.
(Please excuse me for the consultant waffling that is about to commence.)
One of the biggest assets of native applications (for businesses) is also one of its greatest weaknesses. Native applications typically store data locally on the phone or tablet, so if the device gets stolen or lost so does the data (unless they find your iPhone and intend to wipe it). The next largest issue / inconvenience is that they become hard to control or manage. For any of you familiar with my other posts (Google “software cost curve”), the main cost of software is not the development but rather the maintenance. If you are developing one application to run on Android, iOS, Windows, and Blackberry (to cater to all of your different users) multiply that cost by some number greater than one. Just to maintain one application (say a hospital check-in system) you would need four above-average developers (one for each platform) to develop and maintain the software. This is a huge risk to any business in itself, as employees can come and go faster than the lifecycle of an application.
In addition, you cannot control the frequency of when your users update their application by downloading the latest version from the app store. This means you may be stuck maintaining multiple different versions of the same application.
Enter Web applications and Hybrid applications. These solve these two core challenges immediately. First, since all data lives on the server, a lost phone does not mean lost data. Second, you can develop one application (that utilizes HTML5) which should (for the most part) work on all the different devices your organization aims to support. This also conveniently addresses the cost curve, because anytime a user “logs in” he is accessing the most up-to-date application. This means no more maintaining old apps, as everyone has the latest and greatest functionality. One development team can maintain the application for all users, regardless of device and operating system, and it can spend more time developing new features or debugging and less time on maintenance. So from a data governance and version management perspective, Web based mobile applications are superior.
Ok Mike, this sounds great: What about the web presence we want? We need our clients to find us in the app store.
No problem: You can achieve this too. Simply by using an application like PhoneGap to compile and “wrap” your application and login functionality, you can offer your application in an App Store.
So… What are you saying Mike?
A market will continue to exist for both Native and Web applications, as well as the combination thereof. Each has its strengths and weaknesses but the negative stigma toward one or the other is probably off base. Internet connectivity is improving (see LTE “revolution”) around the globe, but it probably will never be fast enough to satisfy the needs of the most hardcore gamer (or stock trader for that matter). (I think Facebook is partially responsible for this polarization between native and web because of its initial commitment to HTML5 and then subsequent back tracking.)
Ultimately, the decision to go with a native or Web-based application is not a good or bad decision; they are just different. It is more important to understand the requirements of the system you are trying to build and the needs of your users; then understand the strengths and weaknesses of each model and choose accordingly.
Is there a place for both Native and Web Applications in the future? What do you think? Which operating system do you think business will favor most? Let me know in the comments below.
Download eBook:
Enterprise Mobile Apps – Are you ready to enter the ring?
Picture courtesy of MobileNext.
