Pros and Cons of Native and Hybrid Application Development

Native and hybrid apps are two different ways to write a mobile app. Bragona Technologies can use either depending on your app type, your willingness to risk dependency on the framework, and how much native functionality you need.

Native applications use frameworks and tools that are local to the platform. Using a native approach means writing two separate apps, one for Android and one for iOS. On Android, you will note the app in Java or Kotlin. All the layout will be done in the layout editor in Android Studio. On iOS, everything is done in XCode: the code is written in Objective-C or Swift, and the layout is done in XCode Storyboards.

Hybrid apps use different techniques to write the app on a single code base. This code is then compiled to the appropriate native platform. The end result of the hybrid compilation process projects can be used in Android Studio or XCode. The disadvantage is that you cannot make changes to these projects without overwriting the results the next time you compile them.

The more native features you plan to use (camera, GPS, Bluetooth), the more it makes sense to use a native app because these features are platform dependent. The sensor APIs are very different between iOS and Android, which means reusing code that would be impossible.

How Hybrid apps work

Hybrid apps work by embedding a web representation (usually WebView in Android or WKWebView in iOS) and then sending information back and forth over a Javascript bridge. Any information you want to send between the web view and the native side is sent via message passing. This adds a level of complexity and inconsistency between objects inside and outside the web view that can only interact indirectly.

How it looks and feels

If you use a hybrid app, your app will look the same on all devices, but it won’t match the feel of other apps. For example, the list view will not look like the default list in iOS, and you will not get native features such as pull to refresh or sticky headers by default. Native components that are high-performance and already proven in terms of usability will not be able to be used inside the web view. These include the native map component, scrolling list views, and camera previews.

Certain types of information work better in the web view than in the native container. For example, anything related to documents or text displays better in the web view. The Internet has always been a medium for displaying documents and has only recently evolved into a web application format with the development of Javascript and HTML5.

Hybrid apps used to be slower, but web views on Android and iOS have improved, and techniques such as animations and CSS-based transitions can work quite well on newer phones. On older devices, native changes remain the best choice.

Cost-benefit analysis

When choosing between a native and a hybrid approach, you should also consider the cost of supporting two separate apps compared to supporting one hybrid app. The more native functionality you need, the more overhead you will need to run a hybrid application properly.

The XCode and Android Studio development environments are great for rapid app development. Since the mobile world has converged on two operating systems (iOS and Android), you only need to support two platforms by going native, as opposed to 4-5 in the past. This means that you need to support far fewer platforms when moving to a native platform than you would if there were more.

Frameworks and techniques for hybrid applications

Cordova

Cordova is a popular choice for writing hybrid applications. With some Javascript and HTML, Cordova generates an application for each platform that consists of a single web representation. You write an application in HTML and Javascript that loads into the view. Then there’s a Javascript bridge and interface for which you can write plugins. One drawback is that the plugin ecosystem is active, and many of the plugins you use have legacy APIs that are not supported. Any platform-specific functionality must be implemented through a plugin, including screensavers and native alerts.

React Native

React Native differs from Cordova in that it dynamically creates Javascript-driven native components. It only implements a certain number of cross-platform native components, but it gives you a native look. One drawback is that although you use native features, you have very little control over what happens. This is because you are writing code that compiles to native, not native itself. Fixing any bugs becomes more expensive and time-consuming, although, with direct access to native code, they could be fixed quickly.

Embedded web views for specific screens

Instead of implementing the entire application natively, you can use web views to display a specific page. For example, you might want a screen where users can view their profile information. This page can be loaded dynamically from the server, meaning it can be updated without reinstalling the application. 

One of the major issues with hybrid apps is the inability to “step out” of the built-in web view or framework and into the native view. Assume you create a single native screen. For example, suppose you make one screen native. In that case, it will significantly redesign the entire application because the hybrid application framework assumes that your application has only one structure. When you switch to a native approach, the opposite is true. It’s straightforward to make one page a web representation and the rest of your application native.

Conclusion

There are many answers to the question of which approach to mobile app development is best. Our recommended approach will vary from project to project. Hybrid apps can be a good choice if you want to bring a simple MVP of your app with a minimal set of features to market as quickly as possible. However, native apps provide the best performance, usability, and security. We recommend native apps to all our clients if their budget allows it. However, developing hybrid applications can be a cost-effective way to get a simple application to market quickly.