Smoke and Mirrors: the Hybrid vs. Native App Debate

There’s a reason the hybrid vs. native app debate never seems to go away; it isn’t a debate at all.

Sure, many people (especially within the mobile app industry itself, us included) have strong opinions and are willing to passionately extol the virtues of their approach while ridiculing the other side. However, in app development as in politics just because you see a lot of smoke doesn’t mean there’s a fire. At the end of the day, what we are talking about is a business decision depending on 3 factors: market needs and expectations, budget and timeline.

What you need to know

What’s the difference between hybrid and native mobile apps? Hybrid apps are web apps wrapped in a thin, native shell allowing them to have some of the feel and functionality of native apps. Hybrid apps are built using popular programming languages like HTML, CSS and Javascript and then given a native wrapper using a framework like Cordova. These apps are cheaper, ready for market sooner and generally easier to maintain.

Native apps are built using the language of the operating system itself (Objective-C for iOS and Java for Android). This gives them better performance, full access to the phone’s hardware and software (eg. the camera and Bluetooth) and enables full usage of the phone’s UX interactions (double tap, pinch spread, etc.).

Hybrid Native
Pros Cons Pros Cons
Cheaper origination costs Slower Better
performance
Multiple
code bases (one per operating system)
Portable
(single language and code base)
Depends on
special plugins for hardware access
Access to
hardware and latest OS features
App store
restrictions
Faster to
market
High
maintenance
User is
already familiar with UX
Requires
larger initial investment

 

Making the choice

The key is knowing your market. If your app requires access to the phone’s hardware or factory software, native is the way to go. Hybrid apps depend on plugins to take advantage of the phone’s native features. An app that depends on access to the phone’s sensors or camera needs to be native to guarantee constant access to those features. Imagine the chaos if the manufacturer pushes an upgrade that isn’t supported by the plugin you used for your hybrid app. For example, a significant proportion of our work is with startups building some sort of smart hardware. In these markets, the connection between the phone and the hardware and the usage of the phone’s native sensors necessitates a full native approach due not only to access to the phones internal systems but also to security and connectivity concerns.

If your target demographic prizes access to the latest technology or is fiercely brand loyal, native will enable you to give them what they want. Some people have inexplicable connections to particular brands, while others don’t react well to change. Native will appeal most to this subset of people as learning to use your app will be a breeze because it mimics the UX of the operating system. Imagine you’re a PC person whose never touched a Mac before. You hear about this cool new web app and immediately download it. But, as you begin using it, all of the commands and shortcuts you’re used to don’t work because it functions as though it’s on OS X.

At the same time, there are also situations where a hybrid app will better fit your needs. If it’s most important to get a prototype or MVP out there as quickly as possible, then hybrid can make it happen. Likewise, if you need greater freedom to update your app and to do so quickly, hybrid may be the way to go. Because of the single code bank, less time is needed to take the initial product to market and to update your app with new features, bug fixes, etc.

Our take on hybrid vs. native app development

At 12Rockets, we believe native is the way to go, thus all apps we build are native. As mobile enthusiasts, the sacrifice in performance and user experience is not something we can get over. We understand that there are certain situations in which the cost-benefit calculation legitimately comes out in favor of hybrid apps. For example, initial prototypes – especially high fidelity ones built to wow potential investors and gather early feedback from ideal users – can effectively and economically be built using a hybrid framework. We’ve happily built such hybrid prototypes many times because they can be key step for early stage or bootstrapped startups to validate their ideas and land funding prior to making a full investment in the final native app.

Although some have recently called for a ceasefire in the hybrid vs. native app debate, we’ve had a number of conversations with startups looking to transition from their hybrid app to fully native. Of course, this isn’t enough data to talk about any wider trends, but it does lend credence to what Roi Kraus’ recently advised in TechCrunch- when deciding the hybrid vs. native app question, put the needs of the user first and build thinking not only of the features the app needs now but also those it will need in the future.