Take Your JavaScript Skills Mobile with React Native
Tags: javascript, react, webdev, programming
Published: 2021-08-13 19:27:50

---
title: Take Your JavaScript Skills Mobile with React Native
published: true
date: 2021-08-05 19:46:44 UTC
tags: javascript, react, webdev, programming
canonical_url: https://www.split.io/blog/react-native-tutorial/
---

You’ve invested a lot of time and energy into learning JavaScript. React gives you a well-organized framework for writing great Single Page Apps (SPAs). But, what about mobile? You could go learn Objective C or Swift for the iOS platform. And, you could go learn Java or Kotlin for the Android platform. But, what if you could use the skills you already have and write code once and run it on both iOS and Android? Seem far-fetched? That’s exactly what React Native gets you.

There’s an additional challenge, though: updating code in the Apple App Store or the Google Play Store can take weeks. Imagine you built and deployed a new feature in React Native to the app stores and you discover a significant problem after the fact. Waiting two weeks (or more) for an update can quickly sour your user base on your app. That’s where feature flags come in.

Feature flags are a way to control who has access to a feature and when. You could enable a feature only for an internal set of testers and then maybe expand to an external beta tester group and eventually enable the feature for everyone. If something goes wrong with the feature, you can hit the “big red button” – a kill switch that instantaneously disables the feature for everyone. All of this is like a remote control for your app. The feature is in production and in the app stores. We call this “testing in production”.

In this post, I show you how you can test in production using Split’s shiny new [React Native SDK](https://help.split.io/hc/en-us/articles/4406066357901-React-Native-SDK). Split is a platform to configure and manage feature flags and to monitor performance as well as alert for any anomalous behavior. First things first: create a free Split developer account.

## Getting Started with Feature Flags

Sign up for a [free Split account](https://split.io/signup/), if you do not already have one.

Once you’ve logged in to your Split account, click **DE** in the upper left. Split has a notion of workspaces and you can have more than one. When you first create an account, a default workspace is provisioned for you and that’s what the **DE** stands for. Toward the bottom of the workspace popup, click **Admin Settings** (underneath your organization name). Click **API keys**. Notice that a number of API key types have already been allocated for you. When you create an account, A set of server-side and client-side keys are allocated in each of staging and production environments. You can have any number of environments and any number of API keys within those environments, but these are sensible defaults that cover most use cases.

A client-side API key has less privileges than a server-side API key and is suitable for any “public” type of application. This is the browser, mobile and desktop type of apps, which is what we’re focused on in this post. They’re called “public” because you don’t have any control over the environment they are run in. It’s easy for hackers to search a binary app payload for significant strings, like API keys. Thus, it’s safer to use a less privileged key in these environments.

Copy the Client-side Prod-default API key and save it somewhere for later use when we dig into the code.

The next order of business is to create some feature flags that we exercise later on in the code.

On the left nav, click **Splits**. Splits are synonymous with feature flags. Click “Create split”. Give it the name: **profile\_feature** , set **user** for the **Traffic Type** and click **Create**. Congrats! You’ve created your first split. Without targeting rules, it’s not terribly useful however. Targeting rules determine how (or if) the feature will be available to the individual user. The individual targeting rules are called treatments. Click **Add Rules**. This immediately brings up a page with a lot of options. This is because you can have any number of treatments for a feature flag and lots of different rules for how those treatments are used. For now, we’re going to accept the sensible defaults. That is, there are two predefined treatments: `on` and `off` and the default rule is `off`. Click **Save changes**. Whenever you make a change in Split, you’re presented with a confirmation screen. This shows you all the elements that have changed in a diff style of additions and subtractions. Scroll down and click **Confirm**.

Create one more split (with the default treatments) using the above steps. But, call this split: **about\_feature**.

The scenario we going to examine in code shortly is that you’ve added some new features to your app to show a user’s profile and to give information about the app. You’ve deployed these new features to the app store already, but you want to control who can see the new feature for a controlled rollout. Initially, most of your new users would NOT see these new features. But, when you’ve completed your testing in production, you will “flip the switch” in Split and everyone will have the new features available without you having to make a new release (and wait weeks for it to show up in the app stores).

## React Native with Feature Flags in Action

The code for this post can be found on Split’s official React Native example GitHub repo [here](https://github.com/splitio/react-native-sdk-example).

Clone the repo and open the project in the editor of your choice. I use [Visual Studio Code](https://code.visualstudio.com/).

### Prerequisites for Running the Example Code

In order to get started you need one or both of the development environments for mobile applications. While you won’t need to deal directly with these tools, React Native does use their tooling to build and run your code.

For iOS, you need to have a Mac and [Xcode developer tools](https://itunes.apple.com/us/app/xcode/id497799835?mt=12).

For Android, you need to have [Android Studio](https://developer.android.com/studio). NOTE: You need to have at least one emulator installed to test the code with Android.

You also need [Node.js](https://nodejs.org/en/) installed. As of this writing, I am using Node.js v14.16.1. The [nvm](https://github.com/nvm-sh/nvm#installing-and-updating) tool is super handy for managing Node.js versions as well.

The example app was created using the [expo-cli](https://docs.expo.dev/workflow/expo-cli/) tool. This tool makes it easy to work with your app locally and to prepare your React Native apps for publication in the app stores. In this post, we’re going to build the app from scratch, so you need this tool.

The following sections outlines building the app from scratch, but you can use the [GitHub repo](https://github.com/splitio/react-native-sdk-example)) as well if you want to just follow along. Let’s start building!

### Bootstrap React Native with Split

Here’s a little taste of how we work with the React native app locally:

![Screenshot of Metro Bundler running android and ios apps on the desktop](https://www.split.io/wp-content/uploads/2021/08/react-native-tutorial-01-devTools-1024x520.png?width=1024)

From the command line, I create a barebones project. From the project folder, I launch expo which in turn launches a handy web interface. From the browser, I can launch both the iOS simulator and the Android emulator with the application in its current state. Both will respond to application changes as we make them.

To begin, execute the following:

```
expo init react-native-sdk-example
```

Choose **blank** and hit enter. This will create an empty project and install initial dependencies for you.

Next, execute the following:

```
cd react-native-sdk-example
npm install @splitsoftware/splitio
expo start
```

This installs the Split SDK dependency to the app (unused for now) and launches the developer tools in the browser. From there, you can launch the iOS simulator and the Android emulator.

NOTE: You don’t have to launch both, but throughout this post I will use both to demonstrate the “write once, run anywhere” concept of React Native.

At this point, you should be in a similar state to the image shown above.

### Update the App to Integrate Split

From the previous commands, we’ve already installed the Split SDK dependencies. Now, we’ll add the code that uses it.

Let’s grab the React Native example from Split and copy over the code and assets. In a new terminal window, execute the following:

```
git clone https://github.com/splitio/react-native-sdk-example react-native-sdk-example-complete
cd react-native-sdk-example
cp ../react-native-sdk-example-complete/assets/* assets/
cp ../react-native-sdk-example-complete/App.js .
```

These commands clone the official Split React Native SDK example into a folder next to the one you generated earlier. Then, key elements of the code are copied over. All this can be done while expo is still running.

Open the `App.js` file in the editor of your choice and replace `<API-KEY>` with the api key you copied earlier in the post. Save the file. Back in your terminal window where expo is running, hit the `r` key to reload. Now, you should see that every 3 seconds, the app pulls in state information about a random feature flag from the list of feature flags in your account. If you’ve followed this post to this point, you should see information for the `profile_feature` and `about_feature` feature flags you created earlier.

<aside><p><span>Note:</span> <strong>When running your app in debug mode on an Android device or emulator, you might get a warning notification stating that “Setting a timer for a long period of time is a performance and correctness issue on Android”. Because of how JS timers are used by the SDK, it is completely safe to ignore or hide this warning.</strong></p></aside>

![screenshot of apps showing treatment is "off"](https://www.split.io/wp-content/uploads/2021/08/react-native-tutorial-02-treatmentOff-925x1024.png?width=925)

Notice that the treatment value is always `off`. That’s because we left that as the default treatment. Back in your browser where you’re logged into your Split account, let’s update the behavior of these feature flags.

Click **Splits** on the left hand nav. Click **about\_feature**. Scroll down and in the **Set the default rule** section, change the value from **off** to **on**. Click **Save changes**. Notice the diff and click **Confirm**.

The next time the app updates and the `about_feature` feature flag is chosen, you should see that the treatment is now on:

![screenshot of apps showing treatment is "on"](https://www.split.io/wp-content/uploads/2021/08/react-native-tutorial-03-TreatmentOn.png?width=430)

This is a good place to look at the code to really see what’s going on. Then, we’ll go over some more feature flag settings and their impact on the app.

Toward the top of `App.js`, you can see where we’re importing the `SplitFactory`:

```
import { SplitFactory } from '@splitsoftware/splitio';
```

This looks pretty straightforward. Behind the scenes this statement is taking advantage of Split’s modular design for SDKs. Only the objects that are necessary for your app are being brought into scope. This keeps your binaries more compact, which is especially of concern on Android.

Take a look at the `_initSdk` function (I’ve omitted part of it here for brevity):

```
_initSdk() {
  const factory = SplitFactory({
    core: {
      authorizationKey: '<API KEY>',
      key: 'react_native_example',
    },
    debug: false
  });

  this.client = factory.client();
  this.manager = factory.manager();

...
}
```

Here, we’re instantiating the `SplitFactory` with a configuration that includes your API key. Then, we use the factory to obtain access to the Split client and the Split manager. It’s the Split manager that allows us to get a list of defined feature flags. Take a look at the rest of the `_initSdk` function:

```
_initSdk() {
 ...
  this.client.on(this.client.Event.SDK_READY, () => {
    this.intervalId = setInterval(() => { // store id for cleanup on unmount.
      const splitNames = this.manager.names();
      const evaluatedSplit = splitNames[Math.floor(Math.random() * splitNames.length)];

      this.setState({
        treatment: this.client.getTreatment(evaluatedSplit),
        evaluatedSplit: evaluatedSplit,
        splitNames
      });
    }, 3000);
  });
}
```

There’s a lot going on here, so let’s break it down. First, the Split SDK has an event driven model. We don’t want to use the client or the manager until we’re sure that it’s ready. Therefore, we add a listener on the `SDK_READY` event. The handler for that event uses JavaScript’s `setInterval` function to execute another function every 3 seconds.

The meat of what gets executed is the following:

1. Get a list of feature flag names:  
`const splitNames = this.manager.names()`
2. Choose a name from the list at random:  
`const evaluatedSplit = splitNames[Math.floor(Math.random() * splitNames.length)];`
3. Obtain the state of the chosen treatment:  
`this.client.getTreatment(evaluatedSplit)`
4. Display the chosen treatment name, its state, and the list of feature flags in the app:  
`this.setState({ treatment: this.client.getTreatment(evaluatedSplit), evaluatedSplit: evaluatedSplit, splitNames });`

### More Advanced Feature Flag Settings

Let’s say you’ve discovered that your new `about_feature` is causing app crashes or an unacceptable amount of latency in the app. Before this becomes problematic, you can easily trigger the kill switch, which disables the feature for everyone.

In your Split console in your browser, click **Splits** on the left nav and click **about\_feature**. Click the red **Kill** button in the upper right. Type **KILL** in the form field and click **Kill** to confirm. Back in your Android Emulator and iOS Simulator, you should see that the `about_profile` feature shows up as off.

Let’s say that you want to test in production in a controlled way. You can ramp up who sees the new feature and monitor the results. Assuming all goes well, you can keep ramping up on a percentage basis until you arrive at 100% `on`, at which point all users would see the new feature.

In your Split console in your browser, click **Splits** on the left nav and click **profile\_feature**. Scroll down to the **Set the default rule** section and choose **percentage** from the **serve** dropdown. Set `on` to **90** (which will automatically set `off` to 10). Click **Save changes** and **Confirm**. Back in the iOS simulator and Android emulator, you should likely see that the `profile_feature` is now `on`. However, if it still shows `off`, it’s not an error. It just means that you landed in the 10% bucket that Split randomly created.

## What’s Next with React Native and Feature Flags

I hope this whirlwind tour of Split’s React Native SDK and feature flags, in general, has been useful to you. It’s exciting to be able to take the skills you already have and instantly become a mobile developer! And with feature flags, you don’t have to fear the slow update cycle of the app stores. Release and test in production the Split way!

There’s a lot more you can do with Split, including monitoring, alerting, and experimentation. Here are some resources that you may find useful:

- [Feature Monitoring in 15 Minutes](https://www.split.io/blog/feature-monitoring-tutorial/)(code tutorial)  
- [Respond quickly to degradations in metrics with alert policies](https://www.split.io/blog/respond-quickly-to-degradations-in-metrics-with-alert-policies/)(blog) 
- [Essential Guide to Experimentation](https://www.split.io/guides/essential-guide-to-experimentation/)

As always, you can reach us on [Twitter](https://twitter.com/SplitSoftware) and [Facebook](https://www.facebook.com/splitsoftware) and you can join the Split Community on [Slack](https://try.split.io/join-community)