Introducing Create React Native App
facebook.github.io
facebook.github.io
I got the feeling that it's layers upon layers of leaky abstractions and the whole thing seems rather fragile.
I know I am just complaining like a grouchy old man and not really helping understand and solve the problem, but that's what I can do right now. I would say that maybe we are building too modular software and the complexity of glueing everything together is becoming a problem? I feel like the existance of several "react + this + that" boilerplates indicates something.
I can also be wrong and everything is OK and I am problematizing.
Before I joined that project they were using yoeman and angular and a bunch of other useless crap. I got rid of all of it.
But then again, I already have a lot of experience with normal web development, so I already know what's under the cover, more or less.
Whereas with mobile, I have none, and I felt that RN was supposed to let me do mobile dev despite not knowing what goes on under the covers.
"Linking" these plugins is black box magic, if anything the fails I have absolutely no clue what is going on.
I have a feeling that some of the hairy errors I've been getting have something to do with the plugins not being up to date with the other libraries.
But like I said, I just have no idea what's going on.
If I'm going to learn how Android and iOS code needs to be structured then I prefer to just write native code. At least I will have more control.
Expo has audio (https://docs.expo.io/versions/latest/sdk/audio.html), file system (https://docs.expo.io/versions/latest/sdk/asset.html), and other APIs built in (https://docs.expo.io/versions/latest/sdk/index.html). We don't have sqlite right now but are actively working on it!
The idea is that we provide a lot of nice things out of the box and then if you still need to write native code you can detach (https://docs.expo.io/versions/latest/guides/exponentkit.html) and only write the native code you need while keeping all our other APIs. You can still use `react-native link` after detaching if you want.
That's not my idea of a filesystem API.
So far it's been amazing!
I'll be doing a brief demo during my lightning talk at ReactConf -- livestreamed at ~5:45pm pacific time today at http://conf.reactjs.org/livestream.
Then earlier this year I tried RN. And yes, I struggled mightily at times with building/deploying/linking libraries, but when it came to the app it finally felt closer to the level of effort I put in building web stuff. And then I finally sent an app out the door with Camera integration and some pretty neat UI elements. All thanks to this.
RN has lowered the barrier to entry in such a way that I have a feeling my story is/will be incredibly common. CRNA is yet another great step in that direction, so on behalf of us mostly part-time devs, thanks a ton!
During 24 hours at a hackathon I was able to build an app that would show a live view of the camera, capture 5 frames a second to be analysed by an external api, overlay recognised food items on the screen, send it all off to the hello fresh api and display a list of recipes to the user that would use the most food items from their fridge.
The fact that I was able to accomplish all of this in 24 hours with no prior RN experience is just amazing to me.
Edit: Expo has open sourced their code, see below. And CRNA does not build code on their servers, I assumed it had the same workflow as their XDE tool. It does not. But I'm still unsure of this decision. It makes Expo a vital part of React Native, or at least puts them in the position to have that position.
https://github.com/exponent/exponent
https://github.com/exponent/exponent-sdk
https://github.com/exponent/xdl
Also, the RN packager runs locally on your machine, there is no dependency on Expo's build services when working with Create React Native App.
The concerns you raised were front and center when we were working on this project, and we worked hard to make sure that CRNA has no service dependency, it works completely offline.
CRNA doesn't use our app building service (which is free) or integrate with it, though you can take a CRNA project and use it with the rest of our tools like the app building service.
Also, CRNA does support ejecting which gives you an Xcode project and an Android Studio project. You can really control everything you want to control here.
The Expo client is open source, so you can fork it for your needs if you want.
Also, if you do start an app with CRNA, and decide that you want to avoid everything-Expo-related, you can eject to a native app with one command.
In summary, we have been careful to craft the CRNA solution to have absolutely zero lock-in.
Regarding your concerns about "private entities," React Native is open source. Expo is open source. React Native was created and is maintained by Facebook, a private entity. Expo was created by and is maintained by Expo, a private entity. Do you have the same concerns about the recommendation in the RN docs to use Airbnb's maps library?
In order to use CRNA, you need to have a client that can fetch and load the JavaScript bundles. CRNA is agnostic to which client you use, which is why app.json puts any Expo specific configuration under an `expo` namespace. Anyone is welcome to implement their own client and use that if they prefer. I'd be very happy to review PRs which support loading React Native JavaScript in an alternative client. As an implementation detail of the Expo client, a number of native APIs are exposed, and it would be infeasible to block CRNA apps from accessing them.
We don't push users towards the Expo SDK, and the template project doesn't make use of any Expo APIs. If users choose to include a dependency on Expo's code, then we warn them that ejecting will break that dependency -- that's it. We choose a default choice in that prompt on the basis that we don't want to push users towards breaking their app.
"Do you have the same concerns about the recommendation in the RN docs to use Airbnb's maps library?" No because that is not even an apt comparison. An apt comparison would be if AWS Engineers helped make 'react-create-app' and they bundled the AWS SDK as well merely to be 'helpful'. That would be an apt comparison not a recommendation on the official documentation to use a certain library.
If you don't push people towards the Expo SDK then remove it from the default 'react-native-create-app', I'm okay with it being in certain templates but a private entity should not be in a default. You clearly benefit from this decision, yet your pretending that it is only because it's in the community best interest.
Nobody is pushing anyone to use Expo's SDK. You are free to choose whether to use it or not. In the same way, you are free to use Facebook's React Native framework or not (bear in mind Facebook is a listed entity with its own corporate objectives as well).
Slight off-topic: is it possible to use C++ code cross-platform way for performance-critical parts? i.e. to have single C++ code for iOS and Android, in React Native.
Yup you can! That's actually how Expo's `GLView` (which exposes OpenGL ES as a WebGL'y API in React Native's JS context) works. The binding is done in common C++ code for both iOS and Android. Calling to that from Obj-C is straightforward, for Java you use JNI. This is binding is done manually and built once (not auto-exposed), then you can use the GL stuff in JS!
https://github.com/exponent/exponent/blob/master/cpp/EXGL.cp... Here's the code
It is definitely possible to create a cross-platform C++ library to share performant across platforms, but unfortunately you need to do the plumbing for each platform by hand.
React native, Ionic, etc. are great for most apps out there. There is nothing special required to get a great app published in very little time, and existing developers can jump on the project and get it done - which probably results in much cheaper overhead for a startup. It really is a win-win.
The only reason I'd consider going full native these days is for mobile gaming, and anything requiring low-level control.
It's still early exploration for me, so I might change my mind on this, but I'm not expecting RN to be a game-changer. Definitely useful, but not really going to upend anything.
Mobile app projects under $20k are definitely react native. It also makes mobile app projects at the $10k level now viable. At the $40k level it'll be a tough choice, with the fact that the project wants to reuse parts for a web app being the clincher.
The other obvious reality is of course that RN isn't meant for 3D, games, or so on. But that's been the understanding from the get go. What started out as replication of whatever UI components that the first and second class FB apps were making use of has now grown into a community that covers many, many different UI cases.
RN is pushing Swift, ObjC, and Java engineers upwards to focus on the upper end but it's wiping out the bottom by letting the web devs into the mobile devs world.
At the same time, I'm sceptical that RN has escaped the earlier performance ghettos of Appcelerator, Phonegap et al., which aren't just in games, but also in complicated UIs with a lot of elements. On building a simple sudoku app, I ran into noticeable micro-lag that seems to come from overuse of Views to structure the grid--and noticeably, the performance was better on a non-retina device, causing me to remember the swamp that Java's AWT got caught in with its 'native peering' arrangement, namely that cumulative overhead killed performance in virtually all non-toy cases. React's virtual DOM is an obvious plus in the browser; I'm not so sure where native apps are concerned.
That's a problem for your designer to solve
At some point, you reach the limit of what the framework provides, and you need to write some native code.
I've always felt that most frameworks required you to rewrite your app in native code once you hit these limits, so it was better to just start with native code in the first place. React Native is the first framework that doesn't make me feel this way.
We pitched (and won) against a competitor who was proposing to use Outsystems last year - who's product creates a React.js Cordova app - and it's mostly only 'cause they demoed badly that we beat them, I was impressed with the capability of their tool (and without doubt their autogenerated react.js thing is well under development to produce react native apps very soon...)
Some apps will always be native code - if for no reason than to gain access to new device capabilities on launch day instead of sometime down the track when bridges or native plugins for the hybrid tools ship - but a vast number of apps can (or are being) reasonably built using hybrid tools these days...
Declarative UI, hot loading, code reusability, modularity, etc. You name it. Because of all these I feel like a dinosaur whenever touching non-react code.
Native covers the parts where React is clunky - for example some unorthodox UI elements that can't be created with simple views and flexbox styling
Core functionality is there already and with time it's only expanding.
I don't intend on turning back.
I've been building a React Native app and there are a couple big positives for it.
l. All the web developers at my company can manage in JS. You don't need special talent or training like you do for the other languages. Our native apps are built by completely different teams because of their native skill sets.
2. The app we're building shares most of its code between iOS and Android. This prevents you from building the same app twice in two different languages (and as I pointed out, for us, in two different teams).
I found React Native to be a mix of joy and frustration. I was amazed at how quickly our devs, who came from the web, could build polished screens that performed beautifully. Then I would become baffled at how, for example, you couldn't do a background upload in React Native. Here - it does is upload a file in the background: https://github.com/Vydia/react-native-background-upload
In RN, you have to connect JavaScript to native code with "bridges". If a bridge exists for, say, getting GPS data, you are fine. But if it doesn't, welcome to the club. I finally became relatively adept at writing these bridges, but I would have much rather have spent that time writing code for my app.
Their build system is weak. For example, the build scripts hardcode 'dev mode' unless you have a build scheme in iOS and Android called 'release'. It felt like nobody else had built RN apps that have beta and staging environments. Crash reporting sucks and we finally got it working with sentry.io and some custom build scripts to upload source maps so we could get decent JS error reports.
But that stuff will go away in time. I was blown away at the progress we made. It was painless for web devs to jump right in an be productive. So for us it's a net positive.
If you're starting something new, try it out. Make your platform choice carefully. RN isn't the only game in town. See what works for you. And don't get fooled into thinking that you don't need any native knowledge to make an app. Maybe hello world, but nothing industrial grade.
What else is there that's similar? NativeScript?
The positive: If you know JavaScript, you can get started quickly because they provide a JavaScript API and all your code is in JavaScript. Under the hood the JavaScript connects to native code. So you get a native look and feel on iOS and Android. You have a single codebase.
The negative: Back then it was impossibly hard to get an app working and/or looking correctly on both iOS and Android at the same time because Titanium was full of bugs. So many bugs. This is because for each platform they have to provide native code. Sometimes their iOS code had bugs, sometimes their Android code. It was absolutely frustrating. I often had to find workarounds which caused a lot of delay so I had to double down to keep the deadline. Titanium was a reason I quit that job after 1.5 years.
On paper it’s nice, but the implementation was terrible. I went back to web apps and have since been happy.
$40/month, but no visual builder. Eclipse-based IDE tooling (which was always flakey ime). $100/month/seat to get hyperloop and visual builder. Still not sure what 'arrow' is exactly.
The demos always looked good, but my day to day was... frustrating after a while. Possibly could have stuck with it and justified with "sunk cost" but I started looking more closely at cordova stuff. Yes, it's not pure 'native' (why I liked titanium) but the ecosystem is more flexible (or so it seems).
RN is not perfect, but it's leagues ahead of Cordova, Xamarin, and etc in a combination of performance and easiness of UI development.
I think the biggest problem with adopting React Native in a shop that already has a native team is politics. Lots of Native developers don't want to touch it.
I think it's a great fit for companies who already have a React front end team and who's mobile teams are at least open to giving it a try.
I feel like this is a huge understatement. Doing anything non-default takes ages to configure, and there's so little documentation to help you out.
On a side note, their build scripts are all js and node is probably my last choice for build scripts. As a result, you have callbacks and promises everywhere. I understand they don't want people installing more dependencies but using something common like Ruby would make it much easier to build great build tools.
For what it's worth for react-native proper we are investing a lot of time into this now. With latest sentry-cli getting sourcemaps going is a one-line change to your build script.
https://docs.sentry.io/clients/react-native/#updating-build-... (you only need the line with react-native-xcode)
They will have a hard time if we become extinct.
Expo includes a `GLView` component that provides a WebGL-like API to OpenGL ES. Things like three.js run on it directly! But CPU-side JavaScript becomes a bottleneck (the shaders themselves run at normal speeds).
One of the reasons I like React Native a lot is because it makes it so easy to drop back to native code when I need to.
React Native basically solves this and solves it well, and can perform well in most cases.
And if there is some screen where it doesn't (ex. if you were building Snapchat and were going to work on live video filters), you can implement that in Swift/Java/Obj-C and just make that a native module that's part of your RN app.
My personal prediction is that almost all apps will be started in RN in the medium term future and most will end up mostly RN.
Honestly I think in 1-2 years at max reactnative will have the same popularity of Ionic and Phonegap at max, and probably far less if react will fall against the newcomers of the web-frontend space (vue.js, inferno.js, riot.js, etc) as fast as it seems doing right now, remembering closely the time of angular1 eof vs react beginnings.
As has been the case with all human artifacts since humans started creating them.
I'm fine with iteration as long as:
a) each one increases developer productivity
b) they remain stable for at least two product release cycles.
My experience is: finally, I can program like I do on the Web! And not just in the sense it uses JS, but like, double typing R to "reload" the app being super fast and seamless. Coding my first React Native app has been the most enjoyable experience I've had creating a native mobile app ever. Even small stuff like being able to use the Fetch API over whatever native gobbledegook API Android uses is a massive quality of life improvement for me.
I actually don't particularly care for React itself (the Web version), but that's because its download/execution costs are still iffy for me and I don't think JSX has a place on the web long-term. I also don't think it's opinionated enough and the roster of React "plugins" reminds me of the bad side of jQuery widgets. (If you couldn't tell, I've moved to being more of a Vanilla JS purist in recent years as the ECMAScript standard has evolved.)
With React Native though, none of those points really matter and I'm able to enjoy the "breakthrough" of self-contained JavaScript components combined with super fast debug iterations. It's a win-win in my eyes.
I'd much rather see some of the positive traits of JS/RN/etc find their way into Swift/UIKit/etc so I don't have to trade away what I like about native development in its current form.
As for someone who was using Expo for a while, how's that different from the exp start and the rest of the platform? Seems like an interface or another entry point -question if necessary?
* Doesn't require an Expo account
* Faster to get started than using XDE
* Smooth 'eject' integration with react-native-cli, if you know that you're eventually going to need custom native modules
I'm sure I'll think of some others at some point. One goal we have right now is to start bringing the same level of polish to the existing Expo tools.
The examples use a navigation library that is implemented entirely in JavaScript and it does not currently aim for 100% accuracy for platform gestures and animations. Pure JS navigation is a work in progress with React Native but, in my eyes, it's the ideal end-state (see a post I wrote here for more info: https://blog.expo.io/good-practices-why-you-should-use-javas...), but to get there we need some more powerful low level primitives such as a better gesture API.
If you prefer to trade-off customizability for platform-specific animations, you can use NavigatorIOS with Expo/CRNA - https://facebook.github.io/react-native/docs/navigatorios.ht.... If you eject, you can use a library like react-native-navigation (https://github.com/wix/react-native-navigation) which bridges the native navigation APIs, or an upcoming library from Airbnb which they use in their app.
Also, I'm curious which examples stood out to you. The "Growler Prowler" app intentionally pushes a screen on top without sharing a navbar, even though this is possible, because this works better for the detail screen. See the beautiful PocketCasts app (https://www.shiftyjelly.com/pocketcasts/) for the design inspiration there.
Hope that helps!
https://news.ycombinator.com/item?id=8965349
A pure-JavaScript implementation of navigation might feel almost native on today's mobile platforms if you work hard enough at it. But will it feel native in the next release of the OS? And does it feel native for all users? For example, when a user of the VoiceOver screen reader on iOS navigates to a new page in your app, do they hear VoiceOver's "new screen" sound effect, as they do when using a real UINavigationController? Also, VOiceOver has a special gesture for going back. Will that work in your nav implementation?
My point is that when you start with cross-platform and try to tweak and tune it until it's native, you might miss some subtleties, and it might still not feel native to some users.
- This guide from Microsoft explains how to use typescript: http://www.reactnative.tools/tutorials/2016/09/20/reactnativ...
- This is a bit old but could help with Mocha setup: https://formidable.com/blog/2016/02/08/unit-testing-react-na...
Hope that helps!
It looks like the setup is still a bit messy, they do mention open issues and it seems that some people are working on making the experience smoother, it would be awesome to have something as simple as:
create-react-native-app my-project --language typescript
Some people have set up some stuff for doing ClojureScript with Expo.
https://docs.expo.io/versions/v14.0.0/guides/using-clojuresc...
You can find them in the #clojurescript channel in the Expo community Slack. https://slack.expo.io/
That might be the best place to start.
I also threw up a post in the forums that we just setup. https://forums.expo.io/t/integration-with-typescript-mocha-o...
I'm used to using Webpack or Gulp or Grunt to transpile source code into something deployable on the web. The React Native / Expo packaging process feels opaque to me though. It's not clear to me, for instance, whether Expo uses https://github.com/facebook/react-native/tree/master/package... or whether it has some kind of different packaging process.
Likewise, a newly created project with the XDE builds automatically using Babel. But it's not clear from the project itself how XDE knows to use Babel. Is Babel hard-coded in the XDE? Can I turn it off?
Expo apps also all seem to have a `registerRootComponent` function, but there isn't any documentation on what this function actually does.
The `registerRootComponent` function is essentially a facade to `AppRegistry.registerComponent` but it also configures hooks for Expo's asset system.
There are also ways of bridging over to native scroll views - see this article[2] by Wix's Tal Kol for one example.
1: https://facebook.github.io/react-native/releases/next/docs/f...
2: https://medium.com/@talkol/recycling-rows-for-high-performan...
The clause of the app store guidelines is not just about code; it also forbids gaming the review process for adding features or changing the app purpose without an explicit review. This is regardless of the language used to write the app.
About react-native-invoke: https://medium.com/@talkol/invoke-any-native-api-directly-fr...
The GitHub page has been set to private for ... reasons I can't divulge, but the NPM package is still public.
"Your app, extension, and/or linked framework appears to contain code designed explicitly with the capability to change your app's behavior or functionality after App Review approval, which is not in compliance with section 3.3.2 of the Apple Developer Program License Agreement and App Store Review Guideline 2.5.2. This code, combined with a remote resource, can facilitate significant changes to your app's behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes."
To get as good of a development experience as React, it would require some work by the compiler and runtime people to basically let you do something like hot loading--Android has something like this now, and maybe Apple will get it too, though I'm not holding my breath.
I think it's a no-brainer for web development these days to do React because 1. you can opt out of it for parts of the page it's not going to work with for whatever reason and 2. the performance is pretty damn good compared to lots of alternatives, including writing all the UI state management logic yourself. However, I've not been convinced that the buy-in is worth it for native mobile development. Can someone who knows more tell me: is it fairly easy to do something like say "I can't/don't want to use React Native for this view controller--I'm going to implement it in code and use it and everything will just work."
Nice.
Additional information: I was connected to the Debian server via putty/SSH with the js server open and that connection broke around the time where my phone layered infinite "loading js package" messages above each other. I guess you should at least do something to prevent that from happening on the client side. The server side and connection problems are my own demons...
Could there be any logs on my phone or server that could help you? As for the platform information, I will see what I can get once I can access the server again. It's a Moto G4 with Android 7 and the server ran some old Debian and node.js 7.x .
It worked perfectly fine on my local Windows computer.
I'm very surprised to hear about the behavior you ran into with the loading messages on top of each other -- we haven't run into this issue in the native client yet (I don't think). If you're interested, I think a GitHub issue may be best so that I can have a reminder to look into this later on this week.
EDIT: That said there are definitely some areas of CRNA that have had more polish than Expo's current tools, and I'm going to be spending a lot of time in the coming months bringing them closer to parity.
2. React Native Navigation Library (airbnb.io)
3. Introducing Create React Native App (facebook.github.io)
8. Wix Releases a React Native Physics Engine (github.com)
WASM solves a totally orthogonal problem: running native-ish code in places where native code is currently unacceptable (e.g. web, other low-trust scenarios). Major mobile platforms can handle native code just fine, and WASM does precisely zero to help you write bindings for platform APIs.
I disagree. I want to dump "native" and just have a more performance engine than is JavaScript. I am assuming that more native hardware will be exposed via WASM. I want the high-level language that is compiling to WASM to isolate me from the platform differences. Perhaps is wishful thinking on my part.
If you want more performant code than you're getting from hand-written JavaScript, you need either (a) an improved JavaScript engine or (b) to write code in a different language. WASM isn't some magic escape hatch for high level languages.
Yes, that's what I want
>normal performance bottlenecks there,
I've never found the DOM to be a performance bottleneck, and I build UIs with thousands of elements.
>I don't see them overlapping anytime soon
I hope not. Like I said, I don't want React - I want WASM and good high level languages. And I want more device support with WASM.
1. Native apps does not have anything like browser DOM. Most of complex controls recycle views based on internal control logic. I don't see how Virtual DOM idea can be mixed with that. UITableView does not care about Virtual DOM and there is no easy way to apply Virtual DOM diff to a particular cell. To make default iOS table Virtual DOM aware you will have to rewrite it from scratch. Quote from here - https://medium.com/@talkol/recycling-rows-for-high-performan... >Recycling previously allocated rows that went off-screen is a very popular optimization technique for list views implemented natively in iOS and Android. The default ListView implementation of React Native avoids this specific optimization in favor of other cool benefits
2. Running event handlers in a separate thread is very bad idea. Appcelerator Titanium does same thing and it gave me all sorts of trouble in the past. For example - you scroll UIScrollView and it generates scroll events. These events asynchronously delivered to JS thread. JS thread changes view position. UIScrollView expect these changes during scroll event not after and does not optimise for that. As a result you get gazillions layout/scroll events which kills layout performance. You also get tons of locking/unlocking as a bonus. In Titanium delay between UI event sending event and JS thread receiving it was visible with naked eye. It was virtually impossible to create responsive UI due to these delays. React Native seems much better in this area but I suspect that complex cases like I described above will break.
3. People have been trying to build cross platform UI for decades. There are dozens of desktop technologies in this space. None of them got even close to the point of replacing native UI. Maybe React Native will be first one but statistics is not on their side. I think technologies which draw all UI themselves does better than others which provide cross platform wrappers to native controls. - Java Swing, WPF, maybe QT - see some use, mostly in enterprise. - Java SWT, wxWidgets (I can add AWT here) - only SWT is being used in Eclipse, others are pretty much dead.
So I'm really sceptical about React Native future as a replacement for native UI. It might be useful in niche areas but polished apps might be very problematic.
You might also find this interesting - Bloomberg rewrite it consumer app with React Native https://www.techatbloomberg.com/blog/bloomberg-used-react-na... - Customers rate it one star - https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8
Couple of years ago I've spent few months digging into Appcelerator Titainum which is also based on JS and in a few of ways similar to React Native. After fixing few bugs in Titanium code base and even making myself familiar with WebKit internals I can tell that Titanium is complete a garbage without any hope for improvement. Major reason for this - they decided to run JS on separate thread for performance reasons.
1. Native apps does not have anything like browser DOM. Most of complex controls recycle views based on internal control logic. I don't see how Virtual DOM idea can be mixed with that. To make UITableView Virtual DOM aware you will have to rewrite it from scratch. Quote from here - https://medium.com/@talkol/recycling-rows-for-high-performan... >Recycling previously allocated rows that went off-screen is a very popular optimization technique for list views implemented natively in iOS and Android. The default ListView implementation of React Native avoids this specific optimization in favor of other cool benefits
2. Running event handlers in a separate thread is very bad idea. Appcelerator Titanium does same thing and it gave me all sorts of trouble in the past. For example - you scroll UIScrollView and it generates scroll events. These events asynchronously delivered to JS thread. JS thread change view position. UIScrollView expect these changes during scroll event not after and does not optimise for that. As a result you get gazillions layout/scroll events which kills layout performance. You also get tons of locking/unlocking as a bonus. In Titanium delay between UI event sending event and JS thread receiving it was visible with naked eye. It was virtually impossible to create responsive UI due to these delays. React Native seems much better in this area but I suspect that complex cases like I described above will break.
3. People have been trying to build cross platform UI for decades. There are dozens of desktop technologies in this space. None of them got even close to the point of replacing native UI. Maybe React Native will be but statistics is not on their side. Technologies which draw controls themselves does better than others which provide cross platform wrappers to native controls. Java Swing, WPF, maybe QT - see some use, mostly in enterprise. Java SWT, wxWidgets (I can add AWT here) - only SWT is being used in Eclipse, others are pretty much dead.
So I'm really sceptical about React Native future as a replacement for native UI. It might be useful in niche areas but polished apps might be very problematic.
You might also find this interesting - Bloomberg rewrite it consumer app with React Native https://www.techatbloomberg.com/blog/bloomberg-used-react-na... - Customers rate it one star - https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8
Couple of years ago I've spent few months digging into Appcelerator Titainum which is also based on JS and in a few of ways similar to React Native. After fixing few bugs in Titanium code base and even making myself familiar with WebKit internals I can tell that Titanium is complete a garbage without any hope for improvement. Major reason for this - they decided to run JS on separate thread for performance reasons.