When i am introducing React Native to fellow front end and native developers i always point out that React Native would be easier for a native developer to grasp. This is because the framework introducing features already built by native platforms. Performance problems, building native components and limitations of the platform or building an animation are more platform specific and native developers are already familiar with them.

Think it otherwise if there was a language for someone to write swift and an API to translate this code to react+html code wouldn’t you be the one that would know all the limitations of the browser and the problems around it?

It is easier to always have in mind that we are building native apps with the help of React Native and that we don’t write React Native (as Ram N well explained in a podcast here).

So let me break it down a bit on what you must have in mind while jumping ships and how a react dev can change the way of thinking to a more native way!

Deployment

Obviously right? eeehh ... not so much. Deployment of an application although someone might think it’s obviously different many doesn’t know it or how different that might be. We used of the idea of basically uploading our app on a server with a domain pointed to it and building our app and .. that’s it! On mobile development you must specify build versions for each deployment going live. For iOS you have to create signatures (automated ATM). On the Android you need to build some secure keys in order to be able to upload your first version. Lastly for android you could build and deploy your app in a console but for iOS you would need some basic knowledge of Xcode in order to make a first release (TestFlight etc).

So let’s see an example with the difference between web and native procedure.

Web Deployment

For deploying a web app you will need to upload all your assets index.html, css files and images on a server that is accessible from a domain e.g myAwesomeWeb.com. Similarly on a create-react-app you run the react-app build command to produce those assets and the procedure is the same.

React Native Deployment

On the React Native side as we are using the native way of deploying apps. Remember the React Native is only the tool of writing native apps. All other procedures and logic runs on a native side. So let’s take iOS to see the difference. I am assuming that you are already own an iOS developer licence.

xCode Product options

Let’s say that our app is ready, you need to define the version and the build number of your app e.g Build: 2 and Version 1.0.9. Then to open the xCode (if you haven’t done that already) and select Product -> Archive. This is the equivalent of or build command on react for native.

After this is finished you will be ready for uploading this version to Apple as we do for web to upload on the server by clicking on the two options showed. Selecting Distribute App is the way to do it.

Archive Window with options

I like to point out here that after upload is complete Apple will run some automated tests on your app for basic info provided for the App store and let you know if there are issues. After this is ok you could test your application with other devs through a program Apple provides called TestFlight. This is the only way to send an application somewhere for testing without plugin a device on your machine.

It is very important here to note that each deployment would need to pass some validation from Apple that would take some days in order for our release to be available to the end user when the testing phase is over.

Going back a screen and memory state of your app

On web this is not even an issue. Going back?? It’s easy. I press the back button and the app reloads etc. This is how it goes right? Yeeeaah .. well … going back varies here. On iOS going back each screen is being handled by a button or a swiping on the screen remember? You might think that hiding a back button would prevent the user from going back but think again. You must wrap you head around it in order to prevent or allow going back.

On android there are two ways, the button on the app and the button on the phone. The magic here is that the android back button works differently on some devices and it is either handles the state of the phone differently or even kills the app from the process manager! 😎

Difference with navigation

In the browser world you have the url. Each time something is changing your react router comes in the way to handle this change and “translate” it to a new page. In the native world this is not the case. Navigation works like you are having different decks of cards where cards are screens. Let’s again compare.

Web

Sample of react router in action

On the web what react (with the help of react-router) does is that when you update the address with a new url the react router “listens” to that change and it cross reference the url with a route and a component.

React Native

As i said on react native the navigation is a different world and you must have this in mind. You define different decks of screens for each purpose. This is because a user could add or go back to a previous screen.

Let’s say you have these 4 screens

splash — with options to go either login or register

login screen

register screen

home screen — where the user will have his info shown

You want a user to navigate from splash to login/register and from login/register back to splash if wants to. You also don’t want someone to go back from home screen to login with pressing a back button e.g on android. You need to define two stacks/decks one to hold splash, login and register and one just for home screen.

createStackNavigator({ Home: { screen: HomeScreen } });

createStackNavigator({ Login: { screen: LoginScreen }, Register: { screen: RegisterScreen }, Splash: { screen: SplashScreen } });

This way you can be sure that a user can’t go back to the other deck.

It is important to note that on native you start from the first screen defined in the deck and when you add a screen it goes to the top of your deck. When you go back this goes off the top of the deck as well. This means that the first screen is loaded in the background till you dismiss the stack or go back .

So the cards are living underneath although you see the top of you deck. Mounting happens as in regular react when you add your screens and the child components but unmount of a new screen only happens when you change the whole deck. You can have different decks/stacks for groups of screens. I am not going to elaborate more as i am focusing on the differences between web and native at this point. More info on react-navigation the react native navigation library.

Modules vs DOM elements (linking and why it’s happening)

In the web you are thinking DOM elements. DIV, A, SPAN and others are elements that doesn’t exist on React Native as is Native. That’s why RN api exists. When you call for a React Native component, that component is rendering underneath a native module. This module can be a native alert or a native card or just a View.

Web

On the web you don’t have to require the DIV as is already part of the DOM. So when you write something you do

<div> <span>Hey World</span> </div>

React Native

For React Native everything defined must go through the RN API. That’s why you must “require” everything you use. So an equivalent of the previous would be

import { Text, View } from 'react-native';



<View> <Text>Hey Native World</Text> </View>

You are calling these components and React Native calls the native module to do this job for you. Here comes the “linking”. As of React Native 0.60 you don’t have to worry about it as is automated procedure but is good to know what it is. Linking is where we define on the native part where it can find a module and import it so we can use it on react-native. If we don’t the system would not be able to find it and is going to break when we are going to use it. Like the example with react-native above react-native modules are already linked for us when we first started the project using create-react-native-app. Same procedure applies to all other components

Native features (push notifications, camera etc)

Think how many cool features mobile has to offer. Push notifications, camera or geolocation are some great examples. On the web though many of those are not used so often as the apps are designed often for desktop users. When building an application you must think of when do you want to ask user permission for these or how to handle those permissions for future use of your app eg when you are asking for user permission for the camera in order to update their profile picture you need have this check every time since the user might have pressed to not give permissions.

These permissions must be defined in the app first on the native side so the user and the app would know where they give permissions to.

Android example of permissions

As you can see you need to define that the app needs permission to access the internet! Cool stuff eh ?

Think animations like native and forget CSS animations

Animations on native are built through a mechanism in order to identify interpolation etc. So CSS it’s very difficult be translated to such code. Many times running RN App it is clear that it was built having iOS in mind. Animation API is one of these cases. Naming is almost identical. Recently i was building Spotify player animation which you can drag to open. In order to make this work i used no other library, only RN animation API. I struggled a bit to make it work as there is a lot of gesture handling going on but the solution came to me by a colleague iOS developer! Yes, he was also able to identify many problems on the code regarding the animation!

Bonus: Remember talking about Navigation and pile of screens? An animation looping on the bottom stack of these screens will cause issue to any screen on your pile as it will run in the background till you change stack 🙌

Simulation vs Real Device vs Browser

We front end developers are familiar with browsers, the limitations on each of them or some problems when there is a combination like browser+platform. It easy to test things around you open a browser window and start test things.

When it comes to native development you must always think about the platform(iOS, android) … Platforms are very different on how they are managing things. They are even more different when it comes to simulation. Simulators although some one might think i am good when testing or building an app, in many cases they are wrong. Simulation can never replicate 100% the hardware of a real device. You can find an app working without any error on simulator and having trouble in an actual device. Android here is trickier and the differentiations are much more because the devices are more. Also services for push notifications only working on real devices. So you must forget about simple browser builds!

Compile and Compile time!

A very quick point. When building a web application you forgot about code compilation or compiler. Well… When you are writing native code the code gets compiled in every change. With the help of React Native the code don’t need to be compiled every time unless you link/add a new native module. 🤔 So you need to compile the app again and that takes some time based on your app size. Compile time = time to make coffee! ☕

Application state (push the app on foreground or background)

There would be two more things to worry about, user having your app in the background or use having the app in the foreground. This is very important and is usually forgotten but think about a user putting your app in background and you want when it comes back to show something or updating your redux state with something. User’s back and forth on you application is very common and you must always think around it. One more thing that you don’t have to worry on the web.

Your app is going to be as strong as native is.

Overall

An application built with react native will have limitations but all APIs do (Gradient, Massive animations etc). React Native framework doesn’t aim to isolate you from the native code but to give you the flexibility of starting something from scratch and maintain it very easy without knowing the system that you are writing for and publish it on multiple platforms. But as you essentially write native code with React Native it is super beneficiary that you know or understand swift or java in order to understand the under the hood mechanics in order to solve a problem.

Do you have something else helpful in mind? Do you think you found these useful? Let me know you thoughts!