Road to 0.70.0

[dmytrorykun]

2022-09-05 Update

React Native version 0.70.0 has been released (0.70.0-rc.4 has been promoted to stable) 🎉
Conversation about the patch version of 0.70.1 is happening here

The branch cut has happened.

Notice

• Current release candidate: 0.70.0-rc.4
• Have an issue with current release candidate? File an issue and we will triage.
• Have a pick request for this release? Does it fall under our pick request qualifications? If so please create a PR against the release branch and comment with the PR link
• If you are release testing, copy and fill a test checklist.

Highlighted Changes in this release

• Autolinking on Android for New Architecture (TM) libraries
• Hermes is ON by default on new apps
• Fix for Catalyst is live, set mac_catalyst_enabled to true in Podfile (see upgrade-helper diff for details)
• Removed jest/preprocessor from the react-native package
• full CMake support for Android builds. (read more here)
• Bumping metro to 0.72.0 should enable the "new" react jsx transform: reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html
• new codegenConfig setup - read more here
• new architecture new docs https://reactnative.dev/docs/next/the-new-architecture/landing-page
• Removing reactnativeutilsjni as it is built from the same sources as reactnativejni Removing reactnativeutilsjni as it is built from the same sources as reactnativejni facebook/react-native#34339
• For more, checkout the Changelog PR

Release Process

Content Checklist

• Changelog PR
• Start a Google doc of blog post for release (start from this skeleton) and invite contributors of release highlights to expand
• Make PR to react-native-website with the new version cut (see docs)
• Prepare typescript PR: [react-native] Bump main to 0.70 and move 0.69 to dedicated folder DefinitelyTyped/DefinitelyTyped#61822
• Follow up on release dependencies

  When ready to publish stable

• Ship changelog [chore] add changelog for 0.70 facebook/react-native#34202
• Ship new docs Generate 0.70 version of the docs facebook/react-native-website#3264
• Ship blog post

Retrospective Topics

• how do we create a better feedback loop / communication channel for library maintainers to make sure they'll support the new version in time for release?

Release Status

Tracking 0.70.0-rc.5

(will likely be not be released, and we'll move to 0.70.0)

Blocking issues for releasing 0.70.0-rc.5

Picks for 0.70.0-rc.5

Tracking 0.70.0-rc.4 (released ✅)

Blocking issues for releasing 0.70.0-rc.4

• (optional) [RN 0.70.0-rc.2] React Native Lottie - function getModule: assertion failed (moduleAsValue.isObject()) facebook/react-native#34372
• (optional) Road to 0.70.0 #26 (comment)
• (need to verify) Road to 0.70.0 #26 (comment)
• Road to 0.70.0 #26 (comment)

Picks for 0.70.0-rc.4

• facebook/react-native@dba6d56
• new release of CLI v9 to stable, and bump Upgrade RN CLI to v9.0.0 and Metro to 0.72.1 facebook/react-native#34447
• new release of Hermes, see comment - (done ✅) - facebook/react-native@0b4b777
• Update template to gitignore android/app/.cxx facebook/react-native#34430
• Fix codegen trying to parse .d.ts files facebook/react-native#34439
• facebook/react-native@50b1270

Tracking 0.70.0-rc.3 (released ✅)

Blocking issues for releasing 0.70.0-rc.3

• (optional) Road to 0.70.0 #26 (comment)
• (optional) [RN 0.70.0-rc.2] React Native Lottie - function getModule: assertion failed (moduleAsValue.isObject()) facebook/react-native#34372
• (optional) Road to 0.70.0 #26 (comment)

Picks for 0.70.0-rc.3

• facebook/react-native@7fcdb9d (will require gradle-plugin release)
• Do not glob node_modules in findComponentDescriptors react-native-community/cli#1670
  • facebook/react-native@7e580b9
• fix: react android kotlin plugin version conflict facebook/react-native#34255
• facebook/react-native@7a911e0
• facebook/react-native@dfd7f70
• Silence deprecation warning for react-native dependency. facebook/react-native#34368
• facebook/react-native@521011d

Tracking 0.70.0-rc.2 (released ✅)

#### Blocking issues for releasing 0.70.0-rc.2

Picks for 0.70.0-rc.2

• facebook/react-native@1ce23ce
• [android] Do not separate autolinked libraries with \ on CMake react-native-community/cli#1661
• Changes that will require a bump of react-native-gradle-plugin:
  • Make sure *.ts files are considered for task avoidance in the Gradle Plugin facebook/react-native#34296
  • Improve package.json search mechanism for codegenConfig support facebook/react-native#34298
  • Introduce findPackageJsonFile to address issue with GenerateCodegenArtifactsTaskTest facebook/react-native#34321
• facebook/react-native@6f76122 (this will require a new react-native-gradle-plugin release)
• facebook/react-native@44ded6b
  • will need a new CLI bump after this is merged: breaking: Upgrade metro dependencies to 0.72.0 react-native-community/cli#1665
  • chore: upgrade RN CLI to v9.0.0-alpha.9 facebook/react-native#34322
• (post-install change with CTA for testing)

Tracking 0.70.0-rc.1 (released ✅)

#### Blocking issues for releasing 0.70.0-rc.1

Picks for 0.70.0-rc.1

• facebook/react-native@a22f30d
• Fix hermes executor not available when use_frameworks is enabled facebook/react-native#34222
• #34214 for main facebook/react-native#34271
• facebook/react-native@b9adf2d
• [eslint-plugin-specs] fix npm lifecycle hook facebook/react-native#34273
• [chore] bump CLI to v9.0.0-alpha.5 facebook/react-native#34275
• facebook/react-native@77752fc
• (bump to new Hermes tag) (done ✅) - facebook/react-native@eb67678

[monholm]

Since I posted about what didn't work regarding hermes on 0.69, I wanna state that:

Successfully initiated a new project and built/ran for both iOS and Android. Also upgraded an existing 0.69.1 project to 0.70-rc.0 without issues. Good job and thank you 👍

[mikehardy]

Does it work with use_frameworks! in the Podfile? I'm currently investigating that comb on iOS and I see 2 issues, global.__jsiExecutorDescription returns HermesEngine without frameworks but returns JSCRuntime with frameworks, and in release mode it crashes at startup. I'm still investigating but I would love confirmation from someone else before investing too much more time in it, to make sure it's not an experiment setup issue on my part. Appears on Intel and M1 Mac for me

[kelset]

Please file an issue - a report like this is not really giving any info we can quickly act on, so it will need a dedicated space that doesn't really fit a Discussion comment

[mikehardy]

Indeed, with current react-native template, version 0.10.3 of soloader is pulled in

Verified with npx react-native init MyAwesomeProject && cd MyAwesomeProject/android && ./gradlew :app:dependencies > dependencies.txt && cat dependencies.txt | grep -i soloader

It looks like the previous soloader bump was just to a versions file, so I proposed the same here: facebook/react-native#34213

[mikehardy]

This has a commit hash to pick now - thanks to Nicola for the merge ! facebook/react-native@b9adf2d

[d4vidi]

Hey thanks @mikehardy for pointing this out here as well! (in addition to the equivalent detox issue)

[kelset]

Given how the author has not been replying to feedback left on 15 Jun 2021 (so, over a year ago) (also, the author last comment is even older, dating back to May 2020) and CI is red, there's no way it can be merged as is. If you want to advance it it's likely easier if you just opened a new PR and implemented it the way the Meta engineers asked.

[dylmye]

Thanks for the reply.

has not been replying to feedback left on 15 Jun 2021

It's worth noting the repo itself was last updated in April of this year with support for 0.68.x.

The only unresolved comment I see from the RN team is this one, and it seems to be more of an explainer than anything. The CI being red is obviously an issue, I'll try and spend some time making a PR, though I might need @ifsnow's permission as there's no licence on the repo or original PR :/

[kelset]

the main piece of feedback I think is this one:

we add an opt-in option to the fix so we can run experimentation around it? That'd help de-risk this change for us as we continue to improve testing and clarify expectations in VirtualizedList's behavior.

[dylmye]

I've continued this discussion on the PR, thanks for the help Lorenzo.

[kelset]

(link: facebook/react-native#34222 )

[Kudo]

the React-bridging pr for main and 0.70: facebook/react-native#34271

[leotm]

great ^ i wasn't sure so commented that part during the upg since on macOS (13b) and Linux, thx again

[cortinico]

Update on:

• [Android] Crash On Startup Using New Arch + Hermes facebook/react-native#34237

The user was on JDK 18 which is not currently supported on React Native.

Also this discussion thread is only for issues on 0.70.0. The second issue needs to be verified but it was reported on 0.69

[leotm]

closed/resolved ^ it works, couldn't repro from npx react-native init RN070RC1 --version 0.70.0-rc.1 adding CI 4 commits later leotm/RN070RC1@f2f070e will figure/fix eventually, betting my big bucks missed smth some point during the upg process since 0.61.5 (it's happened before and was a pita to spot), so frequently glancing back n forth at our template on main

[wwdrew]

Hi @cipolleschi, this is a known issue as referenced in this comment above:

#26 (comment)

[cortinico]

Thanks for the clarification @wwdrew. As mentioned, the issue has already been fixed 👍

[kelset]

good shout!

[leotm]

awesome ^ till now been overriding w @babel/preset-react (incl. @babel/plugin-transform-react-jsx) and runtime: 'automatic', since metro-react-native-babel-preset 0.66ish i think

so will be nice to finally remove this extra Babel config

then think i cleaned up w npx react-codemod update-react-imports followed by Prettier write to do less work

[fortmarek]

The current configuration of the RN template still throws a linter warning as it needs to be turned off as per this. I wonder if it would be a good call to update the template, so new projects no longer have to add import React whenever they want to use JSX?

This can probably be done separately and we can still do a shout-out (although worth explaining the gotchas to make this to work)

[leotm]

yh i did the same, you're right should either add the rule or better bake it in eslint-config-react-native-community, i don't mind following up there separately so can lock here

[kelset]

I'd probably keep it as a "opt-in" thing for 70, maybe we can revisit for 71 to make it on by default. I don't know how widespread is this new approach and I don't want to scare/confuse people off

[kelset]

the AGP bump is already in 0.70; we'll pick the gradle bump

[mikehardy]

Hey all 👋 - I still have pretty low availability to test - so just looking at 0.70.0-rc.2

I'm seeing this with hermes disabled on iOS, with use_frameworks! in Podfile:

❌ /Users/mike/Library/Developer/Xcode/DerivedData/rnfbdemo-dwlryiowautyphccrrwxfbsrbwxk/Build/Products/Debug-iphonesimulator/React-hermes/reacthermes.framework/Headers/HermesExecutorFactory.h:10:10: 'hermes/hermes.h' file not found
#include <hermes/hermes.h>
         ^~~~~~~~~~~~~~~~~

🤔

Reproduction of my "playing with 0.70" branch here:, run ./make-demo.sh

https://github.com/mikehardy/rnfbdemo/tree/rn0.70

[cipolleschi]

Given that this whole block is triggered only when RCT_USE_HERMES is not defined, isn't it easier if we add a couple of lines in the react_native_pods?

We can create a function:

def react_native_use_frameworks!
  use_frameworks!
  RCT_USE_HERMES = 0
end

Even better, if we can deduct whether use_framework! has been invoked by querying something with Cocoapods API, so this is transparent to the final user.

What do you think?

[dmytrorykun]

This error goes away if I delete DerivedData/RNTesterPods-blahblah/Build/Products/Debug-iphonesimulator/React-hermes directory. Apparently it was a leftover from the previous build where Hermes was enabled.
I consider __has_include to be problematic. I merely tries to locate <reacthermes/HermesExecutorFactory.h> in all header/framework search paths. It is very brittle.

[dmytrorykun]

@cipolleschi Probably injecting RCT_USE_HERMES=0 into React-Core and the main target is a right thing to do here to unblock the release. But we have to come up with a more civilized approach to enabling/disabling Hermes.

[cipolleschi]

The solution I proposed won't add the flag to the React-Core Target: to do that you have to either:

• modify the React-Core.podspec, reading some ENV variable
  or
• use add a post_install function to alter React-Core. I think that we already have a function that adds a flag to React-Core, in the react_native_pod.rb script.

But we have to come up with a more civilized approach to enabling/disabling Hermes.

Definitly, also because now we have 2 different flags for that: RCT_USE_HERMES and just USE_HERMES... 🤦

[mikehardy]

FWIW - I think Hermes is very close to working with use_frameworks, and I think it is an error to tangle them in a way where turning on use_frameworks disables hermes as a fact of build machinery

So I do not like this idea as it conflates the two if I understand correctly

def react_native_use_frameworks!
  use_frameworks!
  RCT_USE_HERMES = 0
end

I would rather have independent toggles somehow/somewhere.

It also appears that I may just have some stale compile artifact laying around? I'll test again with more environment verification next time

[cipolleschi]

To build in Release, you have to reinstall the pods with the PRODUCTION=1 flag. This will skip the installation of Flipper.
It is Flipper that is triggering that error.

[dmytrorykun]

Whoa, I somehow missed that. Thanks!

[kelset]

@cipolleschi is this only for RNTester or we need to tell everyone to do this always if they are on 0.70?

[cipolleschi]

Everyone! It is a fix we put into the 0.69, if I remember correctly. This is the PR ;)

Unfortunately, for how Cocoapods works, it installs the dependency in any case, but it links the dependency only to the specified configurations, if any (the default is all the configurations, of course). However the linking step happens after the building and Xcode tries to build the library in any case. 🤷🏻‍♂️
This is of course a workaround until we fix the underlying issues.

[kelset]

that might solve it... but honestly I don't think I know enough 🤣 is there a way to test this locally within the CLI repo itself, before publishing a new release?

[kelset]

@danilobuerger this should now be fixed in RC4, can you try it out and let us know?

[danilobuerger]

@kelset

❯ npx react-native init RN070RC4 --version 0.70.0-rc.4
Need to install the following packages:
  [email protected]
Ok to proceed? (y) y
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: undefined@undefined
npm ERR! Found: [email protected]
npm ERR! node_modules/react-native
npm ERR!   peer react-native@"*" from @react-native-community/[email protected]
npm ERR!   node_modules/@react-native-community/cli
npm ERR!     @react-native-community/cli@"^6.0.0" from [email protected]
npm ERR!   react-native@"0.69.4" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! react-native@"0.69.4" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: [email protected]
npm ERR! node_modules/react
npm ERR!   peer react@"18.0.0" from [email protected]
npm ERR!   node_modules/react-native
npm ERR!     react-native@"0.69.4" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! See /Users/danilo/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/danilo/.npm/_logs/2022-08-22T16_03_05_992Z-debug-0.log

[kelset]

It works on my machine (attached is the screenshot that also shows me being on latest Node 18)

It really looks like it's a local caching problem on your side at this point; we have removed the peerDeps from CLI

[danilobuerger]

Yup, works now. Thanks!

[kelset]

@nikhil-kumar-160 you need to provide repro steps and more information - please open a dedicated issue. This report is not providing any info to understand what the problem is.

[nikhil-kumar-160]

I just created a fresh project using the RN 0.70.0 RC3 and enabled the new architecture on android
Tried building the project. The project compiled successfully but as soon as I launch the app..the app crashes and gives this error

[kelset]

@nikhil-kumar-160 can you try again with RC4?

[nikhil-kumar-160]

@kelset, It is working now

[mikehardy]

[Edit: use_frameworks + Hermes works with use_frameworks! :linkage => :static - not the default "dynamic" - this may bear investigation but there is one success path here at least so 0.70 will work for me, with Hermes]

Hey all, I have more availability to test now, and while I have a react-native-0.70-rc.3 building on iOS with this:

+use_frameworks
-Hermes (with a source patch as mentioned above)
-Flipper,

I was trying to get Hermes working:

+use_frameworks
+Hermes
-Flipper

...and it fails right now, although I believe a fair bit of work was done here (@Kudo ? am I remembering this correctly? It was more than a few weeks ago...)

I see this at what appears to be the final link stage, after compiling everyrhing:

❌ Undefined symbols for architecture x86_64
❌   "vtable for facebook::react::HermesExecutorFactory", referenced from:
❌ ld: symbol(s) not found for architecture x86_64
❌ clang: error: linker command failed with exit code 1 (use -v to see invocation)

I have this repro focused on it https://github.com/mikehardy/rnfbdemo/blob/rn70-hermes-use-frameworks/make-demo.sh

[mikehardy]

Ah! I did not try that, I did not specify linkage (which means that it defaults to dynamic, for those following along).

So first of all: this is fantastic @Kudo thank you for getting this working!

I am a little confused though

In the comment you linked it said disabling bitcode was a possibility, and I thought the workaround was one or the other, not both at the same time? In the comment below I show the Podfile post install stanza I use to disable bitcode, and I do so in my reproduction, but that is not sufficient. So I think I misunderstood, and as I will have to give guidance to a lot of people I want to make sure I understand what the intention was.

Both of those (bitcode, and linkage => static) are required for it to work, not just disable bitcode by itself?

https://github.com/mikehardy/rnfbdemo/blob/12c3d5fa6fd0847e95770e0ac584f6c2b32f2945/make-demo.sh#L102-L104

[Kudo]

it's just static framework should act better runtime startup performance. if there's no other reason, i would prefer static frameworks than disabling bitcode. do you know whether there're any libraries require dynamic frameworks? if so, i would have to investigate the error for hermes + dynamic framework.

[mikehardy]

static has the app size penalty though, so there is a tradeoff, though to your point startup time is better and perhaps it is a better choice to link static

What I saw though was that disabling bitcode was not sufficient by itself. If you disable bitcode and have dynamic linkage, it fails.

So it seems both are needed: disable bitcode and static linkage.

To your question: I'm not aware of the requirements of too many libraries, but the libraries I use have worked either way, with exception now of hermes which seems to require static

This is still an advance, so it's possible to just document it and move on for now while examining Flipper and New Architecture. I am just trying to make sure I understand it myself so I may provide accurate guidance for others

[Kudo]

In the comment you linked it said disabling bitcode was a possibility, and I thought the workaround was one or the other, not both at the same time? In the comment below I show the Podfile post install stanza I use to disable bitcode, and I do so in my reproduction, but that is not sufficient. So I think I misunderstood, and as I will have to give guidance to a lot of people I want to make sure I understand what the intention was.

yep, it's an either or. either static framework or disable bitcode. once using static framework, i think disable bitcode is not necessary.
for dynamic framework + hermes + disable bitcode, if we would like to support this case. we would have to figure out why HermesExecutorFactory is undefined.

[mikehardy]

Hmm Okay - I can say that the dynamic linkage + disable bitcode branch of that or statement is failing at least then, that's the repro I posted

We do have a success result with static linkage + disable bitcode and based on your statement I'll try it without disabling bitcode just to see if I/we can authoritatively state "static linkage is all you need for hermes". That is just in my "interesting to know" category vs "really important to know" since bitcode is going away anyway.

Even though the build failure is surprising and might bear examination, I think as long as we have one success path for use_frameworks + hermes that is sufficient to make Flipper now the top priority. It is for me anyway, so I'm gong to move on to Flipper + use_frameworks

I may add more information here if I think it is useful, but I'll go ahead and hide my comment assuming I have the power to do so. Thanks again Kudo

[kelset]

will likely be picked in 0.70.1, but worth keeping tab on facebook/react-native@f35d18c

[tomatoaiu]

Hello!
I have built ReactNative v0.70.0-RC.4 for Android. I verified that it starts and works properly! Thanks to all the developers.

However, I found one bug.
TextInput's onKeyPress does not work on Android 13 with any key other than the Backspace key.

I have confirmed that this problem is still happening in 0.69.4. As a bug, I have also made it an issue.

Please forgive me if this is not appropriate for discussion.

[mikehardy]

wonderful bug report over there (I just read it) with clear repro. +1 for that

[grahammendick]

Hi, I was expecting 2 PRs to make it into React Native 0.70.0 (#34254 and #34217) but neither are there. How can I get these PRs into this or the next React Native release?

[danilobuerger]

Why would you expect them to be in the 0.70 release? The branch cut happened on 15 Jul 2022, your PRs got merged on a later date.
See https://reactnative.dev/contributing/release-faq for inclusion in 0.70
For 0.71, if they are on main, they will automatically make it into the branch cut.

[grahammendick]

Ok, thanks 👍

[mikehardy]

At the same time the diffs on those are small, might be pickable depending on opinions of severity of issues fixed + whether they pick cleanly etc

[grahammendick]

Oh thanks, but I can wait for 0.71.0. I was just checking that they hadn't got skipped somehow

[Kudo]

hope facebook/react-native#34527 to get attention and land in 0.70.

[Kudo]

thanks for pushing the pr landed as facebook/react-native@3afef3c. i don't want to block the release. so it's not necessary be included in the 0.70.0, we can do it in 0.70.1. thanks!

[mk0116]

react-native: 0.70.0-rc4
react-native-gesture: 2.6.0(support 0.70.0)
new architecture: No
platform: ios

Hello, I had a build error but I'm not sure whether this is an issue of RN or the library.
This is the error message.

#include <react/renderer/components/rngesturehandler/ShadowNodes.h>
-->
~/React-Codegen/react/renderer/components/rngesturehandler/Props.h:12:10: 'react/renderer/components/view/ViewProps.h' file not found

It looks like there are path issues while compiling.

The file "ShadowNodes.h" is successfully generated by codegen at the same path with "ShadowNodes.cpp" but the compiler doesn't recognize where it is.

I'll really appreciate if you let me know what I did wrong

I upgraded my app from 0.67.4 to 0.70.0-rc4. That I think some missing configuration could possibly cause the error.

[mk0116]

It worked fine when I turned on new arch option.

[Kudo]

@mk0116 if you change new/old arch, please also remove ios/Pods and especially ios/build. there're some different generated code there.

[mk0116]

That works! Thank you so much. @Kudo :)

[tido64]

We should pick this Yoga crash fix: facebook/react-native@361b310

Since it's an old bug and 0.70 is already good to go, feel free to delay till .1