Do you have anything to back that up?

Run some lists with images on them on iPhone 5. Anecdotal, and I am sure you can dig into metal to improve performance, but out of the box, it's kinda poor. I still like React and I'm hopeful React-Native will improve.

Thanks. I wonder how much of that is due to the fact that JavaScriptCore can't use JIT compilation when running in an iOS application other than Safari.

As of iOS 8 that's no longer the case. JSC JIT compilation can be used in native apps. (It's also used by WKWebView.)

http://trac.webkit.org/wiki/JavaScriptCore

"JavaScriptCore is an optimizing virtual machine. JavaScriptCore consists of the following building blocks: lexer, parser, start-up interpreter (LLInt), baseline JIT, a low-latency optimizing JIT (DFG), and a high-throughput optimizing JIT (FTL)."

Apps can use JavaScriptCore, and JavaScriptCore can use JIT, but these can't happen together, because third-party apps aren't permitted to execute writeable memory.

http://stackoverflow.com/questions/22281265/is-javascriptcor...

This is good to know. Looks like the only way to make use of JIT (by someone who isn't Apple) is to use a WKWebView to execute the JS.

This has been false for years.

I haven't used React Native, but I've done quite a bit with native bridging with JavaScriptCore and v8. If your performance bottlenecks are crossing the Javascript-to-native boundary, JIT can't help you. And crossing the bridge boundary isn't the cheapest operation.

That isn't an issue with React Native, which runs JS on its own thread and implements an asynchronous, batched bridge between JS and native.