re: react-navigation, I am one of the two primary maintainers of this project and I started working on it in January of this year because it was in a pretty rough state. I think it has come a long way in that time even though there is still plenty to do. I would love to hear what simple things have taken hours for you when using it, feel free to reach out on Twitter in DM @notbrent or email brent at expo dot io. Also, the roadmap for our next major version is here: https://github.com/react-navigation/react-navigation/issues/....
Short summary is, well, the drawer is all sorts of weird. How the drawer interacts with everything else is also kind of weird. How to open a drawer with a NavigatorService is not something I could find documented outside of Github, and the comment there was old and what was suggested didn't work.
I have also seen people post suggestions on how to use the library that are just flat out wrong. Suggesting using props that don't exist (!!!???), and I've seen at least three recommendations of how to do lazy loading. Now that the docs are better these issues are going to go away, but unfortunately old blog posts (and github threads) live on.
Speaking of the documentation, it has gotten 10x better over the last few months. It has a ways to go, and pictures would be super nice. The React Native community likes to post Expo apps to showcase APIs instead of having super robust examples in the docs, I get why (and sample apps can be super useful!), but sometimes a "this option results in this" doc is super useful.
When I was first learning the library, some of the documentations labeled navigationOptions, some of them didn't and just passed it in positionally. It looks like the docs have been cleaned up, hopefully other examples around the web do the same thing. When I was trying to learn the API, this was very confusing, but I think if I had to learn it from scratch today, it would be a lot easier.
(If Steven Girder hasn't updated his examples, ask him to! His RN course is insanely popular and introduces a lot of people to React-Navigation)
So I guess saying it is bad isn't correct, but up until very recently, doing anything with the library was an effort in frustration just because of the documentation.
I'm still going to DM you some questions about the drawer though! :) (Update: answered, I was doing some things wrong, and Drawer is being rewritten to make more sense!)
I can't speak to the original intentions of the authors, but I suspect it might be related to difficulty of making significant changes to the project due to some strongly held beliefs.
An example: react-native depends on alpha/beta versions of react, and libraries in the react-native ecosystem tend to include a peer dependency on react (eg: react >= 15). React 16.0.0-alpha.12 will not satisfy this range, but 16.0.0 will. It's unclear to me in what way it is useful to exclude pre-release versions, and this causes a lot of confusion for users. I posted about it here: https://github.com/npm/npm/issues/8854 and it was shutdown for ideological reasons, rather than practical considerations. On the other hand, someone submitted a patch to yarn to improve this behaviour and it was quickly accepted: https://github.com/yarnpkg/yarn/pull/3361.
And it wasn't all just "strongly held beliefs" there were very real problems with upgrading parts of npm.
npm for a long time was built to do what npm did. There was no spec, no "rules" it did what it did, and changing that behavior was a breaking change. Everyone could agree that feature X needed to be fixed or redone, but doing so would break a significant number of packages/projects so it wasn't done.
Yarn was the solution, they could start from scratch, not worry about those older/undocumented/arcane edge-cases. They didn't have to care about backwards compatibility, or even reimplement the same API.
Every time this question is asked, I also like to point out that many of the Yarn devs were npm devs, and the project as a whole not only had the "approval" of npm, but also was in-part encouraged by them.
Competition is good, and it's "the javascript way" to have multiple competing tools that each prioritise different things. Yarn is pretty much a perfect example of that.
repl.it integrates this with their classrooms product to make it into a structured learning tool with assignments and automatic evaluation of solutions. Direct link to the course: https://repl.it/community/classrooms/17650
Here's a fun example of a pretty common UI pattern -- the header transitions into another as you scroll, and the hero image scales / fades depending on scroll position too: https://sketch.expo.io/SyVvB3Hjx -- it uses React Native's native animated driver with ScrollViews :)
Sketch, create-react-native-app and React Native Express are a great combo I think ;)
(for people who aren't aware of it, React Native Express is a fantastic site for getting your bearings with React Native: http://www.reactnativeexpress.com/)
I'm confused what the point of your comment is. If you can do it natively you can do it with React Native. "The jump" for any app from not including Rollout-style invocations to including them is the same if it's a React Native app or a normal native app, and these can all be determined by static analysis by Apple during the review process.
The point is, saying "RN apps only push JS" is disingenuous. The exact same technology is used to push JS, and that JS can do things that Apple does not like, RN or not. It appears everyone working in the RN ecosystem is hellbent to distance themselves from Rollout, but the gap is very small between the two technologies.
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:
