Others have been coming out and talking about similar experiences with React Native. This thread made the rounds on Twitter and Medium fairly recently:
For me, I'm using it to successfully build mobile apps for a large tech company with very limited mobile developer resources. We've been able to ship Android and iOS apps in a couple months using 100% react-native. I attribute a lot of this to knowing the limitations of the platform and designing a cross-platform experience from the start rather than trying to get the "best of native" out of abstracted JavaScript.
I'll always argue that native is the way to go for the best user experience but react-native is a great tool to have in the mobile space.
We've experienced some of the difficulties in this area at Facebook as well. If you're curious, making native <-> JS integration more seamless is a big motivation for the ongoing architectural revamp that we've recently posted about: http://facebook.github.io/react-native/blog/2018/06/14/state...
It's a shame we weren't fast enough to help Airbnb in these areas, but the native interop will get better when the revamp is finished.
You obviously have much more insight into what the re-architecture will entail than I do but I've heard a lot of worry around that post with regards to backwards compatibility of third party libraries and in-house native components.
I hope RN is going to stop relying on beta code for releases too.
The reason updates are easier at FB mostly has to do with atomicity of commits. Because FB uses RN from master (and in practice all code lives in the same monorepo), codemods can be applied to products together with the corresponding infrastructure changes. Since the upgrades have a commit granularity instead of the monthly stable releases we cut in open source, there are no big delays between a regression being introduced and fixed for FB products. This discrepancy is unfortunate, but I don’t really see a way around it for an actively developed library--which might be your point.
Undoubtedly RN is in active development, and being a moving target, it's easier for FB teams to “follow” it. Still, large backwards-incompatible changes are just as infeasible for us as for everybody else without either an automated codemod or an opt-in strategy.
This doesn't work for any larger changes because nobody is able to rewrite a ton of files by hand just to change some API. So this is why we can't make big changes to the API without a gradual adoption strategy, even internally.
My current company casts a weary eye at third party software so the import process is slow and involved. This means we only take major versions, and usually not very quickly. When those versions then introduce regressions in our own products and in dependent libraries it only serves to strengthen the voices calling to ditch the external solution entirely. It'd be a different story if a major version seemed to be of consistent quality to squat on for a while, but each new version brings its own challenges.
To be clear this is all involved in life as a dev in a large software company. For my own personal use I'd rather see RN move as fast as possible. I'm fighting the good fight to keep up (and increase) adoption at work so I just hope that FB and the RN team keeps these things in mind.
Thanks for the additional insight here.
In my use we've hardly met any of those problems. I work for an agency, and the apps we've used it for are small or medium sized. All are new apps without legacy native components, and none of them mix RN with native outside of plugins. We also use 100% TypeScript now, which fixes a lot of their error-checking issues. Perhaps most importantly, I'm one of the few developers with significant native experience, so we're not encountering the cultural problems that they describe in the posts, of developers resistant to using the tech.
That said, the experience we’ve had has largely been positive and I don’t think we could have achieved what we have so far given team size and time constraints without React Native. I suspect it gets more painful if you try to combine native and RN GUI elements - our UI is purely RN so there is a fairly clear separation of concerns.
I have separation of container components and presentational SFCs so I’m thinking I could easily re-implement UI layers in RN if I wanted to without sacrificing the shared code. Do you think this is a reasonable approach? Or should I ditch RN completely and build native...?
It would be nice if there was a way I could pull that shared JS logic (which really doesn’t have much dependencies) into mostly-native apps without having to adopt RN... maybe I could just repurpose the JS bridge and be aware of its limitations (a sync/serialized/batched..)
For sharing presentation, I'm hopeful for solutions like react-native-web.
I have successfully used this approach to develop applications for both Android and iOS.
You often don't hear about these kinds of issues out of game engine makers. I could be totally wrong although since I haven't worked on games.