Hybrid vs. Native

Seriously, Are We Still Debating This?

For as long as mobile phones have been smart, developers have been locked in an eternal tug-of-war: Hybrid vs. Native. And just when we thought we’d figured it out, React Native has recently arrived, shaking up everyone’s carefully drawn battle lines.

Here’s a quick story from my own trenches:

Back when I was building an MVP for Speedoc – think Uber, but swap cars for house-call doctors – we were knee-deep in development hell with five separate apps: two for doctors, two for patients, and an admin app, because hey, why make it simple when complicated is available?

Then came the unsolicited advice. You know, the kind where “experts” from a big local software house confidently declared: “React Native won’t scale! If you want performance, you must go native!”

Ah yes, “must.” One of my favourite words.

Let’s put aside the fact that Facebook has already shipped entire apps – like Ads Manager and parts of Marketplace – using React Native. I’d like to think that if anyone knew a thing or two about scaling, it was probably the multi-billion-dollar social media giant whose job it is to scale.

But sure, let’s ignore all that.

The confusion wasn’t just about whether React Native could scale. It was more fundamental. People were mixing up terms.

Take Hybrid apps, for instance. “Just like native but easier!” Right? Well, not really. Hybrid apps (think Cordova, Ionic, or PhoneGap) are essentially web pages wearing a native disguise, awkwardly running inside WebViews. Native apps, meanwhile, were championed as the pure-bred thoroughbreds: Swift, Objective-C, Java – languages developers talk about in hushed, reverent tones.

React Native, on the other hand, was misunderstood. It was dismissed as “just another hybrid gimmick,” when in reality, React Native apps render actual native components. JavaScript? Sure, but don’t confuse the language for the result. React Native is native, just sneakily so.

At Speedoc, React Native wasn’t just an option, it was practically screaming to be picked. With a single codebase, we were delivering two patient apps, two doctor apps and even an admin interface without breaking a sweat. Well, maybe we broke a sweat (I most certainly did while working at Ahrefs!) but definitely fewer sweats than multiple native codebases would’ve caused.

The backend was Meteor.js, which comes with their own realtime protocol is a total lifesaver letting us replicate business logic across client and server. Throw in AWS Lambda (fancy, but a bit scary) and we had a scalable future-proof architecture on our hands.

What baffled me most wasn’t React Native. It was the stubbornness of industry folks who insisted that “real apps must be native.” Here’s the reality check: React Native delivered 90% of native performance at 10% of the headache and 10% of the cost.

It unified teams, slashed bugs and accelerated releases. Sure, it had flaws, but so did native. No stack is flawless. You just pick the stack whose flaws hurt the least. For us, React Native’s minor bruises were preferable to native’s broken bones.

The takeaway isn’t about winning a tech debate. It’s about recognizing bad advice when you hear it. And although it depends on a number of factors, it’s also about understanding your business requirements first, then choosing technology, not the other way around.

Hybrid apps will always be around. Native has its niche. But React Native? It’s busy carving out the future.