Native Vs. Hybrid – Which to Choose for Your Mobile App

Native Vs. Hybrid - Which to Choose for Your Mobile App

Native Vs. Hybrid – Which to Choose for Your Mobile App

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.

Like this post? Please share:Share on LinkedInTweet about this on TwitterShare on FacebookShare on Google+




We Develop Custom Applications

Looking for a team to help bring your mobile app to life?






No Comments

Sorry, the comment form is closed at this time.