Woodridge Tech Talk

Our ongoing series of bi-weekly technical presentations

Choosing Between Native and Hybrid Apps

Pros and Cons of Native and Hybrid App Development


Native vs Hybrid apps are two different ways of writing your mobile application. Woodridge may use either depending on the type of your application, your risk tolerance of depending on a framework, and how much native functionality you need.

Native apps use frameworks and tools that are local to the platform. Going with a native-first approach would mean writing two separate apps, one for Android and another for iOS. On Android, you would write the app in Java or Kotlin. All of the layout would be done in the Layout Editor in Android Studio. On iOS, everything is done in XCode, with the code written in Objective-C or Swift and the layout done in XCode Storyboards.

Hybrids apps use a variety of techniques that allow you to write your application with a single codebase. That code is then compiled to the respective native platform. The end results of a hybrid compilation process are projects that can be used in Android Studio or XCode. The downside is that you cannot make changes in these projects without the results being overwritten the next time you compile.

In general, the more native features you plan on using (camera, GPS, Bluetooth), the more it makes sense to use a native app since these features are platform specific. The sensor APIs are very different between iOS and Android, which means that code reuse that would not be possible.

Hybrid vs native apps

(via https://www.topsinfosolutions.com/blog/hybrid-app-vs-native-app-debate/)

How Hybrid Apps Work

Hybrid apps work by embedding a web view (typically a WebView in Android or a WKWebView in iOS) and then sending information back and forth between a Javascript bridge. Any information that you want to send between the web view and the native side is done through message passing. This adds a layer of complexity and a mismatch between the objects inside and outside the webview, which can only indirectly communicate.

Look and Feel

If you use a hybrid app, your app will look the same on all devices, but it will not match the feel of the other apps. For example, a list view will not look like a default list in iOS, and you will not get the native features like pull to refresh or sticky headers by default. The native components, which are performant and have already been proven from a usability perspective, will not be able to be used inside of a web view. This includes the native maps component, scrolling list views, and camera previews.

native vs hybrid date selector

(via https://blog.mobiscroll.com/js-vs-native-controls-in-web-and-hybrid-apps/)

Certain types of information work better in a web view than in a native container. For example, anything document or text related is shown better in a web view. The web has always been a medium for displaying documents and only recently has grown into a format for web applications with the evolution of Javascript and HTML5.

Hybrid apps used to be slower, but the web views on both Android and iOS have improved and also techniques such as CSS-driven animations and transitions can perform reasonably well on newer phones. On older devices, native transitions would remain the best choice.

Cost-Benefit Analysis

When choosing a native vs a hybrid approach, you also have to consider the cost of maintaining two separate apps versus maintaining a single hybrid app. The more native functionality you need, the more overhead that will be needed to get the hybrid app to work properly.

The development environments of XCode and Android Studio are great for rapid application development. Since the mobile world has converged on two operating systems (iOS and Android), there are only two platforms you need to support by going native, versus the 4-5 in the past. This means that by going native there is much less to support than if there were more platforms.

Frameworks and Techniques for Hybrid Apps


Cordova is a popular choice for writing hybrid apps. Given some Javascript and HTML, Cordova generates an app for each platform which consists of a single web view. You write the app in HTML and Javascript, which gets loaded in the view. Then, there is a Javascript bridge and an interface that you can write plugins for. One downside is that the plugin ecosystem is active and many of the plugins you use have deprecated APIs that are not maintained. Any platform-specific functionality will have to be done through a plugin, including splash screens and native alerts.

React Native

React Native is different than Cordova, in that it dynamically creates native components orchestrated by Javascript. There are only a certain number of cross-platform native components implemented, but it gives you a native look. One of the downsides is that although you are using native components, you have very little control over the specifics of what is going on. This is due to the fact that you are writing code that gets compiled to native, not the native code itself. It then becomes more expensive and time-consuming to fix any bugs, although it might have been a quick fix with direct access to the native code.

Embedded Web Views for Specific Screens

Instead of implementing the whole app natively, you can use web views to show a specific page. For example, you might want to have a screen where a user can view his or her profile information. This page could be loaded from a server dynamically, meaning the page could get updated without the user having to reinstall the app. One of the downsides of having many separate web views is that the startup time is around ~1s even for a sparse page, so the user will have to wait for the information to be loaded.

One of the main pain points of hybrid apps is that it is difficult to “jump out” of the embedded web view or framework to a native view. For example, if you make a single screen native, then it would involve a large restructure to the whole app, since the hybrid app framework assumes your app is only structured a single way. Going native-first is the opposite. It is very easy to make a single page a web view and the rest of that app native.


In general, there is not a clear answer to what is the best approach to mobile app development. Our recommended approach will vary from project to project. Hybrid apps can be a good choice if you want to get a simple, MVP of your app to market as quickly as possible with minimum features. However, native apps will offer the best performance, user experience, and security. We recommend native applications to all of our clients if their budget allows for it. However, hybrid app development can be a cost-efficient way of getting a simple application to market quickly.

Categories: Mobile Apps, Tech Talk