How to pitch React Native to Team Leads
This blog post is part of a series about pitching React Native to different people you may interact with. The other parts can be found here
- Development Team Leads
- Native (you most likely knew, that’s what this post is about)
- Smart TV
One thing most people don’t understand immediately is that React itself makes it easy for developers to reason about what the application does due to its declarative syntax; This is a big plus when you think about debugging. If you are more interested in the technical part, please check out the first part of this series: How to pitch React Native to Developers.
So when it comes to native development, there are some problems that need to be solved, and when it comes to React Native, there are some prejudices you may have heard of. I will first discuss the latter one, as selling something you think you can’t use is hard.
Prejudices against React Native
As this post is targeted to a management level I won’t cover the benefits compared to Cordova, etc. and other technical aspects in detail; If you are still interested, please read my former blog post.
What I would like to talk about is what may hold you back from using React Native from a management perspective, and this is either you already have iOS / Android applications or that you have no expert for React Native in your team. But you may be unaware that neither of them is to be considered a tough problem.
If you already have an application, it is quite simple to embed a React Native App in it. I won’t cover that in detail, but when you have a short look at the documentation (iOS & Android) you may easily see that it only takes a few steps to do so. You may think this doesn’t scale, but it is in fact what Facebook did with the Groups feature. They built a separate Groups app which only had that feature and had at a certain point of time two different implementations of the same feature. In the current version, they have included parts of the separate app in the Facebook App and thereby show that this integration works so well, that it may be used in production and large scale.
As we have removed the stepping stones let us dive deeper into what React Native in detail gives to you and what it empowers you to do.
Speed is the key
Whenever web development is compared to native development the two points always mentioned are the speed of deployment and development. The first one results from the ability for web developers to directly control the environment the deploy to; Just push the content to your server and you are done, a new version is deployed. Especially Apple makes that harder for you on native, you need to get your App through a review process, which will take some time; Currently, you have to wait 4 days (See the current time at appreviewtimes.com). If this is a normal incremental update of your application, it might not even bother you, but if you have a typo or even a bug which leads to crashes of the application it definitely will. This will hit you even harder in the native app environment than in the web, because reviews in the app store remain visible, even if you app is updated.
The other point is the development speed which is in my opinion faster compared with native development due to the missing compile time for React Native. This will be topic of another part of this series, How to pitch React Native to Designers, so let’s go on to another key point.
No narrow specialists needed
Additionally, if you like to, later on, add another platform, you will have the fair chance that React Native itself or some Open Source implementations will have just the right thing for you. If not, you might even consider to write it yourself, like Netflix did for Smart TVs some time ago.
More developers may work on one application at the same time
I don’t know how much this is true (if you find out more on that topic than me, please share your knowledge), but I guess that due to the imperative structure of Objective-C and Java simultaneous development may lead to problems. With React Native, two developers may write their own components which may be used beside each other and composed of each other without any problems. On top of that, one may reuse various parts and the whole structure around it not only in various applications but also in various platforms.
If you would like some more insights on the benefits and challenges of growing full-stack developers into cross-stack mobile developers who are responsible for Android and iOS you might want to check the talk by James Ide from the React.js Conf 2016.
Want to hear more from me? Feel free to subscribe to my newsletter; I send out news roughly once a month.