This is an excerpt from my book, the React Native Cookbook, 2nd Edition, from Packt Publishing, due to be published this winter.

React Native has become a very popular way to build cross-platform native apps using primarily, if not solely, JavaScript code. There have been a number of good articles that describe the pros and cons of developing in React Native, such as React Native: Is it Worth It?, React Native: Pros and Cons,Why You Should Consider React Native, and React native limitations that every developer should know about.

If you’ve decided that React Native is right for your project, this article is for you! We will be cover your options for bootstrapping your app, and the pros and cons for each option.

There are two methods for initializing and developing your app: Expo, and the React Native CLI. Until recently there was a distinct third method, using Create React Native App (CRNA). CRNA has since been merged with the Expo project, and only continues to exist as a separate entity to provide backwards compatibility.

Expo falls into the first category of tools, providing a more robust and developer friendly development workflow at the cost of some flexibility. Apps bootstrapped with Expo also have access to a slew of useful features provided by the Expo SDK, like BarcodeScanner, MapView, ImagePicker, and so many more.

Initializing an app with the React Native CLI, via the react-native init command provides flexibility at the cost of ease of development. A React Native app created with the react-native init command is said to be a pure React Native app, since none of the native code is hidden away from the developer.

As a rule of thumb, if the documentation for a third party package states that you need to run the command react-native link as part of the setup process, then this package can only be used with a pure React Native app.

So what do you do when you are half way through building an app with Expo, only to find out that a package integral to your app’s requirements is not supported by an Expo development workflow? Luckily Expo has a method for turning an Expo project into a pure React Native app, just as if it had been created with the react-native init command. When a project is ejected, all of the Native code is unpacked into ios and android folders, and the App.js file is split into App.js and index.js , exposing the code that mounts the root React Native component.

But what if your Expo app depends on features provided by the Expo SDK? After all, much of the value of developing with Expo comes from the excellent features the SDK provides, including AuthSession, Permissions, WebBrowser, and so much more.

That’s where ExpoKit comes into play. When you choose to eject from a project, you’re given the option of including ExpoKit as part of the ejected project. Including ExpoKit will ensure that all of the Expo dependencies being used in your app will continue to work, and also give you the ability to continue using all the features of the Expo SDK, even after the app has been ejected.

Unfortunately some of the niceties of developing with Expo will be lost after the process. Expo eases the burden of building binaries for the iTunes Store and Google Play store, keeps you from having to use Xcode and Android Studio, removes headaches from React Native upgrades in a project, and can manage your push notification pipeline. If you choose to eject from Expo, these are features you’ll have to say goodbye to.

For a deeper understanding of the eject processes, you can read the Expo documentation on ejecting at https://docs.expo.io/versions/latest/expokit/eject.