I am not sure if this is specific to React Native. In a regular Android application, this information is available in the JSON file. Having permissive credentials on the client is a security gap, no matter the technology.
As someone who manages a team at a large corp that uses react native and ships a successful project things have definitely changed. It feels like Facebook has lost interest.
- the android debugger has been broken for months (it opens to the wrong url, delta patches also broke source maps). No one at Facebook cares. Do they not use the debugger?
- pull requests have stopped being merged. We have FIVE outstanding pull requests fixing bugs as old as ones ignored by Facebook from 2016. No one will reply or merge them anymore. We've been told to just create a fork on GitHub for our project. Apparently that's what every serious RN user does because Facebook doesn't really care about it anymore.
- they have a bot who auto closes bugs somewhat randomly. For example an old bug that Facebook ignored with hundreds of comments gets closed for "inactivity", but it's not active because folks all complained and now they're just waiting for someone to fix it.
So it all combines to a situation where the platform is buggy, but you can't get fixes merged, and filing bugs is largely a waste of time since all it gets is auto replies from the bot and "me too" responses from others.
We really like RN, it helped us ship fast at first, but Facebook absolutely seems to have lost interest in it and in having a community around it.
I’m sorry it’s frustrating but it’s not at all because FB lost interest. In fact it’s the opposite. We’re making pretty big bets on complex core architectural improvements to RN, and the team is heads down busy with these core changes. Unfortunately it does mean that PRs and external contributions get less attention until those core improvements are done.
If there’s a specific PR that’s blocking you please ping me in DM on Twitter and I’ll try to get somebody to review it.
We’ll post more when it’s closer to being production-ready. But TLDR is that we’re making improvements to the threading model and interop with native code.
I understand what you are saying, since I too am upset about many issues being closed without being fixed. I come across them when doing searches for various problems with RN. It's the same with Flow, the Javascript type checker, only that there it seems like nobody from the dev team even cares about the Github repo and the huge list of open issues (hey, at least they don't close them all automatically by bot).
I think the commit history says more than (auto-)closed issues. They may not share our priorities but they keep working on the project pretty actively.
> On the documentation
The document is not abandoned. Infact, we are actively working on fixing the document and reaching out to the community to identify gaps in documentation and fixing them. We are also moving docs to a separate repo to make sure that they are easy to contribute to.
> On Typed languages.
A lot of people use React Native with Flow or TypeScript, and are able to benefit from type systems.
How are you measuring those metrics on real devices ? Do you use the Chrome tracing timeline ? I wrote a tool called http://github.com/axemclion/browser-perf that does something similar, so was curious !!
Can it call arbitrary native code? I think that's our probably going to be an issue if it can (I.e. If it can do loadFramework("baz").getClass("foo").callMethod("bar"))
PM on the CodePush team here. The rejection notice seems to explicitly call out the native methods that are a cause of the issue. CodePush cannot inject private frameworks or expose any methods that React Native already exposes.
I would also recommend not using CodePush to completely what an app does.
Correct me if I am totally wrong here, but isn't the issue not with introducing new private frameworks or exposing new methods but with changing the behavior of the interpreted code that interacts with already exposed frameworks/methods? The relevant language seems to suggest that you could still be in violation of Apple's TOS if your script(s):
>change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
CodePush will also be integrated into Mobile Center, so that you can also making CodePush a part of your CI process.
We are also working on adding support for Authentication, storage, testing and Push notifications.
[I am the PM on CodePush and React Native Mobile Center stuff]
You should be able to use Mobile Center and CodePush separately today. We are planning to incrementally roll out a backward compatible solution over the next 2 months.
