Building mobile apps in React Native

Ionic and React Native

If you’re looking to develop mobile apps with anything other than the native toolsets, you’ll most likely find yourself evaluating Ionic and React Native as two of the most common alternatives. Both have a large community of passionate developers, are used heavily in large enterprises, and can lay claim to many popular consumer apps.

But today, I’d like to focus on how Ionic and React Native are different, and what these differences mean for those who are evaluating cross-platform development approaches.

Most people assume that all cross-platform frameworks work similarly and that the decision is as simple as choosing the stack with which you’re most comfortable. If you’re a React shop, choose React Native; if you’re an Angular shop, choose Ionic (setting aside that, now, Ionic 4 works with any JS framework, including React).

The truth of the matter is this decision isn’t nearly as simple as one would expect.

You’ll see, as we compare ourselves, we have two very different philosophies in how we approach development. And, no matter which path you choose, it’s important to understand that when you do make a choice, you’ll be buying into one of these philosophies and the profound implications they carry with them—whether you know it or not. Hopefully, by the end of this post, you’ll have a clearer idea of how each of these technologies work and which direction makes the most sense for you.

Let’s break it down a bit, shall we?

Where We Are The Same

Ionic’s goal has always been to give web developers the ability to develop for, and participate on, platforms that haven’t always been accessible to them. For example, do you want to build a native app that can be downloaded from the app stores using web technology? Ionic has your back.

This concept of allowing developers to use technology that they already know, to build apps in the technologies they don’t know, is what all cross-platform frameworks are trying to achieve.

• Ionic allows you to use HTML/CSS/JS to build iOS apps, Android apps, PWAs, desktop apps, or apps for any other platform where the web runs.
• React Native utilizes the JS framework React, but renders native UI elements at runtime, allowing you to build iOS and Android apps.

In that way, we all have the same mission: Use technology X to build for platform Y, where X and Y traditionally aren’t the same.

It’s also important to note that all hybrid app development frameworks, including Ionic, allow access to native device functionality like the camera, biometrics, geolocation, and offline storage.

But, that’s where the similarities end.

Hybrid-Native vs. Hybrid-Web

In order to accomplish the goal of building for a specific platform, each of these technologies has different philosophies to which they adhere. In my opinion, we can divide these beliefs into two major categories: Hybrid-Native and Hybrid-Web.

Hybrid-Native

NATIVE UI, SHARED CODE

React Native, along with Xamarin and NativeScript, allows you to program your user interfaces (UI) in one language that then orchestrates native UI controls at runtime.

It is “cross-platform” in that the React Native framework has mapped calls in JavaScript to calls that manage the native UI for specific mobile platforms. For example, a React Native component that renders text on a mobile app will be translated into two separate components: [TextView] for Android and [UIView] for iOS. Thus, you are not sharing components across platforms, you are sharing code.

This is why proponents of this approach will tout that you’re building a real native app. Your JavaScript code runs and orchestrates native UI controls under the hood, so that your app UI is running (almost but not completely) natively.

This means that the underlying native UI component that you would like to use, as well as any customizations of that component, must be supported by React Native in order to use that component or change it.

For instance, let’s say you wanted to change the border around a button. If React Native doesn’t open up a customization for that border, you’d be unable to modify it without going directly into the native implementation to manually program it. That doesn’t mean you can’t change the border, it just means it will be harder to do so than expected in some situations.

It also means that, if you dream of a single, shared library of reusable UI components that you can use across all of your digital experiences, the Hybrid-Native model (i.e. React Native, Xamarin, NativeScript, et al) would not be the right approach.

SHARED CODEBASE, PLUS NATIVE CODE

The amount of code reuse in your React Native project will depend on how much you want to customize your app at the native layer. If you stick with fundamental UI primitives like View, Text, Image, and Touchable then your code will run on each platform, meaning you'll get close to 100% code reuse.

On the other hand, if you have a lot of native customizations, your project will involve three separate codebases: Two to manage your UI for Android and iOS, plus a shared codebase where your controller code will live. In a recent post from the mobile team at Airbnb, they explained how this played out in their project:

“Even though code in React Native features was almost entirely shared across platforms, only a small percentage of our app was React Native… As a result, we wound up supporting code on three platforms instead of two.”

In the end, React Native and the other Hybrid-Native frameworks are great solutions with a number of benefits. Namely, the ability to build a real native UI using mostly JavaScript, while enjoying a high degree of code sharing. In particular, we recommend choosing this approach if you want to mix a cross-platform solution into an existing native codebase, have existing native skills, prefer native-specific languages over JS, or only plan to target iOS and Android.

Hybrid-Web

Web UI, Shared Components

Ionic takes a different stance. Instead of your JavaScript code acting as a bridge that controls native UI elements, the UI components you use in your app are actually running across all platforms. In a mobile app, these components execute in a webview container. In a Progressive Web App, they run in the browser. And, in a native desktop app, they would run in a desktop container like Electron.

Why does this matter? Here are a few reasons...

DESIGN CONSISTENCY

First, if you’re building a design system and want to enforce UX and brand consistency across apps and digital experiences (e.g. this is the exact button that should be used in all of the apps we build)—there’s only one way to do it: By sharing components across all digital platforms, like mobile, desktop, native, and the web. Additionally,  if you want to make sure a component you build for one app can be reused across any project, using web components is, currently, the only way to go.

PORTABILITY

Since Ionic is based on HTML, CSS, and JavaScript, your UI runs on a portable, standardized layer. Looking for a fully customizable component that automatically works no matter which platform your app is running on? Ionic makes this possible by utilizing open web standards. You’ll even be able to run your Ionic app on new platforms like Progressive Web Apps (PWAs) with no changes.

CUSTOMIZABILITY

One of the things Ionic developers often brag about is being able to fully customize every bit of their UI. For example, you have complete and total control over the UI by utilizing the web, which offers a ton of out-of-the-box styling properties. Start with a simple `<div>` tag and turn it into whatever you'd like!

And if you’d like to customize your app's design based on each platform, it’s easier to do so when working in a single codebase with easy-to-use CSS styling on a per-platform basis, which Ionic’s technology provides.

STABILITY

Lastly, perhaps the biggest benefit of building on the web is the stability of the platform. With open web standards supported in all modern browsers, you can be confident that whatever you write today is going to work tomorrow. Other front-end tools are growing and changing all the time, without as much care towards backwards compatibility.

One Codebase, Running Anywhere

With a Hybrid-Web approach, your UI is built with HTML/CSS/JS, with native functionality being accessed through portable APIs (or “plugins”) that abstract the underlying platform dependencies.

Instead of your entire UI depending on the native platform, only certain native device features, like the Camera, are platform-dependent.

This allows your app to run anywhere the web runs: iOS, Android, Browsers, Desktop/Electron, PWAs—the list goes on.

This also means that your UI layer can be shared between all platforms. This is a really important point: Even if you customize the look & feel beyond Ionic’s default platform-specific designs, you’ll never need to split your app into multiple codebases.

On top of that, you also get the benefit of debugging multiple platforms at the same time by utilizing web-based debugging tools, like the Chrome Developer tools, saving you time in the long run. This is actually a huge benefit. We often hear that being able to build the bulk of your app right in the browser is one of the most tangible benefits of building with Ionic.

To sum it up, here are the scenarios where I would recommend the Ionic (“Hybrid-Web”) approach to cross-platform development:

• You’re looking to build an application not just for mobile (iOS and Android), but for desktops and browsers as well.
• You don’t want to have to rewrite your UI for each target platform.
• UI customization and design consistency across all of your target platforms are critical.
• You want to open up the possibilities of your UI to custom components or third-party libraries.
• You want to hire from the huge pool of existing web development talent and build out a JavaScript organization.

What About Performance?

Now let’s talk about the elephant in the room when it comes to evaluating the Hybrid-Web approach. Proponents of Hybrid-Native will often say: “But what about performance?!”

The truth is, for the vast majority of use cases, hybrid frameworks (both Hybrid-Native and Hybrid-Web) will have similar performance. But the proof is in the pudding. If you want to see how an Ionic app performs, I invite you to check out one of our sample appsand take it for a spin. And remember, “bad code”, even in a native app, can make your app sluggish. So always make sure you’re utilizing best practices when building.

Lastly, if performance is your one and only concern, you might as well go fully native and build directly with iOS and Android toolsets. For performance sensitive applications, staying as close to the metal with Native SDKs will likely be worth the tradeoffs in terms of cost and development time.

So What Does This Mean?

If you’re evaluating Ionic against React Native, or any of the other Hybrid-Native framework, be sure to give careful consideration to the commitment you’re making and the approach it takes.

While both are solid frameworks and will help you build a great app, the choice for your team or organization depends on your overall vision and the ideal functionality for your app(s).  Additionally, you must also be sure to evaluate your options based on which factors are important to you, such as design consistency, customization, platform independence, portability, and more.

When you think about the top priorities for choosing a technology to tackle your app development activities, you’ll likely find that one clear winner emerges above the rest for your next project. Remember, the choice has much less to do with which tech stack you’re used to and more to do with how the values of your app align with the approach to build it.

Interested in building a truly cross-platform app? Give Ionic a try, today.