frostik

Layout: It's the main reason to go all in with RN. You're much faster building these with RN then using native stuff.

Infinite Scrolling: ListViews and RN are a thing. There's a new List Type since a few Versions - if you're following the book regarding DataStrucure everything should work.

REST Client: RN provides basic API so nearly everything which works in Browser works in RN too. I use Redux Sagas and fetch. Working great so far.

Image Handling: It's built on top of fresco and works great so far.

Push: Can't say mush about it, because i don't use it but should work ok.

In-App: There's a great Plugin.

Animation: Native Animations are around for some time. Should work ok, but depends what you're planning to do.

Basically it's extremely easy to go native if necessary. But at that point you need to implement it on every platform. Even though for usual use cases it shouldn't be necessary. You just need to keep Track of your renderings and make sure you use PureComponents at the right point, so there are no unnecessary rerenders congesting the bridge and slowing everything down. But if you do it right you will achieve performance and an feature level that is on par with every native development in less time. And with 95% Code Share.

Just a wild guess - you said opening for processing. Depending on what you're doing with the file and how you're opening it the whole data get's passed over the bridge resulting in some catastrophic memory allocations. I would recommend tapping into the bridge communication and start checking if everything stays where it should. Some picker modules tend to send base64 encoded file beside the URL.

Yes, but means that you need to implement map, foreach, filter yourself. So you might be better off with lodash.

There's a huge gotcha: _.map, _.forech, ... can iterate over objects (often used as associative arrays) - Native map can't.

At some point you'll need lodash and co again - at least for convinience.