As a former Business Development Manager, I’ve tackled this debate hundreds of times. Since our team favours performance over speed of implementation and quality compromises, in the last couple of years we’ve been defending native development as the best production environment for a mobile app.
However, things change and since we are a team of highly-qualified developers, in the last two years we’ve been researching, studying and even building some of our apps as hybrids. Don’t get us wrong – we still believe native is the best way to go, but there are instances where hybrids shine a tad brighter.
Under such circumstances, we’ve decided to advise whenever it’s worth building a hybrid app and which are those cases that make a react-native or ionic app a clear winner. Let’s start with defining them to deliver a better outlook on what a hybrid application is as compared to a native one.
Just to mention here: in hybrid, we’ll include cross-platform frameworks as well and will elaborate on hybrid vs cross-platform differences in another post.
What’s the difference between a hybrid and a native mobile application?
A hybrid app acts as a web application inside of a native application. I know, at first it might sound confusing, but to put it in perspective, such an app (if desired) can be accessed through your mobile web browser and it will still be usable. The reason most developers choose to run hybrid apps using a native app wrapper (which is essentially an isolated instance of the platform’s web browser on steroids or Native UI components) is to gain native access to essential components such as geolocation, storage or camera. In other words, the web application performs the logic while the app warper facilitates access to iOS or Android components. Hybrid apps are usually written on frameworks such as Ionic or Apache Cordova.
As compared to hybrid apps a native application is built as per each platform and has direct access to the platform’s components. This is why native applications are snappier, work seamlessly with your camera, storage and GPS. In addition, these have a better User Experience since they are forced to use default platform UI guidelines and standards, making the app more familiar to an Android or iOS user. Needless to say: due to the fact that each app is written on the platform’s codebase (Java/Kotlin for Android and SWIFT/Objective-C for iOS), native applications are superior in matters of performance since there is no middle-mile (the app warper) between the backend’s API and system components. With these in mind – if you’re not ready to compromise on the UI or the app’s performance, the native approach is an obvious choice.
Now, assuming you don’t like to read a lot, here’s a datasheet approach to screen differences between a native and a hybrid app:
Hybrid / Cross-platform Applications
iOS (Objective-C / SWIFT)
HTML, CSS, Java Script
iOS (Objective-C runtime)
Various, depending on the chosen framework
# of environments
Separate environments/code as per each platform
One environment for all platforms – write once, run everywhere
Light on physical resources.
At least 1.5 times heavier on physical resources
Delivers the fastest response and performance to end users
Compromises on UX quality and response times to run a single environment
Twice the time as compared to hybrid
fast delivery cycles enabled by one code/runtime environment
Twice the cost as compared to a hybrid app
½ of the cost as compared to the native approach
iOS – all based on SWIFT/Objective-C code
Mobile Angular UI
What are the pros and cons when building a native vs hybrid application?
In most of the cases, these are related to your business scope. Depending on your logic, a hybrid app might be a better way to reach your end-users and deliver add-value through your service. In the last two years companies like Evernote, Amazon and Netflix, opted for hybrid mobile versions instead of building native apps. Since their scope is not relying on immediate access to your device’s components, it makes perfect sense to go with hybrid development.
In addition, for such giants, it is better to maintain and improve on a single codebase instead of doing so for 3 different platforms (Android, iOS and the Web).
For instance, let’s consider Netflix’s business model: their users would rarely use one device and would consume media on their laptops, TVs and various cast-oriented devices.
If Netflix had chosen the native approach, they would’ve released the same app for Unix-like OSs (which power most TV-sets), for UWP-enabled devices (that count over 700 million instances worldwide), as well as for Android and iOS-enabled terminals.
Considering variations, this would draw a maintenance nightmare. Imagine pushing one simple update to at least 8 code-bases, taking into account dependencies, current structures and runtime environments. That means a simple improvement could take from 6 to 8 months in delivery terms and since Netflix users are people who want it now – these time-frames are simply unreasonable. Hence, delivery speed takes precedence and considering recent performance improvements in hybrid/cross-platform frameworks (ghm-ghm – React-Native) there is little or nothing to compromise over.
Following the above statements, we should all go and start building hybrid applications. However, the story ain’t nearly over. Let’s take a more pragmatic approach to compare hybrid and native apps, in base of your business model. The best way to do it is by covering a few essential questions related to a potential build:
Are you building a full-fledged app or a Minimum Viable Product?
Depending on your answer, the pros and cons may vary. So let’s dig in: If you’re building a Minimum Viable Product (or MVP) consider your core business logic and how much it relies on direct access to OS components (like GPS, storage, camera, microphone, etc).
Then, If your MVP relies heavily on access to certain device hardware (i.e. accessing the NFC hardware for payments or the fingerprint scanner for authentication) you should probably choose the native approach. Otherwise, if such requirements aren’t aligned to your scope, a hybrid build would make more sense in matters of development timelines, required talent and budget.
Surprisingly, the same approach goes for full-fledged apps. If access to physical hardware of an iOS or Android device is paramount – it makes sense to choose native development.
Then again, if you’re a streaming giant like Netflix, or if your service focused on a Software as a Service premise, without the exclusive requirement of direct access to device components, building a hybrid app might be a better fit for you.
What features are you ready to sacrifice?
It is no doubt – in matters of hardware and/or OS-related feature access (like 3D-touch or instant NFC Sharing) a native build has no competition. It’s the Swiss Knife of Android or iOS SDK and there are no limits in matters of features you’d like to populate your app with. In addition, native apps are easier to change, manage and enrich (as long as you’re willing to involve additional resources as per each platform).
On the Hybrid side, you must be ready to sacrifice OS or device-related features and gain rudimentary access to hardware. In addition, since all of the interaction is made through an app warper, it’s no wonder why hybrid apps take a bit more to perform camera or voice-related features as compared to native apps. Again, this is OK if your business logic does not require 3D-touch or Split-Screen features. Otherwise – it’s worth to go with a native build.
How important are Native UX premises to your public?
Hybrid apps will always look a bit different when compared to native apps, so you really need to understand how important is a native User Experience for your audience. Try making an iOS user live with an Android device for a day and vice-versa. The same goes for your app’s user experience. Native apps tend to match the device’s experience, therefore, a user might get familiar with a native app faster as compared to a hybrid app.
On the other hand, if your purpose is to serve convergence to an already trained audience, familiar with your product’s layout – building a hybrid interface might be an even better idea (especially if your product performs well without those OS or hardware-related gimmicks). This is why we have React Native today: Facebook focused on their desktop User Experience and built one interface for iOS as well as for devices. This way – a Facebook user would find the mobile version as familiar as the desktop version they’ve spend thousands of hours on. In this case, their user’s day-to-day experience with the desktop app took precedence over native experience approaches or each platform. They’ve even found a way to diminish hybrid shortcomings, but about that, we’ll elaborate in another post.
How tight is your budget?
When talking about money – hybrid apps are considered tiny-little gems. Since you’re building on a single code base there are fewer people involved, hence you spend less on building a hybrid than you’d spend on building a native app. You could actually save half of your money. However, there are some things to be considered.
If you are building an MVP that relies on heavy device access, you’re most likely to rebuild native versions when releasing a second version. Given the circumstances, expected to spend thrice as much as those savings, especially if rebuilding the API is required. Same goes with full-fledged apps – the only difference here is that you might need tenfold of what you’ve saved at the first app release.
Maintenance-wise, a hybrid app can reduce your costs by almost 60%, considering the app’s warper dependencies and the system architecture you’ve gone with.
Overall, building a hybrid application will definitely be cheaper. However, consider building an entire roadmap for your app (at least for 2-3 years) to make sure a native switch would not be required for at least 3 to 5 years.
Is speed of delivery paramount in your business model?
MVPs are characterised by a fast delivery model, so regardless of the approach you choose – the difference is one or two weeks, which isn’t really essential.
When talking about building full-fledged applications, we’re approaching a totally different story. A hybrid approach might be the best way for verified business models, especially if their logic requires rudimentary hardware access and fast feature deployment.
In these circumstances, a hybrid approach could save half of the time spent on building mobile apps and generate scarce resources that can be allocated to developing a more robust architecture or back-end. This is true for multitier platforms like Facebook, Fiever, Upwork or Fancy Hands or SaaS giants like Amazon, Salesforce and Evernote.
In most cases, we’re talking about Progressive Web Applications that act as SaaS for their end-users. These candidates are more likely to benefit in matters of time-saving when choosing hybrid over native development.
Another story is maintenance time. If your product ticks all those requirements for building a hybrid app (i.e. does not need direct access to hardware, acts as a SaaS with a pre-defined scope and is required to be cross-platform) – then you’re expected to reduce maintenance efforts by a factor of 3 to 10 times as compared to a native build. Hybrid applications (especially those proven successful to their audience) are a clear winner in matters of time-saving.
So – by the end of the day, when should I choose native over hybrid and vice versa?
Generally, by now you should have enough to make a decision, however, by rule of thumb:
Choose native development whenever:
- Access to the device’s hardware and OS features is paramount;
- Privacy and access to biometrics is a must;
- Bugs are a strict no-no;
- Internet access is not a business case bottleneck;
- Your User Experience relies on the platform’s UI guidelines.
Choose hybrid development when:
- Building an uncertain MVP;
- Budgeting is limited;
- Running a live service;
- The business logic requires an accelerated development cycle;
- Full hardware or OS-related feature access is a “nice-to-have”.
Is it worth building a hybrid app in 2019? Well, yes, it is worth it and No – it is not.
Before deeming native as better over hybrid, one must consider the business logic first. The most important thing here is to choose best-fitting approaches for your service model. To do so, you must be aware of what you’re going to build, when you need it running, and how much you’d be willing to spend to place it in production?
The product’s road-map is also an important piece of the puzzle – if you know where you want to be in the next 3 years: the choice is quite easy. Go hybrid if your service doesn’t rely on hardware access or real-time processing – go native if it does. That is really it. You can only state one is better than the other when you have a clear vision, timeline and implementation plan. Otherwise – go safe with native builds – at least until you have more certainty regards your business logic.
Anyway, this is our perspective and we’ll be happy to hear your take on it. That’s why we have a comment section below. Feel free to share your own view on choosing hybrid over native apps or vice-versa and we’ll do our best to address your thoughts in a timely manner.