16 ms·

Introducing Create React Native App

535 points by anp 10y ago

brilliantcode 10y ago
Has the Android side improved with React Native? The last time I took a look at this which was last year, the consensus was the Android result wasn't optimal.
- lacker 10y ago
  There's a ton of work going into polishing many different parts of React Native right now. So "the Android experience" has definitely improved overall. But it probably depends on what specifically you were running into last year that was frustrating during Android development?
- pgm8705 10y ago
  I have an Android app in production that works as well as its ios counterpart. Launched it in the fall of 2016.
- buckhx 10y ago
  We're pushing one out in the next few weeks. Haven't ran into any dealbreakers. Ours is fairly basic displaying info from an API so YMMV.
- deleted 10y ago
  [deleted]
donjh 10y ago
Create React App was a great addition to the React ecosystem and definitely made the library more approachable. Excited to check this out!
dikaiosune 10y ago
Hi! I wrote a bunch of the code for CRNA (although it obviously builds on a lot of great work from Facebook and Expo people). Happy to answer questions. 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 http://conf.reactjs.org/livestream.
- ChrisBland 10y ago
  No questions, simply saying Thanks! I've been trying to show people RN and this will make it super easy to introduce it to them. Know a lot of work in the OS community is under-appreciated, so great work & thanks!
- jondot 10y ago
  Brilliant!
- ChicagoBoy11 10y ago
  I remember buying a Mac in college because I was finally going to get into Native development!! Well, that was almost 10 years ago and after many false starts it just never happened... seemed like such an insurmountable amount of cruft for even the most mundane things. 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!
  - sorenbs 10y ago
    I'm a fairly experienced backend and web developer. My first experience with RN was exactly this. 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.
    - sorenbs 10y ago
      Btw, GraphQL and React Native / Expo is a great combo https://www.learnapollo.com/tutorial-react-native-vanilla/rnv-01 https://www.learnapollo.com/tutorial-react-native-vanilla/rn...
Kiro 10y ago
Is there any reason to use this rather than "New Project" in the XDE if you're already an Expo user?
- dikaiosune 10y ago
  Probably not. One of the biggest advantages of CRNA is that we built it from the ground up to not require integrating with Expo's accounts or services. If you've already opted-in to those services, then you're probably getting what CRNA offers plus a little extra. 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.
eeeze 10y ago
Thanks for the great work on it! Will definitely check it out. 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?
- dikaiosune 10y ago
  The biggest advantages of CRNA right now are: * 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.
ourcat 10y ago
Didn't Apple start rejecting apps recently which do 'hot code' pushes to update apps remotely? (As the video on the Expo.io site says)
- nuggien 10y ago
  I think it was just apps that pushed updates for native code, and javascript updates are still fine (for now).
- benhoyt 10y ago
  I believe that was only for apps that could talk to Objective C API's natively, in other words, essentially bypassing the native code review process. React Native can only do hot updates of JavaScript (which may call existing Objective C API wrappers, but not create new ones).
  - LeoNatan25 10y ago
    It's exactly the same in the case of Rollout, they were also only updating JS using JavaScriptCore, not using new native APIs.
    - jameside 10y ago
      Rollout exposes arbitrary Objective-C APIs to JavaScript (likely using Objective-C's reflection capabilities), while React Native and Ionic/Cordova WebViews require you to explicitly bridge your own native methods. That was one of the key differences in Apple's concern.
      - LeoNatan25 10y ago
        Implementations already exist, such as react-native-invoke, that enable similar functionality. The jump from "need to explicitly bridge" and "explicitly bridge the runtime API" is very small, opening the possibility of exactly the same features as Rollout. 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-from-pure-javascript-in-react-native-1fb6afcdf57d#.60pyo15vg 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.
RubenSandwich 10y ago
I'm a bit unsure about this decision. Because this is tying React Native to a private entity, namely Expo, that has not open sourced it's toolchain used here. Expo takes your code and builds it on their servers and then serves it to you. That toolchain unlike React Native is not open source. This is creating a walled garden around Expo who can easily decide to charge for their server fees. Yes it is a much easier of an boarding experience then installing Xcode and Android Studio but at least with Xcode and Android Studio you own the whole toolchain. Because of this fact I don't think this is comparable to React Create App, which is excellent. 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.
- dikaiosune 10y ago
  Hi! Expo is definitely a private entity, but the tools used by CRNA are also definitely open source: https://github.com/exponent/exponent https://github.com/exponent/exponent https://github.com/exponent/exponent-sdk https://github.com/exponent/exponent-sdk https://github.com/exponent/xdl 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.
  - RubenSandwich 10y ago
    What about the build server?
    - dikaiosune 10y ago
      Which build server? If you have an Expo account you can create a "standalone app" with our service, but that's not a part of CRNA's workflow and it's certainly not required to use this tool.
hypercluster 10y ago
Always interesting to see how cross platform is evolving (this and also Xamarin update recently), wonder how the Google and Apple regard this. Anyway, I just tried out the Expo App on iOS and noticed that the back swipe animation does not seem to be native in the examples. Is there a reason for that? (that's something I always try out of I want to check if an app is native).
- brentvatne 10y ago
  Hello! 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-javascript-whenever-possible-with-react-native-26478ec22334#.8m1k008ip 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.html 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 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/ https://www.shiftyjelly.com/pocketcasts/) for the design inspiration there. Hope that helps!
  - deleted 10y ago
    [deleted]
  - mwcampbell 10y ago
    It seems to me that you're repeating the mistake that caused Java AWT and Swing applications to feel foreign on any mainstream desktop system. https://news.ycombinator.com/item?id=8965349 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.
andrewfong 10y ago
Are there any tutorials or documentation on integrating Expo with a different RN build process? For example, if we have an existing setup with TypeScript or want to use Mocha instead of Jest or whatever.
- brentvatne 10y ago
  Hi there! - This guide from Microsoft explains how to use typescript: http://www.reactnative.tools/tutorials/2016/09/20/reactnative-ts/ 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-native-with-mocha-and-enzyme/ https://formidable.com/blog/2016/02/08/unit-testing-react-na... Hope that helps!
  - vmarsy 10y ago
    Those links are usful, thanks! 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 that just works out of the box and lets you debug in VS Code.
- ccheever 10y ago
  Hey! Some people have set up some stuff for doing ClojureScript with Expo. https://docs.expo.io/versions/v14.0.0/guides/using-clojurescript.html 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/ 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-other-build-processes/33 https://forums.expo.io/t/integration-with-typescript-mocha-o...
  - andrewfong 10y ago
    Thanks! I guess my actual question is -- what are the hook(s) Expo expects from a React Native package? 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/packager 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.
Traubenfuchs 10y ago
Crashed my phone (An infinite amount of "Loading js bundle" popups appeared, creating a solid black background from all the shadows) and then it killed my server (EDIS/waveride vserver -now unreachable from outside, probably some kind of overusage protection). Nice.
- dikaiosune 10y ago
  Hi! Sorry you ran into problems. Was this just using the basic starter project? If you want to include some platform information in a GitHub issue I'd love to look into this.
  - Traubenfuchs 10y ago
    Yes, it was the starter project. 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.
    - dikaiosune 10y ago
      Hi! Sorry for the very late reply, there's been a lot of interest and I haven't had time t get back to everyone yet. 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.
swah 10y ago
Interesting, this probably kills Phonegap now :) :(
baron816 10y ago
What are people's feelings towards React Native vs actual native mobile development these days? Are people starting to get the sense that this is the future and coding in Swift/Objective-C/Java for mobile is dying off?
- traviswingo 10y ago
  Personally, for me, it comes down to trade-offs. How quickly do you want to be able to push changes? Do you want to hire a new developer for mobile, or have an existing developer plug away on the project? Are you building a game, or does your app require very low-level code control? 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.
- santaclaus 10y ago
  Swift and Obj-C are pretty high up in popularity rankings [1], and I imagine a majority of their use cases are mobile. [1] http://www.tiobe.com/tiobe-index/ http://www.tiobe.com/tiobe-index/
- fatbird 10y ago
  Having run through an app building exercise myself, and starting to shepherd coworkers through the same exercise, my feeling about it is the same as it was for earlier platforms (like Appcelerator) that I tried: good for certain classes of application that are mainly built around text, lists, and UI logic; weak for performance demanding areas like games. React native brings a nice dev pipeline to app development and speeds development for a lot of garden variety app development tasks, making it a real advance for prototyping or rapid iteration; it doesn't bring anything that's going to unseat native app development where native is strongest, in drawing intensive tasks. 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.
sprite 10y ago
A bit off topic but how is react native performance compared to native? Lets say you did an Instagram type timeline, would you be able to get the same scrolling performance with RN as going native?
- k_sh 10y ago
  I only do React work (not Native) so I can't definitively say, but I'd imagine it's close to native perf, because React Native spits out native UI components at the end of the day.
- jwarren 10y ago
  I've run into a few problems with lower memory Android devices - even with the optimised ListView components, there were crashes. However, there's a new FlatList[1] component coming in (I hope) 0.43 which is waaay more performant - it's practically solved all of my issues. 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/flatlist.html https://facebook.github.io/react-native/releases/next/docs/f... 2: https://medium.com/@talkol/recycling-rows-for-high-performance-react-native-list-views-628fd0363861#.x98ryoo4t https://medium.com/@talkol/recycling-rows-for-high-performan...
  - sprite 10y ago
    Thanks.
fleshweasel 10y ago
I don't see why there can't be React-like libraries written and used in languages that compile to native. I'm not expecting to have JSX but I should be able to write component classes and implement their render methods, returning view trees written with some kind of object/array literal syntax. 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."
- marcbernstein 10y ago
  To your last point - yes, you can mix your view controllers (or Activity/Fragments on Android) between pure native and React Native implementations.
- jameside 10y ago
  Companies with large, existing apps that want to use React Native definitely share the desires written out in your last paragraph. Facebook has this need in their main app. And at React Conf today, Leland Richardson from Airbnb just gave a talk on using React Native in "brownfield" apps and seamlessly sharing a single navigation controller across React Native root views and UIViewControllers and Android Fragments. The navigation library that helps a lot with this is here: https://github.com/airbnb/native-navigation https://github.com/airbnb/native-navigation
- spicyj 10y ago
  ComponentKit is open source and a lot of the Facebook app is built on it.
rtw1981 10y ago
What is the difference between this and https://facebook.github.io/react-native/docs/getting-started.html#content https://facebook.github.io/react-native/docs/getting-started...
hasenj 10y ago
I started a project in React Native a few months ago, then I left it for a couple weeks, then when I came back to it, I did the usual chore of updating libraries, and found that I could no longer compile/run the project. Purged and re created my npm_modules folder to no avail. Things kept getting worse and I simply have no clue what is going on. Started a fresh RN project and even that would not run. I got the feeling that it's layers upon layers of leaky abstractions and the whole thing seems rather fragile.
- lohengramm 10y ago
  I felt that way using React itself (for the web) - it was like writing code upon so many layers I didn't have control to fix eventual hairy bugs anymore. So I didn't even try Native.
  - spicyj 10y ago
    Were you using many other libraries? We try to keep React itself pretty simple and recommend you start with that.
    - lohengramm 10y ago
      I am probably blaming React for more than it's responsible for, but I feel that, in a real world project, it's rather difficult to not fall into that zone where you have webpack, several loaders and complex configurations for different environments, babel with plugins/presets, gulp, redux or something equivalent, strange directory structures because all libraries purposely try to avoid being associated with bad old big frameworks thus giving too much freedom for the programmer to be "creative" when organizing his code, node for SSR (and then taking care for everything to also work on the server), css modules, react wrappers crashing because wrapped libs were originally written with dom manipulation in mind etc. You know the list can go on, the last time I remember my package.json had around 50 direct dependencies, and it is possible to justify every one of them. All that to write magic JS code that imports assets, transforms them, output obscure css classes and a client.js file that eventually print some crazy warnings on line 53777 column 838383937. 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.
sAbakumoff 10y ago
What is it with React Native? HN's front page today: 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)
- idointernet 10y ago
  react conference was today
intrasight 10y ago
Serious question: Isn't React Native just a short-term fix while we wait for WASM?
- johncolanduoni 10y ago
  If you mean you'll write something in a language with a C-ish ontology (C, C++, Swift, Rust, etc.), WASM won't help you much because you can already compile these languages for both platforms and interact via bindings; WASM won't buy you anything except for mandatory interpreter overhead on iOS. If you mean a GC-ed language like JS or Java, WASM doesn't yet have native GC and likely wouldn't be much better than JavaScript as a compiler target for these languages even if/when it does. 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.
  - intrasight 10y ago
    >WASM solves a totally orthogonal problem 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.
    - johncolanduoni 10y ago
      What do you mean by native hardware? WASM's only goal is to expose some "hardware" in the CPU itself, all of whitch is already available to (and mostly used by) the existing JavaScript engines. Anything that goes through a driver has nothing to do with WASM; its specification explicitly does not define any APIs that WASM code can access at all. 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.
- deleted 10y ago
kikimora 10y ago
First of all - I enjoy using React in browser and consider it the best browser UI tech out there. At the same time I've been working with desktop and mobile apps for past 12 years and there are things that makes me very suspicious about React Native. 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-performance-react-native-list-views-628fd0363861#.so16r6s9j 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-native-develop-new-consumer-app/ https://www.techatbloomberg.com/blog/bloomberg-used-react-na... - Customers rate it one star - https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8 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.
kikimora 10y ago
First of all - I enjoy using React in browser and consider it the best browser UI tech out there. At the same time I've been working with desktop and mobile apps for past 12 years and there are things that makes me very suspicious about React Native. 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-performance-react-native-list-views-628fd0363861#.so16r6s9j 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-native-develop-new-consumer-app/ https://www.techatbloomberg.com/blog/bloomberg-used-react-na... - Customers rate it one star - https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8 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.

535 points by anp 10y ago

Has the Android side improved with React Native? The last time I took a look at this which was last year, the consensus was the Android result wasn't optimal.

lacker 10y ago
There's a ton of work going into polishing many different parts of React Native right now. So "the Android experience" has definitely improved overall. But it probably depends on what specifically you were running into last year that was frustrating during Android development?
pgm8705 10y ago
I have an Android app in production that works as well as its ios counterpart. Launched it in the fall of 2016.
buckhx 10y ago
We're pushing one out in the next few weeks. Haven't ran into any dealbreakers. Ours is fairly basic displaying info from an API so YMMV.
deleted 10y ago
[deleted]

donjh 10y ago

Create React App was a great addition to the React ecosystem and definitely made the library more approachable. Excited to check this out!

dikaiosune 10y ago

Hi! I wrote a bunch of the code for CRNA (although it obviously builds on a lot of great work from Facebook and Expo people). Happy to answer questions. 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 http://conf.reactjs.org/livestream.

ChrisBland 10y ago
No questions, simply saying Thanks! I've been trying to show people RN and this will make it super easy to introduce it to them. Know a lot of work in the OS community is under-appreciated, so great work & thanks!
jondot 10y ago
Brilliant!
ChicagoBoy11 10y ago
I remember buying a Mac in college because I was finally going to get into Native development!! Well, that was almost 10 years ago and after many false starts it just never happened... seemed like such an insurmountable amount of cruft for even the most mundane things. 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!
- sorenbs 10y ago
  I'm a fairly experienced backend and web developer. My first experience with RN was exactly this. 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.
  - sorenbs 10y ago
    Btw, GraphQL and React Native / Expo is a great combo https://www.learnapollo.com/tutorial-react-native-vanilla/rnv-01 https://www.learnapollo.com/tutorial-react-native-vanilla/rn...

Kiro 10y ago

Is there any reason to use this rather than "New Project" in the XDE if you're already an Expo user?

dikaiosune 10y ago
Probably not. One of the biggest advantages of CRNA is that we built it from the ground up to not require integrating with Expo's accounts or services. If you've already opted-in to those services, then you're probably getting what CRNA offers plus a little extra. 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.

eeeze 10y ago

Thanks for the great work on it! Will definitely check it out. 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?

dikaiosune 10y ago
The biggest advantages of CRNA right now are: * 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.

ourcat 10y ago

Didn't Apple start rejecting apps recently which do 'hot code' pushes to update apps remotely? (As the video on the Expo.io site says)

nuggien 10y ago
I think it was just apps that pushed updates for native code, and javascript updates are still fine (for now).
benhoyt 10y ago
I believe that was only for apps that could talk to Objective C API's natively, in other words, essentially bypassing the native code review process. React Native can only do hot updates of JavaScript (which may call existing Objective C API wrappers, but not create new ones).
- LeoNatan25 10y ago
  It's exactly the same in the case of Rollout, they were also only updating JS using JavaScriptCore, not using new native APIs.
  - jameside 10y ago
    Rollout exposes arbitrary Objective-C APIs to JavaScript (likely using Objective-C's reflection capabilities), while React Native and Ionic/Cordova WebViews require you to explicitly bridge your own native methods. That was one of the key differences in Apple's concern.
    - LeoNatan25 10y ago
      Implementations already exist, such as react-native-invoke, that enable similar functionality. The jump from "need to explicitly bridge" and "explicitly bridge the runtime API" is very small, opening the possibility of exactly the same features as Rollout. 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-from-pure-javascript-in-react-native-1fb6afcdf57d#.60pyo15vg 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.

RubenSandwich 10y ago

I'm a bit unsure about this decision. Because this is tying React Native to a private entity, namely Expo, that has not open sourced it's toolchain used here. Expo takes your code and builds it on their servers and then serves it to you. That toolchain unlike React Native is not open source. This is creating a walled garden around Expo who can easily decide to charge for their server fees. Yes it is a much easier of an boarding experience then installing Xcode and Android Studio but at least with Xcode and Android Studio you own the whole toolchain. Because of this fact I don't think this is comparable to React Create App, which is excellent. 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.

dikaiosune 10y ago
Hi! Expo is definitely a private entity, but the tools used by CRNA are also definitely open source: https://github.com/exponent/exponent https://github.com/exponent/exponent https://github.com/exponent/exponent-sdk https://github.com/exponent/exponent-sdk https://github.com/exponent/xdl 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.
- RubenSandwich 10y ago
  What about the build server?
  - dikaiosune 10y ago
    Which build server? If you have an Expo account you can create a "standalone app" with our service, but that's not a part of CRNA's workflow and it's certainly not required to use this tool.

hypercluster 10y ago

Always interesting to see how cross platform is evolving (this and also Xamarin update recently), wonder how the Google and Apple regard this. Anyway, I just tried out the Expo App on iOS and noticed that the back swipe animation does not seem to be native in the examples. Is there a reason for that? (that's something I always try out of I want to check if an app is native).

brentvatne 10y ago
Hello! 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-javascript-whenever-possible-with-react-native-26478ec22334#.8m1k008ip 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.html 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 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/ https://www.shiftyjelly.com/pocketcasts/) for the design inspiration there. Hope that helps!
- deleted 10y ago
  [deleted]
- mwcampbell 10y ago
  It seems to me that you're repeating the mistake that caused Java AWT and Swing applications to feel foreign on any mainstream desktop system. https://news.ycombinator.com/item?id=8965349 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.

andrewfong 10y ago

Are there any tutorials or documentation on integrating Expo with a different RN build process? For example, if we have an existing setup with TypeScript or want to use Mocha instead of Jest or whatever.

brentvatne 10y ago
Hi there! - This guide from Microsoft explains how to use typescript: http://www.reactnative.tools/tutorials/2016/09/20/reactnative-ts/ 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-native-with-mocha-and-enzyme/ https://formidable.com/blog/2016/02/08/unit-testing-react-na... Hope that helps!
- vmarsy 10y ago
  Those links are usful, thanks! 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 that just works out of the box and lets you debug in VS Code.
ccheever 10y ago
Hey! Some people have set up some stuff for doing ClojureScript with Expo. https://docs.expo.io/versions/v14.0.0/guides/using-clojurescript.html 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/ 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-other-build-processes/33 https://forums.expo.io/t/integration-with-typescript-mocha-o...
- andrewfong 10y ago
  Thanks! I guess my actual question is -- what are the hook(s) Expo expects from a React Native package? 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/packager 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.

Traubenfuchs 10y ago

Crashed my phone (An infinite amount of "Loading js bundle" popups appeared, creating a solid black background from all the shadows) and then it killed my server (EDIS/waveride vserver -now unreachable from outside, probably some kind of overusage protection). Nice.

dikaiosune 10y ago
Hi! Sorry you ran into problems. Was this just using the basic starter project? If you want to include some platform information in a GitHub issue I'd love to look into this.
- Traubenfuchs 10y ago
  Yes, it was the starter project. 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.
  - dikaiosune 10y ago
    Hi! Sorry for the very late reply, there's been a lot of interest and I haven't had time t get back to everyone yet. 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.

swah 10y ago

Interesting, this probably kills Phonegap now :) :(

baron816 10y ago

What are people's feelings towards React Native vs actual native mobile development these days? Are people starting to get the sense that this is the future and coding in Swift/Objective-C/Java for mobile is dying off?

traviswingo 10y ago
Personally, for me, it comes down to trade-offs. How quickly do you want to be able to push changes? Do you want to hire a new developer for mobile, or have an existing developer plug away on the project? Are you building a game, or does your app require very low-level code control? 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.
santaclaus 10y ago
Swift and Obj-C are pretty high up in popularity rankings [1], and I imagine a majority of their use cases are mobile. [1] http://www.tiobe.com/tiobe-index/ http://www.tiobe.com/tiobe-index/
fatbird 10y ago
Having run through an app building exercise myself, and starting to shepherd coworkers through the same exercise, my feeling about it is the same as it was for earlier platforms (like Appcelerator) that I tried: good for certain classes of application that are mainly built around text, lists, and UI logic; weak for performance demanding areas like games. React native brings a nice dev pipeline to app development and speeds development for a lot of garden variety app development tasks, making it a real advance for prototyping or rapid iteration; it doesn't bring anything that's going to unseat native app development where native is strongest, in drawing intensive tasks. 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.

sprite 10y ago

A bit off topic but how is react native performance compared to native? Lets say you did an Instagram type timeline, would you be able to get the same scrolling performance with RN as going native?

k_sh 10y ago
I only do React work (not Native) so I can't definitively say, but I'd imagine it's close to native perf, because React Native spits out native UI components at the end of the day.
jwarren 10y ago
I've run into a few problems with lower memory Android devices - even with the optimised ListView components, there were crashes. However, there's a new FlatList[1] component coming in (I hope) 0.43 which is waaay more performant - it's practically solved all of my issues. 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/flatlist.html https://facebook.github.io/react-native/releases/next/docs/f... 2: https://medium.com/@talkol/recycling-rows-for-high-performance-react-native-list-views-628fd0363861#.x98ryoo4t https://medium.com/@talkol/recycling-rows-for-high-performan...
- sprite 10y ago
  Thanks.

fleshweasel 10y ago

I don't see why there can't be React-like libraries written and used in languages that compile to native. I'm not expecting to have JSX but I should be able to write component classes and implement their render methods, returning view trees written with some kind of object/array literal syntax. 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."

marcbernstein 10y ago
To your last point - yes, you can mix your view controllers (or Activity/Fragments on Android) between pure native and React Native implementations.
jameside 10y ago
Companies with large, existing apps that want to use React Native definitely share the desires written out in your last paragraph. Facebook has this need in their main app. And at React Conf today, Leland Richardson from Airbnb just gave a talk on using React Native in "brownfield" apps and seamlessly sharing a single navigation controller across React Native root views and UIViewControllers and Android Fragments. The navigation library that helps a lot with this is here: https://github.com/airbnb/native-navigation https://github.com/airbnb/native-navigation
spicyj 10y ago
ComponentKit is open source and a lot of the Facebook app is built on it.

rtw1981 10y ago

What is the difference between this and https://facebook.github.io/react-native/docs/getting-started.html#content https://facebook.github.io/react-native/docs/getting-started...

hasenj 10y ago

I started a project in React Native a few months ago, then I left it for a couple weeks, then when I came back to it, I did the usual chore of updating libraries, and found that I could no longer compile/run the project. Purged and re created my npm_modules folder to no avail. Things kept getting worse and I simply have no clue what is going on. Started a fresh RN project and even that would not run. I got the feeling that it's layers upon layers of leaky abstractions and the whole thing seems rather fragile.

lohengramm 10y ago
I felt that way using React itself (for the web) - it was like writing code upon so many layers I didn't have control to fix eventual hairy bugs anymore. So I didn't even try Native.
- spicyj 10y ago
  Were you using many other libraries? We try to keep React itself pretty simple and recommend you start with that.
  - lohengramm 10y ago
    I am probably blaming React for more than it's responsible for, but I feel that, in a real world project, it's rather difficult to not fall into that zone where you have webpack, several loaders and complex configurations for different environments, babel with plugins/presets, gulp, redux or something equivalent, strange directory structures because all libraries purposely try to avoid being associated with bad old big frameworks thus giving too much freedom for the programmer to be "creative" when organizing his code, node for SSR (and then taking care for everything to also work on the server), css modules, react wrappers crashing because wrapped libs were originally written with dom manipulation in mind etc. You know the list can go on, the last time I remember my package.json had around 50 direct dependencies, and it is possible to justify every one of them. All that to write magic JS code that imports assets, transforms them, output obscure css classes and a client.js file that eventually print some crazy warnings on line 53777 column 838383937. 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.

sAbakumoff 10y ago

What is it with React Native? HN's front page today: 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)

idointernet 10y ago
react conference was today

intrasight 10y ago

Serious question: Isn't React Native just a short-term fix while we wait for WASM?

johncolanduoni 10y ago
If you mean you'll write something in a language with a C-ish ontology (C, C++, Swift, Rust, etc.), WASM won't help you much because you can already compile these languages for both platforms and interact via bindings; WASM won't buy you anything except for mandatory interpreter overhead on iOS. If you mean a GC-ed language like JS or Java, WASM doesn't yet have native GC and likely wouldn't be much better than JavaScript as a compiler target for these languages even if/when it does. 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.
- intrasight 10y ago
  >WASM solves a totally orthogonal problem 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.
  - johncolanduoni 10y ago
    What do you mean by native hardware? WASM's only goal is to expose some "hardware" in the CPU itself, all of whitch is already available to (and mostly used by) the existing JavaScript engines. Anything that goes through a driver has nothing to do with WASM; its specification explicitly does not define any APIs that WASM code can access at all. 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.
deleted 10y ago

kikimora 10y ago

First of all - I enjoy using React in browser and consider it the best browser UI tech out there. At the same time I've been working with desktop and mobile apps for past 12 years and there are things that makes me very suspicious about React Native. 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-performance-react-native-list-views-628fd0363861#.so16r6s9j 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-native-develop-new-consumer-app/ https://www.techatbloomberg.com/blog/bloomberg-used-react-na... - Customers rate it one star - https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8 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.

kikimora 10y ago

First of all - I enjoy using React in browser and consider it the best browser UI tech out there. At the same time I've been working with desktop and mobile apps for past 12 years and there are things that makes me very suspicious about React Native. 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-performance-react-native-list-views-628fd0363861#.so16r6s9j 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-native-develop-new-consumer-app/ https://www.techatbloomberg.com/blog/bloomberg-used-react-na... - Customers rate it one star - https://itunes.apple.com/us/app/bloomberg/id281941097?mt=8 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.