In the past, Hybrid apps had a bad reputation in certain tech circles (and in some, they still do). While part of that is fair, things have changed a lot in recent years.
Mainly, technology has improved. Newer mobile devices offer better performance and faster web browsers; and the frameworks we use to create hybrid apps provide more effective access to native features.
Let’s take a minute to rewind with a couple definitions of what native and hybrid means within the context of mobile applications.
Native: Native apps are developed using a device-specific programming language (Java, Objective-C, Swift). They have direct access to the operating system of the device and are not portable. Meaning, a native iOS app will only run on Apple devices, and a native Android app will only run on Android devices.
Hybrid: Hybrid apps are developed using JavaScript, HTML and CSS. The code is then contained within a ‘native wrapper’ (such as PhoneGap) that gives the mobile app access to native device capabilities (such as the camera, notifications and more). In other words, hybrid apps run within a native app.
Because the core application is device-independent, it can be “re-wrapped” to use on multiple platforms. Having one code base has benefits, including lower development costs and faster time to market.
But, that doesn’t mean that hybrid is always the right choice.
Factors that will influence your team’s decision include:
- Required app features and functionality
- Budget & timeframe
- Number of platforms to support
- Security
- Performance
1. Native Vs. Hybrid Features and Functionality
Before choosing hybrid it’s important to be sure that what you need your app to do can be done entirely with hybrid code. Oh, and we don’t just mean now, but future enhancements as well.
When Apple or Android release their latest operating system update, the newest features are immediately available to developers of native apps. This is not the case with hybrid apps that rely on native wrappers and third party software libraries that may take time to be updated by their development team/community.
What this means is that if you plan to stay cutting edge, adapting your app to support the latest bells and whistles…a hybrid app will slow you down.
For many projects this is not an issue because the needed app functionality is already supported by hybrid frameworks, such as PhoneGap.
| Native | Hybrid | |
| Access to Native Features | Yes | Some |
| Camera | Yes | Yes |
| GPS & Location | Yes | Yes |
| Accelerometer | Yes | Yes |
| SMS | Yes | Yes |
| Notifications | Yes | Yes |
| Apple’s Touch ID | iOS 7 & 8 | iOS 8, limited functionality |
| Offline Access | Yes | Some |
| Available on the App Stores | Yes | Yes |
2. Budget and Timeframe
If your app must deploy on more than one platform, you will need an app for each. But, when you chose native, both apps will be developed from scratch, creating two separate code bases. However, when you chose hybrid, the code base can be shared within separate native containers.
This certainly doesn’t cut the cost to develop in half, but it does significantly reduce the investment of time and resources ($$$).
If budget is not an issue, and your team is not in a rush, hybrid will lose some of its allure.
Another point to consider is the cost to maintain separate code bases. If you expect frequent updates of the logic or content behind your app, hybrid has advantages. Many online news portals, such as BBC, choose hybrid for this reason.
3. Native Vs. Hybrid Security
Whether your app is native or hybrid there are security vulnerabilities. It comes down to how well the app is developed to prevent exploitation. Both hybrid apps and native apps are vulnerable to attacks if they contain poorly written code.
That said, because hybrid apps make extensive use of web views and HTML5, they are open to more risks than native apps.
Further, each platform (such as iOS and Android) have their own security features, but hybrid apps do not have access to all of them. There are techniques that hybrid apps can use to mitigate these risks. The problem is when they are not implemented, or not properly implemented.
If security is critical to your app (such as apps for healthcare or e-commerce) native is a safer option.
4. Native Vs. Hybrid Performance
Native apps do perform better…but depending on what your app is used for, you may never notice the difference.
3D graphic rendering (gaming) and animations will cause a noticeable slow down.
Native apps will also start faster, but when we’re talking numbers like 15% faster – that is hardly noticeable when applied to something that already starts in under three seconds.
What Do I Recommend?
That depends.
If I were having this conversation with an organization that needs to stay cutting edge using the latest native features, and envisions many future enhancements to their app, I would not recommend hybrid.
I would also not recommend hybrid for apps that will have a lot of animations, or complex data processing and manipulation.
When I would suggest considering hybrid is if the app needs to be deployed on more than one platform, but the budget (or ROI) is not there to justify the cost to develop multiple native apps….but only if the needed app functionality could be achieved with hybrid code, and security is not a critical issue.
