If you pay attention to the world of mobile app development, you’re already familiar with the native vs hybrid arguments floating around. This article isn’t really going to add anything to this debate for you.
However, if you’re a business owner with an idea for your company that involves a mobile app, then hopefully this will give you a little more guidance as you’re looking for someone to build your app for you.
In the olden days…
For some 10 years now, building an app for a mobile device – whether iOS, Android, BlackBerry, or Windows – meant using that vendor’s preferred language and tools. This “native” approach ensures your app adheres to all the conventions and user expectations of that particular platform. The downside – assuming you want to support all the devices out there – means you have to start from scratch with each new platform type. Even the designs may require changes since iOS and Android have certain UI conventions that don’t make sense on the other platform. One of the most common examples being that iOS uses a back-button in the top-left of an app’s design, while Android has a dedicated back-button that makes a visual app button feel out-of-place.
Since starting over for each platform adds significantly to a project’s cost, various “hybrid” solutions have come out that promise to allow us developers to write the code once, and run it on all platforms. This has typically been done by writing the app code using HTML, CSS and JavaScript, and then running that code inside a shell app that can then be treated like any other native app (such as downloading from the device’s respective App Store). This works fine for some apps, but in general the result is that the app ends up looking rather generic, performs sluggish on most devices (due to the intermediate code translation that’s happening), and altogether yields a lackluster user experience.
The (not-so-new-anymore) new hotness!
The release of React Native a couple years ago, though, has brought an interesting and promising new approach to this type of hybrid development. Like most of the other hybrid frameworks before it, React Native code is primarily written using JavaScript, which has a rich ecosystem of its own to enable developers to builds things quickly. This means we can write a mobile app in one language for multiple devices, instead of a different language for each.
The exciting part of the React Native model, though, is the well-thought-out ability to “bridge” from the JavaScript to get to the native platform APIs, and vice versa. The code architecture makes it easy to write as much of the common code in one place. Then when an app needs to do something iOS- or Android-specific, there’s a clear way to do that. So we can now build a big chunk of the app (50% … 75% … 90% ??) once, and then drop down to native code to ensure a device-appropriate UI experience, or to accommodate truly device-specific features (such Apple Pay on iOS vs Google Wallet on Android). This is hybrid development in its truest sense!
Is it worth it yet?
Of course the reality hasn’t fully caught up to the promise – there are still quirks that prevent the full native experience users expect in 2017. Some of the built-in React Native components are device-specific, and often only available (or stable) on iOS. Developing can be more cumbersome due to the additional layers and tools required for this “magic” to happen. And it doesn’t support any other mobile platforms (for now at least). But with a monthly release schedule, changes and features are delivered fast and furious, and those issues should get remedied.
And that’s not to say that native development won’t still be important – the device vendors will continue to enhance their platforms. Some developers may want to leverage device-specific features immediately without waiting for a third-party (or distracting themselves) to develop the necessary bridge code to allow its use from the hybrid code. Other apps simply may not warrant cross-platform accessibility, especially games or rich experiential apps.
But React Native is definitely production-ready for many other types of apps, especially content-driven ones. Instagram’s dev team just published an article about how they’ve incorporated React Native into their existing native apps, with the right proof points: more shared code, and faster time to market. So we feel good that within a couple years, many more app types will benefit from this approach as well, and the hybrid vs native arguments will cease to matter.
Have an idea for a mobile app that you’d like to discuss? Let us know in the form below!
Also published on Medium.