Are your organization’s mobile apps hybrid or native? A combination of the two? Or just a Web View?
You may be asking yourself why you should care, but the distinctions between the two types can impact your company in ways you might not imagine. Native apps are specifically designed for a particular operating system and to fully leverage the capabilities of that OS. If all of your company’s mobile devices run on the same OS platform, then native apps definitely are for you.
But most companies and their employees use devices that run on various operating systems or different iterations of the same OS. Hybrid apps are developed in one OS, then migrated to others. Development can occur in quicker fashion using this approach, but user experience and performance can suffer, so there can be tradeoffs.
There are many places where hybrid apps make perfect sense:
- When a company has a lot of people in a particular technology and wants to retrain them to create mobile apps
- When an enterprise is not fixed on the platform and might switch to a different OS in the near future
- When the apps do not rely heavily on hardware features
To determine the best approach, companies must weigh what they are trying to accomplish against the budget, development tools they have invested in, the skills of their internal IT staff and other factors. We help our clients not only answer these questions, but also bring maximum value out of their IT investment. In some cases, companies have resources on a particular technology and believe they can leverage that technology to build mobile apps. However, many soon realize that mobile development is beyond their internal capabilities.
Native vs. Hybrid
Hybrid apps get all of the press because third-party vendors make software that can translate mobile apps from one platform to another. Market something aggressively enough, and attention will follow.
Because they are provided by the platform (Apple, Google, etc.), native application platforms have a lower profile. Until a few short years ago, native was the only way to go. Hybrid platforms were initially marketing as a way to slash development costs by as much as 30%. The development cost of two apps would be 130% versus 200% if each app was development independently. The more platforms a mobile app was translated into, the lower development cost for each app.
The flip side to lower development costs is higher QA costs with hybrid apps. A common code base applies to all platforms, so a change in code means that all of the platforms and devices need to be tested. At the end of the day, the app should work as intended, making QA a critical part of any cost equation. As the number of major operating systems has dwindled, overall development costs remain about the same between native and hybrid apps.
This approach seeks to make a web application, built within a “responsive design” framework, available as an installable native app. It is basically an app that uses an embedded browser (called WebView) to pull a URL off the server.
This is not a hybrid nor a native app, because it’s nothing but a shell. These apps did initially make its way through into the Apple store. However, what Apple quickly realized is that once the app went through the screening/verification process, the creators could change the pages in the server without going through the screening/verification process again. This did not make Apple very happy. And as of today these kinds of shell apps are being rejected by Apple.
Responsive is more of a state of design than a state of app. Native and hybrid mobile apps are what your company should be focusing on.