• 1344 words

Get started with React Native

There are many ways of booting up a React Native application. Which one should you use?

A yellow hot air baloon
Photo by Jin Cheng / Unsplash

Did you miss me, right? Ok, in 2021 I promise you an article per month.

Yes, I’ve said it, and I’ll do it. I want to step up the game with a “simple” but important goal that I’m setting myself.
So no more long pauses, I’ve got plenty to tell :)
So what we’ll be talking about today?

The many ways of starting up a react native application

Being a rising technology, despite all the fuss in the past about companies that dropped it, the whole React Native community offers many ways of starting up an application.
PS: This article isn’t necessarily intended for skilled or non-skilled react native developers, but it’s not about how to start developing with react native, but more of a how-to-produce the first boilerplate you’ll work on.
So I’ll list them and then discuss a bit of the pros and cons about each one of them:

  • react-native init
  • create-react-native-app
  • ignite new
  • expo init*

* expo is an ecosystem that oversimplifies react native development process. It enables you to produce builds, set app icons and splash screens, use native APIs (and so on) in an extremely easy way. But it clearly comes with a cost. If you want to know more about my opinion on Expo, I’ve written some stuff here.

Starters with native code

react-native init

This is the most barebone starter, the one developed by the same devs who build React Native itself.
With this, you have full power and control over all the native code. I’m assuming here you know that every React Native application is made by two native projects: an iOS and an Android one (moreover, some starters that I’ve listed hide this native code to you and we’ll discuss this shortly).
As a starter, this is as low level as you can get, but there are of course other ways of using React Native in a more “hardcore” manner, which is including it directly into the code of your native Java/Kotlin/Swift, etc. apps*.
*A similar strategy is used in web apps that are transitioning towards React.js, for example, where you’re not yet ready to use a full-blown starter like create-react-app and therefore you start to use it only in the pages where you need it.

init results

The command npx react-native init <app-name> produces these folders:

react-native init results

You can also associate some options to the init command like the folder where to put the rn app files, the tile of the application, or the template to use (yes, you can use various available templates or one that you can create yourself following this official one that includes typescript in the project)


It’s the most versatile one. You start with a blank page (or almost blank, based on the template you may choose), and then it’s everything up to you.

  • you know your app will have particular needs such as Bluetooth communication
  • you want to be able to choose by yourself the services your app will use (one signal, Firebase Crashlytics, and so on)
  • you need to communicate with proprietary hardware or, more in general, you’ll have to write custom native code
  • you have a very strong feeling about the libraries you want to use to build your app (react-native-navigation, for example)
  • you don’t plan to use any of the expo modules

If any answer to each of these matters is yes, then this is the starter you want.
You can derive the pros from this list


In one word complexity. The handling of such a barebone structure is more complex than the ones that hide the native parts for obvious reasons. Depending on which are the things you’ll need to do, here is a list of the basic stuff you might find problematic to do if you’re new to this:

  • Setup your application icon
  • Produce builds of your application
  • Set the splash screen of your application
  • Set up push notifications

And the complexity grows as the functionalities requiring native knowledge increase

Starters with or without native code


This starter slightly increases the abstraction of the code it delivers by a bit, including expo and the expo-unimodules and providing pre-installed libs like react-native-web (which allows you to use react native code in the browser), react-native-reanimated, screens, and gesture-handler.
It’s a step towards the expo ecosystem, but it still gives you the native apps code*.

_Be aware that it also depends on the template you choose during the installation process. Some of them use expo, and therefore no native code is delivered.

init results

The command npx create-react-native-app <app-name> produces these folders:

create-react-native-app results


This starter (which is basically an expo init + expo eject as we are about to see) promises to give you a structure where you can use all (or almost) the useful native modules and functionalities that are included in the expo ecosystem without losing the possibility to add native code.


We’re basically working with a higher amount of complexity compared to the “react-native init” command due to the expo native libs being included.

In conclusion, if you need this starter or not is equal to answering the following question: do you need some expo stuff in addition to stuff that expo doesn’t give you?


This starter focuses greatly on the react side of things. It delivers various useful react libs and react-navigation, AsyncStorage, Flipper, and Reactotron as native libs and utilities that are compatible with both react-native or expo (meaning that you can have a project with or without native code).
It also features generators and a preconfigured storybook instance that will help you to develop your UI.

init results

The command npx ignite new <app-name> produces these folders (you can also use the —expo flag to avoid having the native code in your project):

ignite-new results


It gives you a little boost as long as you know the tech stack used in there.
I honestly never understood this kind of starters since it’s easy to create a simple bootstrap yourself with the tech stack you prefer… BUT, there is a but.

Ignite offers you the feature of generators. You can define templates that you can use to generate certain files. (if you know Angular, it’s something like schematics that you can customize very easily).

This is the basic component template (it uses ejs as a template system):

import * as React from "react"
import { TextStyle, View, ViewStyle } from "react-native"
import { observer } from "mobx-react-lite"
import { color, typography } from "../../theme"
import { Text } from "../"

const CONTAINER: ViewStyle = {
  justifyContent: "center",

const TEXT: TextStyle = {
  fontFamily: typography.primary,
  fontSize: 14,
  color: color.primary,

export interface <%= props.pascalCaseName %>Props {
   * An optional style override useful for padding & margin.
  style?: ViewStyle

 * Describe your component here
export const <%= props.pascalCaseName %> = observer(function <%= props.pascalCaseName %>(props: <%= props.pascalCaseName %>Props) {
  const { style } = props

  return (
    <View style={[CONTAINER, style]}>
      <Text style={TEXT}>Hello</Text>

and you can create such one with the following command:

ignite generate component MyAwesomeButton

this, by default, will generate a .stories file too! And you can actually decide everything very easily, pretty cool.


Well, pretty obvious: many, possibly, unknown stuff (to you) to handle but at least all of it isn’t part of the native code and, truth to be told, a great part of ignite “just” helps you in the process of development and gives you stuff that won’t even be part of the actual code that your users will have on their devices.

So as long as you like their tech stuff, I can’t see big cons here.

Starters strictly without native code


I’ve already dropped you some info about the expo ecosystem at the beginning of the article and there isn’t much else to say. All the cons and the “why” and “when” of it have already been discussed in this other article.
It’s easy to pick and start developing, and it’s the bigger pro.

init results

The command npx expo init <app-name> produces these folders (you also can use templates that kickstart the app with certain navigators or with typescript):

expo-init results

As you can see you don’t get any android or ios folders with these.


I’ve possibly showcased the most known ways of kickstarting a react native application.
Now do your magic and then come back and tell me if you made some great with it @giacomocerquone on Twitter.

See you at the next one 🙂