Closed grabbou closed 3 years ago
Compiling the default generated app with 0.64-rc.2 gives the following errors:
RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:16:28: error: cannot find protocol declaration for 'NativeVibrationSpec'
@interface RCTVibration() <NativeVibrationSpec>
RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:33:20: error: use of undeclared identifier 'facebook'
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:33:49: error: type name requires a specifier or qualifier
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:33:72: error: use of undeclared identifier 'facebook'
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:35:27: error: use of undeclared identifier 'facebook'
return std::make_shared<facebook::react::NativeVibrationSpecJSI>(params);
RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:27:33: error: cannot find protocol declaration for 'NativeLinkingManagerSpec'
@interface RCTLinkingManager() <NativeLinkingManagerSpec>
RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:188:20: error: use of undeclared identifier 'facebook'
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:188:49: error: type name requires a specifier or qualifier
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:188:72: error: use of undeclared identifier 'facebook'
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:190:27: error: use of undeclared identifier 'facebook'
return std::make_shared<facebook::react::NativeLinkingManagerSpecJSI>(params);
As well as:
fatal error: module map file '/Users/username/Library/Developer/Xcode/DerivedData/RN064-fpnzltspmimnjpcudwlvlpjgalym/Build/Products/Debug-iphonesimulator/YogaKit/YogaKit.modulemap' not found
app size increase after enabling Hermes in ios
On the latest RC2 release, failed to build via command line with the next error:
The following build commands failed: CompileSwift normal x86_64 /Users/xxx/GitHub/xxx/ios/Pods/YogaKit/YogaKit/Source/YGLayoutExtensions.swift CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (2 failures)
But works well using XCode.
On the latest RC2 release, failed to build via command line with the next error:
The following build commands failed: CompileSwift normal x86_64 /Users/xxx/GitHub/xxx/ios/Pods/YogaKit/YogaKit/Source/YGLayoutExtensions.swift CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (2 failures)
But works well using XCode.
same for me
Hi Folks,
I was able to upgrade successfully my react native application without much trouble. initially i faced few issues, but reinstalling node_modules, regenerating pods helps to upgrade it successfully.
I'm trying to upgrade to RN 0.64-rc.02, on android i don't have issues. On ios during the archive process, i encountered this error:
I can replicate the error on both pipe and local pc.
@lorenzoangelini looks like you're using codepush 🤔 CodePush + Hermes isn't supported on iOS yet, see https://github.com/microsoft/react-native-code-push/issues/1986 and https://github.com/microsoft/react-native-code-push/issues/1966 (or https://github.com/microsoft/appcenter-cli/issues/1164)
Hi @mrousavy i don't use codepush. If i disable hermes the archive works.
@grabbou this pr, https://github.com/facebook/react-native/pull/30470, is present into RN 0.64.0-rc.2? Because after the upgrade, the app crash on start uo in release mode with hermes enabled. (on android). Without hermes, the app doesn't crash. But on RN 63.4, with hermes enabled, i don't have any issue.
EDIT: I found the problem, I use this https://github.com/react-native-community/jsc-android-buildscripts it seems that it is not supported in RN 0.64.0. I solved it by removing the library
With hermes enabled it can't find FBReactNativeSpec/FBReactNativeSpec.h
file in RCTVibration.mm.
Disabling hemes solves the problem.
Looks like the issue caused by some third-party pod as it was working fine initially.
Also, libevent generating a crazy amount of warnings while compiling.
'FBReactNativeSpec/FBReactNativeSpec.h' file not found
I have this same issue, although in my case it's complaining at React-RCTAnimation.build
.
If you clean the iOS project and recompile, it works again (I use react-native-clean-project and wipe iOS build folder option).
NativeVibrationSpec
i have the same issue, any solution please?
'FBReactNativeSpec/FBReactNativeSpec.h' file not found
I have this same issue, although in my case it's complaining atReact-RCTAnimation.build
. If you clean the iOS project and recompile, it works again (I use react-native-clean-project and wipe iOS build folder option).
maybe related to https://github.com/facebook/react-native/issues/30257 ? or https://github.com/facebook/react-native/pull/30449
hey folks - since we are now entering the ✨magical time✨ between Christmas and New Year, most of the maintainers are off on holidays; so I don't think there will be much going on here, or in terms of new commits or releases until January.
For all the issues you are reporting please open an issue on the main repo; it makes everyone's life easier to have the conversation for these kind of bugs somewhere else so that we can keep the one here on which commits to cherry pick (and just have here the link to said issues).
@KingAmo one thing in your comment on https://github.com/facebook/react-native/issues/30257 that caught my eye is that you are using npm@7 and I'm worried maybe also other folks here are having issues because of that.
Either way, again, please open an issue, and keep the conversation there.
Over and out, happy holidays everyone. See you in January.
@kelset i have a warning
when run pod install
in /ios
folder:
[!] FBReactNativeSpec has added 1 script phase. Please inspect before executing a build. See `https://guides.cocoapods.org/syntax/podspec.html#script_phases` for more information.
@KingAmo
[!] FBReactNativeSpec has added 1 script phase. Please inspect before executing a build. See `https://guides.cocoapods.org/syntax/podspec.html#script_phases` for more information.
That's just a warning for the codegen script that was added to FBReactNativeSpec
. It can safely be ignored.
follow the upgrade helper from rc.1
to rc.2
solved 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
problem for me.
Would appreciate it if we could cherry pick in facebook/react-native@6d2a527 The commit fixes an issue on iOS/macOS/Windows where clicks or taps are sometimes eaten when using a physical keyboard instead of soft keyboard.
I think this one might have gotten lost.
@NickGerleman I will check it tomorrow and let you know.
We ended up porting the fix to 0.63 for RN macOS and RN Windows, but are using stock bits for 0.64 so far. The issue is pretty bad for tablet or desktop usage, so it would be great if we could fix across platforms before release.
I would like to ask to cherry pick the https://github.com/facebook/react-native/commit/8aea93022bad4ed57ff6b738528a43f26fc335ac. It is a trivial change that removes an unnecessary TurboModule dependency on Folly. It would help us avoid forking TurboModule files in the react-native-windows where we are adding support for C++ TurboModules in https://github.com/microsoft/react-native-windows/pull/6804 .
Please consider cheery picking https://github.com/facebook/react-native/commit/381fb395ad9d2d48717a5d082aaedbecdd804554. It’s only a few lines and would greatly improve accessibility and the Android e2e testing experience so that the misuse of the accessibilityLabel can finally come to an end! Corresponding pull request was https://github.com/facebook/react-native/pull/29610
Current latest release: v0.64.0-rc.1
Isn't 0.64.0-rc.2 the latest one? :P
I have errors based on the method how I init application. If I use upgrade tool from rc1 to rc2 errors are based on RCTClipboard
If I init react-native app with --version rc2 errors are based on RCTVibration
It can't find
FBReactNativeSpec/FBReactNativeSpec.h
file in RCTVibration.mm.=
@lumberman @beetlebum right now, the CodeGen stuff is not run at pod install
time, but after building the project. So indeed, before the first build, there might be some errors in the workspace.
CC: @hramos - not sure whether that is desired UX. Alternative would be to run this script while doing pod install
anyway.
@grabbou So I've tried to build android, but my builds failed because the turbo module JSI JNI
.so
files were generated more than once:- More than one file was found with OS independent path 'lib/x86_64/libturbomodulejsijni.so'. If you are using jniLibs and CMake IMPORTED targets, see https://developer.android.com/studio/preview/features#automatic_packaging_of_prebuilt_dependencies_used_by_cmake
I temporarily fixed this, by adding this:
android { // ... + packagingOptions { + pickFirst '**/*.so' + } // ... }
in my
app/build.gradle
(under theandroid {
section). Since I'm not sure if that has any unwanted side-effects, I don't really feel comfortable with shipping an app like this, but it builds fine for now. (I couldn't get the app to actually run due to errors with reanimated - working on that! software-mansion/react-native-reanimated#1469)
@mrousavy do you have any update on this? Since I couldn't reproduce it, my question is - did you get it on a fresh new app?
@grabbou No, I had those errors in my app which worked fine on RN 0.63, but I think it's related to reanimated. I'll test again tomorrow 👍
Hey!
I am back to work in 2021 after holidays! I had a run through comments today and checked the status of the release. I would like to get it out to you as soon as possible. We're not that far away, while it may look otherwise based on the list of issues below!
Issues to verify:
Regressions:
Cherry-pick requests:
I will start with the issues first. The plan is to resolve everything by 24th of January and push the latest release candidate before going stable.
The regression has a fix that has already landed on master: https://github.com/facebook/react-native/commit/4481d09865c728f08017687f9f2bbb0399d48e45
I would like to propose to cherry-pick https://github.com/facebook/react-native/commit/6bfd89d27724f2aac602fa2acbf4753950f4152e to improve Android networking security. I expect no issues with this change.
Not sure if this is related to https://github.com/react-native-community/releases/issues/214#issuecomment-758200295 or not, but I've noticed that there's an issue stripping symbols on Android in the latest RC. It happens in debug and release, with and without Hermes. Occurs on a freshly-created app running RN 0.64.0-rc.2
.
> Task :app:stripReleaseDebugSymbols
Unable to strip the following libraries, packaging them as they are: libc++_shared.so, libfb.so, libfbjni.so, libfolly_futures.so, libfolly_json.so, libglog.so, libglog_init.so, libhermes-executor-common-debug.so, libhermes-executor-common-release.so, libhermes-executor-debug.so, libhermes-executor-release.so, libhermes-inspector.so, libhermes.so, libimagepipeline.so, libjscexecutor.so, libjsijniprofiler.so, libjsinspector.so, libnative-filters.so, libnative-imagetranscoder.so, libreact_codegen_reactandroidspec.so, libreact_nativemodule_core.so, libreactnativeblob.so, libreactnativejni.so, libreactnativeutilsjni.so, libreactperfloggerjni.so, libturbomodulejsijni.so, libyoga.so.
@dulmandakh I would prefer to not cherry-pick anything at this point, unless it's critical. Let's leave something exciting for the 0.65 that will be cut shortly after this one is out.
I'm having this same issue https://github.com/react-native-community/releases/issues/214#issuecomment-758194436,
the same way it's noted in build.gradle
that one should do a ./gradlw clean
after changing enableHermes option, it should be noted in podfile
that one should do a pod install
after enabling /disabling hermes on ios.
@dulmandakh I would prefer to not cherry-pick anything at this point, unless it's critical. Let's leave something exciting for the 0.65 that will be cut shortly after this one is out.
please elaborate on "shortly" - the 0.64 release took many months
@hsavit1 While I understand that you'd like things to move faster, I think everyone try to do their best to release good stable versions. If you want to work with the latest commits on master (like fb does), feel free to use the nightly builds, these are made for you. Also please keep this discussion to bug reports especially when we are that close to the release 😄 .
@Titozzz By "nightly builds" do you mean build by oneself? But based on my personal experience, most of the time the master could not pass the build in the OSS repo (fb has a different internal version/build process I think and neither did they test or care about the OSS builds). Or did I miss something, is there any public nightly builds channel?
@sunnylqm the react-native repo does publish nightly builds! The main consumer at this point is the react-native-windows project, because we want to validate and integrate new changes before they're released. These builds are published under the "nightly" dist-tag. E.g. https://www.npmjs.com/package/react-native/v/0.0.0-6fd684150
There is likely to be dragons with these, but reporting or fixing any issues affecting the public OSS build would be a great way to help make things smoother at release time.
@NickGerleman Thanks for the info and surprised that I never heard of it! Maybe someone should note that somewhere like https://reactnative.dev/versions
Is this PR https://github.com/facebook/react-native/pull/29039 something that could be merged and cherry picked prior to the final release or maybe in the upcoming ones? It is a common issue that we have been facing on our team on our last 2 projects.
I have switched to whatsapp gb long ago.
@grabbou I can confirm I am getting FBReactNativeSpec/FBReactNativeSpec.h file in RCTVibration.mm
with hermes option disabled. Hermes does not seem to be problem. I am referring to this #214 (comment)
Did cleaned the project and the issue persists.
@marudy you need to pod install
again after enabling Hermes.
This is not related to Hermes as it's disabled in our build and we still experience this issue. I'm still seeing the error randomly pop up, although usually it goes away after a few tries cleaning the iOS build.
Could it be related to the order in which codegen and other compilation steps happen? there could be an extra migration step we're missing.
node_modules/react-native/Libraries/NativeAnimation/RCTNativeAnimatedModule.mm:8:9: fatal error: 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
#import <FBReactNativeSpec/FBReactNativeSpec.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
@a-eid yeah i am doing pod install
every time. It's not the cause of the problem
FBReactNativeSpec/*
files actually get generated inside the node_modules/react-native/Libraries/<Library Name>
directory, and not in the usual ${PODS_ROOT}/Headers/Public/<Library Name>
where CocoaPods and Xcode expect them to be. This means that:
a) any operation that touches node_modules
can destroy generated files;
b) if other Pods depend on the FBReactNativeSpec
target and are not configured to search for headers in the node_modules/react-native/Libraries/
dir, they will not be able to find generated sources.
The generated files are also not listed in the "Output Files" of the Xcode's Script stage. This may create issues with the Xcode's "New" build system, since it can nondeterministically run codegen after the build steps that implicitly depend on its results.
I guess these may play some role in the issues people are observing.
Following up on my earlier comment – this change alone seems to help:
diff --git a/Libraries/FBReactNativeSpec/FBReactNativeSpec.podspec b/Libraries/FBReactNativeSpec/FBReactNativeSpec.podspec
index 70e90d54ea439ef076c80c5d53d441919b5315a7..ef1ae65ae4482b90f5d063408d70f7e57abcf8e7 100644
--- a/Libraries/FBReactNativeSpec/FBReactNativeSpec.podspec
+++ b/Libraries/FBReactNativeSpec/FBReactNativeSpec.podspec
@@ -59,7 +59,7 @@ Pod::Spec.new do |s|
s.script_phase = {
:name => 'Generate Native Modules Code',
:input_files => [srcs_dir],
- :output_files => ["$(DERIVED_FILE_DIR)/FBReactNativeSpec-codegen.log"],
+ :output_files => ["$(DERIVED_FILE_DIR)/FBReactNativeSpec-codegen.log"] + generated_files,
:script => codegen_command,
:execution_position => :before_compile
}
At least it makes Xcode wait for codegen before proceeding with compilation of the FBReactNativeSpec
target and its dependents.
It may still be problematic that the codegen results are put in node_modules
and not in the DerivedData
dir, though.
(The first thing that actually came to my mind is that codegen'ing into node_modules
will complicate supporting PnP in Yarn v2, aka Berry, since it expects the dependencies' sources to be immutable)
UPDATE:
No, this change still doesn't solve the issue of generated files not existing during the time when pod install
is run for the first time after a clean install. Since there are no files at this point yet, the FBReactNativeSpec
target ends up having no sources.
I imagine this is the same problem discussed above, but on the off chance this variant is helpful, here's my version:
error: Build input file cannot be found: '/my-app/packages/mobile-app/node_modules/react-native/Libraries/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec-generated.mm' (in target 'FBReactNativeSpec' from project 'Pods')
I am using a monorepo, which perhaps is another twist. Also when trying to apply the diff, there are a NUMBER of pbxproj changes that mostly look cosmetic - ids changing etc. If there's any way to NOT have those spurious changes in the diff I think everyone who upgrades would be very appreciative.
@dulmandakh I would prefer to not cherry-pick anything at this point, unless it's critical. Let's leave something exciting for the 0.65 that will be cut shortly after this one is out.
please elaborate on "shortly" - the 0.64 release took many months
@hsavit1 I know, 0.64 is taking a while to release due to many unexpected conditions, including New Years Eve and lots of holidays that happened in the meantime. I am really sorry that this one had extraordinary amount of delays, but due to the nature of release process, sometimes it gets particularly tricky.
Last week was my first week after holidays. It was also a busy time for our friends over at Facebook due to lots of internal things happening.
I am going to send an updated game plan later today (here's the comment). I hope that all outstanding errors can be fixed this week.
@grabbou Don't stress too much about it. A wise man once said, 'a delayed release is eventually good, but a rushed one is forever bad.'.. I think it was Albert Einstein
@marudy @beetlebum @ivanmoskalev @cosmarc @djMax, are you all running a fresh React Native app or an upgraded one? I am not able to reproduce any CodeGen-related errors on a fresh application, that would be caused by the place where the execution of the generator takes place.
I created a fresh application, opened it up with Xcode and had no errors. I've hit compilation and managed to run it on a simulator without any errors as well.
The reason I am asking is - maybe there's something additional and specific to your project (during upgrade) that a fresh app already has?
Thank you for the answer @max-earnin, but this question is specifically targeted to quoted developers as they reported the same TurboModule-related issue. Are you running into the same problem as well? If yes, can you verify that everything works fine on your machine when starting a blank new project? That way, we can have a starting point.
@marudy @beetlebum @ivanmoskalev @cosmarc @djMax, are you all running a fresh React Native app or an upgraded one? I am not able to reproduce any CodeGen-related errors on a fresh application, that would be caused by the place where the execution of the generator takes place.
I created a fresh application, opened it up with Xcode and had no errors. I've hit compilation and managed to run it on a simulator without any errors as well.
The reason I am asking is - maybe there's something additional and specific to your project (during upgrade) that a fresh app already has?
I have a massive project with dozens of dependencies that was started with 0.61, it would be hard to replicate from scratch I reckon.
Here's a list of modules:
BVLinearGradient, RNCAsyncStorage, RNCClipboard, RNCMaskedView, RNCPicker, RNCPushNotificationIOS, RNDeviceInfo, RNFBAnalytics, RNFBApp, RNFBAuth, RNFBPerf, RNFBRemoteConfig, RNFastImage, RNGestureHandler, RNLocalize, RNPurchases, RNRate, RNReanimated, RNSVG, RNScreens, RNSentry, RNShare, ReactNativeAutogrowTextinput, lottie-ios, lottie-react-native, react-native-adjust, react-native-amplitude-analytics, react-native-date-picker, react-native-fbsdk, react-native-netinfo, react-native-onesignal, react-native-pdf, react-native-restart, react-native-safe-area-context, react-native-slider, react-native-splash-screen, react-native-text-input-mask, react-native-track-player, react-native-video, react-native-view-shot, react-native-viewpager, react-native-zendesk, and rn-fetch-blob
The error is always the following:
Code/GitHub/better-half-app/node_modules/react-native/Libraries/NativeAnimation/RCTNativeAnimatedModule.mm:8:9: fatal error: 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
#import <FBReactNativeSpec/FBReactNativeSpec.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interestingly, it does always go away if I get the error, then clean the iOS build project, do pod install
and react-native run-ios
again, although it's a very time consuming error since it compiles everything from scratch.
Hope this helps, thanks in advance.
Current latest release: v0.64.0-rc.4
Highlighted Changes
profile-hermes
CLI command for converting Hermes tracing profile to Chrome formatPlease see the changelog PR for more details.
Work Required
shelljs
has been moved from the rootpackage.json
intorepo-config/package.json
(https://github.com/facebook/react-native/commit/f3930a93d5cf5f19058b0bfe453c7b9324eb8552), causingpublish-npm.js
script to fail. I have temporarily installed that package on the CircleCI, but would love additional background on the original commit and whether we can safely move it back to the root. https://github.com/facebook/react-native/pull/30472Already resolved
- [X] [Update documentation](https://github.com/facebook/react-native-website/projects/1) [@simek] - [x] facebook/react-native#29914 - [x] React 17 support (landed) - [x] facebook/react-native#29882 - [x] facebook/react-native#30177 - [x] facebook/react-native@a7c1c5a - [x] Bump CLI to latest - [x] Migrate warnings in index.js to point to new lean core repos (https://github.com/facebook/react-native/pull/30422) - [x] The `hermes-engine` pod has no version constraints specified, which should probably happen in the `React-Core.podspec` file and lock it with similar version constraints as the one applied to the Android version in `package.json`. Fixed by https://github.com/facebook/react-native/pull/30432 - [x] The newly introduced codegen invocation step in the iOS Podfile is failing, as the dependencies of the `react-native-codegen` package have not been installed. See output [here](https://gist.github.com/alloy/2d3b3285b76666234be62086f9d4b8b6). In progress PR here https://github.com/facebook/react-native/pull/30449 - [x] Trying to build a newly created Android app fails when checking the dynamic libraries for duplicate classes. See output [here](https://gist.github.com/alloy/a9f2f4102705bad0b2c53407edd2bd89). Fixed by https://github.com/facebook/react-native/pull/30452 - [x] https://github.com/facebook/react-native/pull/30470 - [x] The new CLI has a minor regression when using a local template dir, now you need to specify the `file://` protocol to resolve that [@grabbou] (added note to changelog, this is expected) - [x] https://github.com/facebook/react-native/commit/d85d5d2e1974b463318e4c86da29a5ccdd60a977 - [x] facebook/react-native#30489 (+ make sure to update the changelog as [per this comment](https://github.com/facebook/react-native/pull/30489#pullrequestreview-539864503)) - [x] Bump to Hermes 0.7.2 (facebook/hermes#373) (https://github.com/facebook/react-native/pull/30561) - [x] Add instructions on how to enable Hermes in the default application https://github.com/facebook/react-native/pull/30461 - [x] Running `pod install` outside of `ios` folder will fail facebook/react-native#30469 (temporary solution, will be fixed by facebook/react-native#30449) - cherry picked https://github.com/facebook/react-native/commit/c901c1fbce080c6e9b6ed56dbccaa7f2fa0571b2, https://github.com/facebook/react-native/commit/5eee2f2bc01184481a663453648ab15d1d295f4d and https://github.com/facebook/react-native/commit/b61aaa1545b3308bda5ade169204f875ba417f01 for the record. - [x] ~~Submitting Hermes enabled application to AppStore will fail validation https://github.com/facebook/hermes/issues/420~~ This isn't a release blocker; this issue is triggered when somebody specifies a higher deployment target than the default and can be solved by the user as shown [here](https://github.com/facebook/hermes/issues/420#issuecomment-736875843). - [x] https://github.com/facebook/react-native/pull/30571 - [x] Building React Native application in release mode will cause an issue with Xcode 12 facebook/react-native#29984 (here [is a workaround](https://github.com/facebook/react-native/issues/29984#issuecomment-696328815)) https://github.com/facebook/react-native/pull/30543 - [x] facebook/react-native#30495 (regression) - [x] Building with Hermes in Release mode (or with "build active architecture" set to false) causes "Thread-local storage is not supported for the current target" in "folly/synchronization/Rcu.cpp:17:10:" and happens while building for "i386". https://github.com/facebook/react-native/pull/30592 - [x] Resolve issues highlighted in the comment https://github.com/react-native-community/releases/issues/214#issuecomment-758203239 - [x] https://github.com/facebook/react-native/commit/811ccec74e5b898e9304f86f85f390908f8d317f - [x] https://github.com/facebook/react-native/commit/7a9e4ba4e9ae02ab8a0fe0f67ceefd5d675b9dbf - [x] https://github.com/facebook/react-native/commit/f312e5ba84afcddaac326ed62eaf4e00c00cf480 - [x] https://github.com/facebook/react-native/commit/f45cb60e560d21be134aa808bd105e0394ba1fd5 - [x] Issue stripping symbols on Android https://github.com/react-native-community/releases/issues/214#issuecomment-758425571 - [x] Some users are experiencing issues with CodeGen on iOS due to missing files https://github.com/react-native-community/releases/issues/214#issuecomment-766436299Hopeful Dates
We can never commit to the dates involved in a release as many things are out of our control. However, we are thinking about these rough dates for this release.