Hybrid applications could also be called containerized mobile apps. The driver behind hybrid app development is that it allows a single codebase for use on multiple devices in multiple operating systems. Each hybrid app framework takes a slightly different approach to this problem space using a native shell running code inside itself on the device.
Cordova and PhoneGap are two popular wrappers for hybrid app development, but are not the only way to leverage this approach. A wrapper is a native app that is also the visual and technical container for WebViews. Any combination of native and WebView can be used to fulfill the mobile user experience.
There is a perception that hybrid apps suffer from a higher security risk than other app development efforts. Each mobile approach requires its unique security considerations, and hybrid app development is no different. Best practices around server-side security, code hardening (protecting against common exploits), and encryption must be followed in any app development. The introduction of a third-party wrapper does introduce a layer outside of your control, and as such, applications with high-security requirements should prioritize cross-compiled or native app development.
While hybrid apps enjoy access to native API’s, it comes at the expense of performance.
Since everything is running in a WebView, there is no performance lift that native apps and native API’s provide. There are more ways for the engineering effort to be over or under engineered. It is essential to develop these applications with a team experienced in both progressive web and native apps.
Discoverability: App marketplace; search engines; direct links to the app stores
If an Apple App Store or Google Play Store presence is required, this is the quickest way to go from a web app to the app marketplace.
App updates: App marketplace and server-side
A full update of all functionality requires an app update. Depending on the work done, there may be an ability to do server-side updates that push new functionality when the app loads.
Supported devices: Dependent on hybrid approach used
Each hybrid architecture comes with a certain reach and will need to be evaluated on a case-by-case basis.
Network dependency: Some functionality without connectivity
Since hybrid apps live in native wrappers, there is often limited functionality that can run offline.
Certification: Certification required for each store
Hybrid apps face additional scrutiny. If an app could function as a website, is not performant, or doesn’t scale to device sizes properly, it might have a lengthy and costly approval process.
The effort required to build a hybrid app is often slightly less than the effort to build a cross-compiled application or two native applications. Code quality is the driver of speed to market and maintainability. Access to device specific API’s are available either by writing native code per platform or via a plug-in.
Performance: Decent, but dependent on code quality
These apps can feel like native apps when they limit network usage and fully leverage the
benefits of the native wrapper.
Time to market: Warrants approval process
Hybrid apps are essentially web apps in a native shell; much of the development process is the same. There is the added complexity of app marketplace approvals.