Native Vs. Hybrid App Development: 5 Reasons To Go Native
November 1, 2016
In the developer world, there is a never-ending argument for which approach is the best platform for mobile software development. Despite strong cases in favor of native mobile development, there are some individuals in the industry who still think that hybrid mobile app development is the way to go. Today, I want to share some of our beliefs about hybrid vs. native development. As mobile software is increasingly a necessity for companies, it’s important for a company or mobile product owner to be well-informed on the pros and cons of choosing either a hybrid or native mobile app development approach.
The Definitions of Hybrid vs. Native
It is important to fully understand how both hybrid and native mobile application platforms function and how to distinguish among the three different degrees of non-native applications and their differences with natively developed applications.
Native iOS applications are built with the iOS Software Development Kit (SDK) in the Objective-C or Swift programming language. Native Android applications are built with the Android SDK in Java. Because these apps are written for their particular platform (iOS or Android), the apps can take full advantage of the software and operating systems’ features. This kind of development offers the best user experience.
Finally, there are platforms that package an additional library of code that maps Android and iOS native code to another language. We’ll call this ‘faux native’ – Xamarin and Appcelerator are examples of faux native applications.
Both web-based hybrids and faux natives translate code from a non-native language to the native languages of mobile platforms. Web-based hybrids take advantage of native features by interpreting code running in a web browser, while faux natives perform a similar translation, but do so by generating the native code prior to shipping the application.
Now that we know the definitions of each platform approach, let’s discuss the 5 reasons why a brand or mobile product owner should consider going native.
5 Reasons You Should Go Native
The hidden cost of hybrid mobile app development.
It’s a common saying within software development that the last 10% of a project is 90% of the work. In some ways, this is true; it’s relatively trivial to build something functional compared to taking something from functional to something competitive in the marketplace. Crucial features that compete against other applications are developed during the last 10 percent of the project; this is where the hybrid approach starts to show its flaws.
With web-based hybrids, native mobile features can only be exposed through plugins written by other developers. This can be a negative part of hybrid development because it’s possible that the appropriate plugin doesn’t exist or that an existing plugin has not been maintained for recent operating system versions. The cost and time to develop this plugin far outweighs the cost to utilize the existing feature in a native application.
Native platforms have nuances, big and small, between them. It is often the case that the hybrid code must account for these nuances depending on the platform they are executing on. When this is the case, a developer must choose between ‘dropping down’ to a lowest common denominator solution that spans both platforms or writing code to support both platforms in the same codebase. Not only does this defeat the purpose of a cross-platform solution, it is much more difficult to maintain two different applications in one codebase than it is two applications in two codebases.
They may make changes to the low-level format in which applications are to be submitted to the Apple App Store that have the potential to render platforms like Xamarin inoperable in the future. The cost to fighting the system increases exponentially as time goes on, too. There is too much invested in the product to start over, but the truly competitive features aren’t done – and perhaps aren’t even possible, depending on the hybrid platform choice. The hybrid approach tricks stakeholders into a false sense of progress until it is too late to switch and the inferior product simply must be shipped. All the while competitors continue to adopt new platform features with little resistance.
This problem is most pronounced when new versions of Android and iOS are released. Native developers are given early access to the new software development kit (SDK) to start building their applications with recently added features. Because of this lead time, users of native applications have access to new platform features the day they update their phone to a new operating system. This is an important part of generating loyalty amongst its users.
However, developers working with hybrid approaches must wait for the third-party developer of the hybrid tool to implement the bridge to new operating system features.
Specific to Apple, because of legal reasons, hybrid platforms cannot release their updated toolset until the new iOS version is released. This gives natively-developed applications between three and four months of extra development time to support the newest features in the best case. In the worst case, hybrid platform vendors may never support them.
The native codebase will be easier to build upon in the future and be more adaptive to the changing mobile landscape. In the end, choosing a native approach will save you time and money and ensures your product is the highest of quality because a native codebase will be easier to build upon in the future and be more adaptive to the changing mobile landscape.
Technical reasons against hybrid
A hybrid application will never match the speed of a native application since it has to go through an additional layer. Additionally, in-application browsers for both iOS and Android are fairly liberal with their system resource consumption, so it becomes difficult for web-based applications to support cheaper and older phones that have less power.
Hybrid applications are unable to leverage many of these tools. iOS and Android toolsets for designing user interfaces wield amazing power and are integrated into highly sophisticated layout systems. Native development environments have deeply integrated tools for both diagnosing issues and for ensuring code works before releasing it.
“It’s a known fact that hybrid apps don’t perform as well as native apps, so if you’re going to choose a hybrid, make sure you’re aware that your users’ experiences will likely suffer.” -Robbie Abed, Y Media Labs
If there is an issue in a hybrid application, a developer must evaluate its code, the code in the hybrid library they are using, and the native code they may have built as plugins. Sometimes, the issue may be in the hybrid platform itself, and developers aren’t able to fix it. This time-consuming debugging process is incredibly costly and likely inevitable. Finally, as the mobile market expands into wearables, television sets and the Internet of Things, the hybrid approach becomes even less compelling.
It is currently – and will likely remain – impossible to build an Apple Watch application with a hybrid platform. The best way to stay on track with the future of software development is by choosing development technologies that support all of the innovative, new platforms.
It is important to understand the security risks of hybrid applications. Every layer in an application introduces an opportunity for a new attack. Hybrid applications add a new layer that bridges their non-native code to native features. Additionally, since this layer is owned by a third party, the code in a hybrid application’s compatibility layer cannot be inspected by a user of that library.
Even if the hybrid platform itself is safe now and forever, the community-developed plugin architecture of platforms is a security concern. For every native feature that must be accessed in an application, a plugin must exist. Any code that goes into an application – especially banking or healthcare applications – should be reviewed for potential security issues. Therefore, a project that must consistently do this for all features will move very slowly.
Write once, run anywhere
This is not the first time the dream of ‘write once, run anywhere’ has been marketed to enterprises. Five years ago, Gartner Research predicted Adobe Flash, Qt, Silverlight and JavaFX would become increasingly popular through 2015. Now, those platforms are not part of the mobile conversation at all. The same conversation happened with Java web and desktop applications 20 years ago.
Cross-platform is accomplished through web services
Instead of viewing mobile applications as cross-platform, a business needs to view its entire platform offering as cross-platform. Mobile clients are simply user interfaces to a larger ecosystem of servers and databases. Allowing access to a company’s software offerings across platforms is done by shifting data and logic into web services.
Mobile clients are responsible for fetching, presenting and manipulating that information, but the web servers and databases hold and verify the truth of that information. Mobile clients, then, are able to focus on meeting user expectations for the platform. This is beneficial because the part of an entire software platform that verifies data integrity is written only once and is able to securely vend out the appropriate information to client applications for presentation.
Instead of investing money and time into a hybrid, cross-platform development approach that will most likely have an expiration date, the cross-platform should live in the backend. When a company invests into a powerful backend platform, its product can ensure stability overtime. A powerful backend has the ability to keep both iOS and Android software up to speed.
The one pro to hybrid development
Even with the numerous reasons why a company should reconsider a hybrid approach, there is one positive part to choosing hybrid. Software provides solutions to a variety of problems, so when the goal is to give access and power to consumers, hybrid isn’t a good approach. However, software can use hybrid solutions effectively if the software does not have to take advantage of native features or compete in a consumer marketplace. For example, teams will often use hybrid solutions to provide in-house tools to their staff. In this case, they are solving an internal business need instead of trying to compete in a consumer market by offering a first-class user experience.
There are plenty of other pros to native development, so if you are not sold, check out this article called “From Native from Hybrid App Development and Back.” The article shows an example from Roi Kraus from LTG on how his company started with hybrid development and had some regrets. What do you think? Is native the right approach? Let us know!
Does your brand needs an app? Read our free guide to find out if you or your company is ready.
[av_button label=’See Guide’ link=’manually,/wp-content/uploads/2017/07/Does_My_Brand_Need_An_App_Guide.pdf’ link_target=’_blank’ size=’large’ position=’center’ icon_select=’no’ icon=’ue800′ font=’entypo-fontello’ color=’custom’ custom_bg=’#FF8919′ custom_font=’#ffffff’ custom_class=” admin_preview_bg=” av_uid=’av-1waik0′]