Differences between React and React Native that newcomers should know about
There are some things to have in mind when coming from web to mobile, here are some thoughts and tips.
It’s very frequent to see that people starting on React Native are coming from a web background, generally React web one, but not only.
🚀 The promise of React ecosystem is: “learn once, write everywhere”.
While this is mostly true, newcomers may not see the differences between the web and the mobile programming development flow. At least until some critical moment of the project, this could be devastating and hard to recover from…
I would like to share some tips here in order to help migrating to mobile stack in a easier way, this list is non-exhaustive and may be updated during this article life.
Those tips are mostly taken from my experience of JS Tech Lead Kaliop.
I hope what’s following can help you preventing some mistakes and that you’ll enjoy it. Good read!
🎫 The application entries points might be multiple in React Web apps whereas there is a single entry point on React Native
➡️ Using react web
First thing to notice is that while using React in the web, your app can boot from multiple entry points, at least when using some kind of Framework such as NextJS.
Those entry points depends on the requested URL, which trigger some specific components rendering.
It means that you should rather think your bootstrapping code as a blocking Higher Order Component (HOC) instead of the method we will see below presented by react-navigation.
This way, no matter from where the app boot, an App loading component will take precedence and do mandatory things before give control back to the user.
I already described that approach in another article, you might have a look:
How to handle and design the startup of a React application
When building an application once the user arrives on the splash screen, you might want to do some things before…
➡️ Using react native (RN)
At the opposite, React native as a single entry point (react native web is not part of this assertion) which is generally
This allows different patterns such as the one described here with redirections through screens.
While this looks like a great approach, I highly recommend however to consider that the endpoint can be multiple and avoid the redirection strategy from react-navigation’s doc for compatibility reasons with eventual react-native-web future releases.
You might also handle Deeplink through this bootstrapping HOC. Deeplinking is a way to trigger an app opening action with specific intent and params.
📵 Offline experience and cache strategies should be first class citizen in mobile apps whereas they are less in web.
As network connectivity is not a constant, you might live in some places in the world where the network is flaky.
That being said, the app will be able to boot without network connection and it can end in a state of being loaded but not being able to fetch data required for content display.
The user might think that he will have access to some contents, whereas he hasn’t and in the best situation he will see stale content.
That’s why you should really consider offline as the heart of your application and structure around this.
Nowadays, even if the network is getting better and better, there is no point making an app without taking this in consideration.
⚡️The network has to be considered as an improvement of your app.
This might be a bit tricky at first glance, especially when coming from a web background, but there are a lot of tools that make this task easier such as Cloud Firestore with Firebase or Apollo-client with GraphQL.
I also made an article about all of this, you may be interested in having a look at it.
General considerations for offline resilient React based apps
You should always design your applications as offline first and think of the network as an augmentation and…
💡Note: What we just discussed can also apply to progressive web apps, which are kind of mobile applications sibling using the web browser capabilities and APIs.
Web libraries that are not isomorphic cannot work on React native
You should really take care of the libraries you are going to use, some of them are badly built and might make your app crashing upon importing them as they try to access the
window global object, which is unavailable on NodeJS and React Native.
You can’t also use most of NodeJS API based libraries, such as the one reading and writing on the filesystem:
Also take note that React Portals are not available in the React Native API, instead you can have a look at this:
Render React DOM into a new context (aka "Portal") This can be used to implement various UI components such as modals…
React native depends on all mobile problematic, while react web is just web…
When building a mobile app you’ll will need to keep in mind a lot of problematic and rules:
- The Apple Appstore and Google Play will make a review of your app. This might delay your delivery from some hours to some days.
- You can have multiple versions of your app living at the same time as user might not want to update or forgot about that.
- The inertia of hotfix patching is drastically augmented, especially due to first rule but also because of the build and delivery process in general.
- Mobile packages requires an more complex CI / CD integration and also code signing to be delivered.
- Push notifications are the heart of engagement tools and the best retention strategy. As they are not much popular in 2019 in the web, they are mandatory on mobile apps.
- Crash reporting are mandatory, otherwise you’re totally blind.
With that in mind you should adapt accordingly.
💁🏻♂️Here are some ideas to adapt your workflow to those concepts.
- You could set up a progressive app features rollout, to ensure that everything works well before releasing new update to everybody. Start by activating update to 1% of the user base then scale it up gradually.
- You’ll also need to test your app on multiples devices and develop with the assertion that the emulator or the cellphone you use is a top tier cellphone. Your user won’t have such performances in production for sure, always test for low tier devices or you may have bad surprises.
- Start safe programming 🔐, which means that you can’t trust the data that is coming from the network. The API might change and you’ll need to ensure every results you get is truly defined before accessing it. You can reduce this by versioning your backend API and ensure you’re not removing existing field and only adding new ones.
- Crash reporting are not optional as you need to know why you’re app isn’t performing well, this can work on UAT environment but not in some edge cases in production you could have missed. Think of tools such as Crashlytics, Sentry or Bugsnag.
- Think of cloud solution for your CI such as Github Action or Bitrise which provide both MacOS computer for your builds.