With the number of smartphone users on the upswing, building for mobile is as important as ever before. Hence, in 2018 we expect people to get their hands dirty with React Native and similar tools even more.
Although they share the same core and are most of the time similar, React Native and React can differ quite a lot in certain aspects. It comes as no surprise because the differences originate in the platforms that the apps are running on top of.
In this article, I will outline some of the things of React Native that may be surprising, particularly to the people that are coming from the desktop and web development world.
It's not just
<div /> vs
What I hear quite often is ‘React Native is pretty much the same except that
<div /> is
<View /> and
<button /> is
<TouchableOpacity />. In my experience, the differences go a bit deeper than that. It might be very helpful to understand where the peculiarities may come in so that you begin your journey with React Native well prepared.
1. Navigation is a b*tch
On the web, you make pages and then you program states into the components that you will be using on said pages. What I found interesting is that on mobile devices you need to manage navigation much more carefully. Mobile users are accustomed to animated transitions, back buttons and other things that may not necessarily be a part of your typical web app.
What’s even more confusing, sometimes you will be making routing decisions based on navigation history.
Incidentally, I haven’t come across a perfect navigation solution yet. Some approaches work a bit better than the others though. For example, react-navigation will give you a drawer that is very straightforward.
Pick a couple of routers to choose from. Make sure that they have enough stars on GitHub. This ensures that there’s a community supporting the library and you won’t get stuck with a half-dead major dependency.
2. You need to worry about the bridge
React Native allows you to write your apps in ES6 and not have to deal with learning additional languages and mobile frameworks. It’s developers cover a lot of use case. With the help of the community, they have created a tool that let us build highly performant and all-around nice applications.
However, it is still quite important to understand how the data is transferred through the bridge to communicate with the native platform.
Wrong decisions will make your screens freeze, your animations slow and the whole experience horrible.
3. Publishing, deployment and API versioning
Unlike the web app where typically as soon as the user reloads the browser, they receive a fresh version of the code, mobile apps need to be updated.
Having our apps banned from both the Play Store and the App Store more than once, we are very cautious about using CodePush and HockeyApp to do hot reload on the client. Even if your changes were in accordance with the rules, it is hard to reason with the app gods.
Thus, if your app has at least some portion of back-end and a decent number of users, you will need to have an API strategy. In our estimations, 10-20% of users depending on the domain of the application are slow to update the app. This means you may face a choice of either abandoning them or supporting multiple versions of the API.
GraphQL helps mitigate that, but even then there are data schema changes that will require a fair bit of attention.
It seems that right now there is no silver bullet and the decision depends on the specifics of the app. That is why it is important to keep this in mind and talk the strategy through with your team.
4. Be prepared to learn to use Xcode
I mean it. It is just a matter of time before you need it.
5. The way you manage state is even more important on mobile
The amount of small interactions users expect to have with your app is unprecedented. All the little bells and whistles will often need to be managed by the state.
What makes it intense is that you will sometimes have components that need to be displayed on more than one screen. If you are not careful, you might find yourself passing props to children through a chain of components which is going to make your codebase a nightmare to understand.
Choose a state management approach that you like. Whether it’s Redux, Mobx or something else, the point is that your app is going to need it very fast.
Even for a seasoned developer, React Native will present some tough challenges. Package manager, XCode, navigation, and deployment are those that are on the surface.
The good news is that you will get more experience and get used to it very quickly if you come prepared. We love React Native and will keep using it on our projects as well as recommending them for use by our clients.
Get on board while it's still red hot!