[META] Upgrading JSC

[kelset]

The purpose of this issue is to create a "single point of truth" regarding the efforts related to upgrading the JSC used by the react-native repo/project, in order to coordinate and recap all the efforts connected to this subject.

Foreword

The JavaScriptCore (JSC), basically, allows Android developers to use JavaScript natively in their apps - you can read here for more details about how react native uses engines.

Currently, react-native bundles in the Android app android-jsc, which is outdated and relies on old native tooling (ex. NDK v10).

Why

Upgrading the JSC would improve greatly performances for react-native apps running on Android, and allow support for x64 builds on Android apps.

Which links back this to the main "Roadmap of future Android(s)" issue #19297 - quote:

In anticipation of future Android devices that support 64-bit code only, the Play Console will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions. This can be within a single APK or as one of the multiple APKs published.

Related

PRs

Currently there are two approaches possible, keep relying on the android-jsc bundled but changing some other configs:

• [WIP] Android 64-bit [WIP] Android 64-bit #17640

• add arm64 and x86_64 support add x86_64 arm64-v8a support. Fixes #2814 #18754

Which seems to not be the way to go, given that internally FB doesn't use it.

The alternative is to move to the JSC fork maintained by some important players in the core & community:

• Build 64bit binaries for Android Build 64bit binaries for Android #19536

Issues

• React Native for Android is incompatible with 3rd-party 64-bit libraries Support third-party 64-bit libraries on Android #2814

• [...Array(5).keys()] not working in Android [...Array(5).keys()] not working in Android #18426

• React Native apps fail to build since NDK update to r17 (due to removed support for ARMv5/armeabi) React Native apps fail to build since NDK update to r17 (due to removed support for ARMv5/armeabi) #19321

• potentially (as @kmagiera wrote in core), this unfortunately would bring some significant footprint penalty: JSC built with intl enabled takes roughly 5M more than without it. This needs to be multiplied by the number of CPU archs included (e.g. x86, armv7, arm64, x86_64), which leads to an "Hello World" base app to ~40MBs - unless split apk is enabled. But this it potentially "automatically" fixed by Google via their new Android App Bundle feature.

---

Again, this issue is for discussing and keeping everyone updated with decisions around this subject (based on discussions happened with the core team and open issues in the repo). Please avoid going OT.

[newyankeecodeshop]

Great job creating a centralized issue for this @kelset .
The question of whether to include Intl support is a good one. The JavaScriptCore on iOS 10.0+ has Intl support, so it would be good for consistency to have the Android one include it as well. However I can see how the increase in the binary size makes that problematic.

[LegNeato]

I believe you are mistaken...the "FB doesn't use it internally" appears to be referring to the updated SoftwareMansion JSC. That is, FB doesn't want to push an updated JSC to open source that they don't use internally, and the one they use internally is android-jsc. At least, that's how I read it.

Re: newer JavaScriptCore, I would imagine it is basically a non-starter to update JSC past the version shipped by the RN minimum supported iOS version...otherwise one could use JS features on Android that don't work on some subset of iOS devices and cause all sorts of annoying, hard to debug issues.

[LegNeato]

FWIW, I have patches out for both the two issues in Buck blocking RN:

For "React Native for Android is incompatible with 3rd-party 64-bit libraries": facebook/buck#1889
For "React Native apps fail to build since NDK update to r17 ": facebook/buck#1894

[gengjiawen]

I prefer #19536. Also with this I think we can reconfig babel to generate modern js. @rafeca

[gengjiawen]

For app bundle size, x86 and x86_64 should not bundled to the apk when you push the apk to market. Because real phone are using arm cpu.

[hey99xx]

@gengjiawen You can find X86 devices out in the market but they're so much rarer, especially in modern Android versions. It's mostly ignorable, my company only uses it for emulator builds.

[gengjiawen]

Yes, ignorable is the precise desription.

[hramos]

@LegNeato we're not using either JSC at Facebook, therefore there's no reason to force OSS to use android-jsc and we're happy to help unblock folks here.

[LegNeato]

Good to know...but, it would be weird if the JSC of react native was newer than the minimum iOS version's JSC, right? Then you would have Android and modern iOS working, and older iOS devices degrading in quality and compatibility. But perhaps that's ok?

[hey99xx]

we're not using either JSC at Facebook

Wait, what are you guys using as the alternative then?

[hramos]

@hey99xx I can't answer that just yet, but hopefully soon we can share more information. Let's keep this issue scoped to what needs to be done to allow open source to use an arbitrary JSC.