April 4, 2017
We’ve looked at the positives. We’ve looked at the negatives. So – should you use it?
Of course, these are the kind of questions that only you and your team can ultimately answer. You’ll need to consider your own circumstances, and those of your team and project.
One thing I will add before we move on, is that the development time of a React Native app, as opposed to having multiple native apps, will never be 1/<number of native platforms>. You’ll make time savings, but just how much time will vary a fair bit from feature to feature.
Nevertheless, based on my own experiences, I recommend considering the following points before making a decision either way on whether to use RN.
Since it’s still pretty new, the likelihood is many of your team won’t have any direct experience… If no-one on your team has made a fully-fledged RN app before, I wouldn’t recommend using it on a product that has a deadline of under three months.
I wouldn’t recommend using a bleeding-edge, relatively undocumented framework to inexperienced or mediocre developers. You need people who can pick it up, play with it, and get going. Try to let your Lead gain some experience with RN at the very least – some time to play in the metaphorical sandbox.
What kind of engineers am I talking about? I mean people whose appetite for good code leads their ability. People who are stable and disciplined, and not language/environment snobs (i.e. if they laugh at the mention of Javascript, they’re probably not going to clamour for React Native).
Redux requires an appreciation of pure functions and immutability. Using functional libraries like Ramda/Lodash makes it all very tasty. If a Functional Programming approach is unfamiliar to your devs, RN probably isn’t for you.
This one should hopefully be obvious. Don’t take my word as gospel, or what’s in your own head. Ask your team. If you can’t convince them to try it, don’t force it. It won’t work out.
There will be many an OSS pull requests to dedicate time to. Most of the time it won’t be wasted effort, but it will take time. This is just standard OSS territory.
Some features are insanely quick to develop with RN, and it can be amazingly performant out of the box (as described in part one), but your devs may take a deep intake of breath when you ask them to do certain things (????). Often it’ll be that extra sense of polish – and despite the many things RN has going for it, that’s still something that only a purely native app can give you in a reasonable time frame.
React Native is not React. So don’t think you can get away with using mainly React Web devs (unless they are really good, fast learners, and don’t mind getting stuck and asking for help from a Native background person on the team).
The intricacies of the different platforms are not avoided with RN. To succeed, you need to have a solid enough background in Android or iOS – mainly to have familiarity with the tooling, but also to be productive in general. So while you may be able to task React devs with certain things when you’re in a busy period, they will not be able to lead or really get stuck in without a certain amount of handholding.
The roadmap of RN is a little murky, but Facebook doesn’t seem to want to drop this puppy – it seems to want it to replace native dev (and that’s as ambitious as it gets!). So hopefully it will mature and not get canned. Nevertheless, at this point in time I’d suggest the longer you want your app to live, the more you should consider sticking to native or something altogether more vanilla.
It’s important to note that Apple in particular is extremely protective of iOS and exercises a higher level of control around what goes on the platform. It’s not inconceivable that it might have something to say if React Native were ever considered a threat to the differentiation of the iOS platform, or to Apple’s own native development ecosystem. It’s unlikely to sit idle whilst Facebook asserts itself as an aggregator of Mobile platforms, of which iOS is just another example.
This is the big killer, and it’s enough to put some people off on its own (if they’ve been burnt by Parse for example). RN/React has also had a strange license history. It has since been clarified and original objectors – behemoths like Apple and Microsoft – have since changed their tune. The main-take point in my book is that if you’re planning to challenge Facebook, or get big enough for Facebook to come knocking on your door… RN may not be for you.
That said, this may be a good problem to have, if you ask me! If you’ve become a threat to Facebook, well done – they’ll probably buy you…
Do you have the time and flexibility to create a rough and ready MVP? Or do you have a specific part of an app, a low risk section where you can try out an RN view? Remember, the Facebook app itself is a combination of purely native and RN. This would be preferable than going in at the deep end and committing yourself completely.
Hope this was useful!
The points in this blog series have mainly been gathered from personal recent experience on a major automotive start-up. If you’re keen to know more about RN, here’s an excellent and far more technical, well referenced and thorough run-through by Ariel Elkin.
If you’ve worked through all these blogs and have positive answers to the challenges and risks, RN might well be perfect for your project. Good luck! Please let me know how it goes or if you have any questions – you’ll find me @thesecond_t on Twitter.
All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.
If you’d like to find out more about working with us – get in touch. We’d love to hear from you.