Closed kelset closed 3 years ago
swrobel
commented
3 years ago Cherry pick request: https://github.com/facebook/react-native/commit/41f45a77ad09b46de328fb2a72775a052dac1e93
Flipper Pod >= 0.94 has a fix for incorrect timestamps in the network tab in iOS apps
SConaway
commented
3 years ago Found a few iOS issues:
npx react-native init command), building for the iOS Simulator (through yarn ios --simulator "iPhone 12 Pro Max") or a device (through yarn ios --device "Name") errors with ld: warning: Could not find or use auto-linked library 'swift_Concurrency'
ld: warning: Could not find or use auto-linked library 'swiftFileProvider'
Undefined symbols for architecture x86_64:
"__swift_FORCE_LOAD_$_swiftFileProvider", referenced from:
__swift_FORCE_LOAD_$_swiftFileProvider_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
(maybe you meant: __swift_FORCE_LOAD_$_swiftFileProvider_$_YogaKit)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)I've tried using Xcode 13db3 and CLI. Upgrading flipper did not help, if that's the issue.
use_flipper!() in Podfile, (and no hermes), release builds can't be created for the iOS Simulator (through yarn ios --simulator "iPhone 12 Pro Max" --configuration "Release"). They fail, with the
AwesomeProject/ios/Pods/RCT-Folly/folly/container/detail/F14Table.cpp:41:10: Thread-local storage is not supported for the current targeterror (and another file, missed the name) as in https://github.com/facebook/react-native/issues/31179#issuecomment-831872601.
SConaway
commented
3 years ago And the android ones:
Some minor warnings with the out-of-the-box setup in release mode (seems like the first set cause the second):
When Hermes is enabled, these warnings happen to (JS being generated incorrectly?)
marqroldan
commented
3 years ago (No. 1 in above comment) I never got the Task :app:extractReleaseNativeSymbolTables text when attempting to build, this is also a fresh out of the box release
I'm using Node 16.5.0, and on Windows 10 if that matters
And for the No. 2 above (with Hermes enabled and building a release variant)
I get a virus warning š
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:packageRelease'.
> A failure occurred while executing com.android.build.gradle.tasks.PackageAndroidArtifact$IncrementalSplitterRunnable
> java.io.FileNotFoundException: F:\Development\Personal\RN065RC3\android\app\build\outputs\apk\release\app-release.apk (Operation did not complete successfully because the file contains a virus or potentially unwanted software)
I'll try to disable the antivirus and see what happens
Edit: After adding the project to the Exclusions list of Windows Defender, I was able to create a release variant šÆ
Maybe a false positive? Can't find anything decent on Google at the moment
ivanmoskalev
commented
3 years ago @marqroldan The !ml suffix in the "virus" signature means that it is a machine learning-based guess by Windows Defender. Might be useful to submit the file as a false positive.
marqroldan
commented
3 years ago Thanks @ivanmoskalev, I just sent the apk as a Home Customer because the Software Developer option asked for a company haha
--
I'm trying to build this on an m1 Mac mini without using Rosetta, trying to run a Debug on iOS simulator but I have encountered issues like:
Thread-local storage is not supported for the current target)Fortunately I was able to by following this https://github.com/aiba/react-native-m1
After trying a lot of combinations I was able to build it with a few steps:
npm install, did pod install (gotta get that workspace folder)This was without Hermes enabled.
I tried running a release version (simulator) but I got the folly issue:
arm64 Environment details:
COCOAPODS: 1.10.1
Node 16.5.0
Xcode 12.5.1
Big Sur 11.4p.s. I tried using this https://github.com/facebook/react-native/commit/b77948e33bc5e0df422fffca3b4c9253f611d298 thinking it would help with the issue but it was also the same, and on my end download speed for boost was slow x_x
Edit again:
I was able to build both release and debug versions (on simulator) with Flipper by reverting this https://github.com/facebook/react-native/commit/f31c6102cc6abc22de4f1e5f0cd1f3b003bbabc1. What I actually did was I simply replaced all matching string in my node_modules/react-native, and redid pod install
The commit above never reached 0.64 (and I'm able to build both debug and release on the 0.64 with Xcode 12.5.1, m1 non-rosetta)
I also had to update the build phase because no bundle was being linked (?) for some reason
cd $PROJECT_DIR/..
export NODE_BINARY=node
./node_modules/react-native/scripts/react-native-xcode.shHowever I wasn't able to build with Hermes, and getting the atomic_notify_one error again (expected)
I tried the latest version from folly, same thread_local issue
RichardLindhout
commented
3 years ago I got an error on this line:
#import <FBReactNativeSpec/FBReactNativeSpec.h>'FBReactNativeSpec/FBReactNativeSpec.h' file not foundI got an error on this line:
#import <FBReactNativeSpec/FBReactNativeSpec.h>'FBReactNativeSpec/FBReactNativeSpec.h' file not found
@RichardLindhout make sure to run pod install, since that seems like things didn't get set up properly.
kelset
commented
3 years ago @swrobel it seems that that change could also be manually done "user side" after 0.65.0 is released, so I'm not sure we'll cherry pick and do a new RC just for that commit.
@SConaway I appreciated you trying to report all those warnings but none of the steps you write have:
@marqroldan thanks for reporting that reverting that commit helps you, I wonder what's wrong with it that blocks you (and if it's something M1 specific š).
@RichardLindhout did @SConaway's comment help you? if so can you say it so that I can hide those two comments.
beetlebum
commented
3 years ago I reported issues with RC2 a few weeks ago and gave RC3 another try but had to downgrade to 64 again.
We keep getting the 'FBReactNativeSpec/FBReactNativeSpec.h' error when building the iOS app using the CLI and the only way to make it go away is to clean the build and pods, which is a very time consuming process.
We're also experiencing issues with Flipper compilation and it usually takes a few tries to pin down the right versions until it stops failing the build. I'm not very familiar with the iOS build pipeline but find it surprising that people experience different behaviours with the same Xcode version.
Reanimated 2 is also not ready for 65 so testing on Android was not even possible.
I'd be happy to provide any additional info that might help fix these issues.
OS: macOS 11.5
CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Memory: 184.27 MB / 16.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 16.5.0 - /usr/local/bin/node
Yarn: 1.22.10 - /usr/local/bin/yarn
npm: 7.19.1 - /usr/local/bin/npm
Watchman: 2021.06.07.00 - /usr/local/bin/watchman
Managers:
CocoaPods: 1.10.1 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: iOS 14.5, DriverKit 20.4, macOS 11.3, tvOS 14.5, watchOS 7.4
Android SDK:
API Levels: 27, 28, 29, 30
Build Tools: 30.0.2, 31.0.0
System Images: android-30 | Google Play Intel x86 Atom_64
Android NDK: Not Found
IDEs:
Android Studio: Arctic Fox 2020.3.1 RC 1 Arctic Fox 2020.3.1 RC 1
Xcode: 12.5.1/12E507 - /usr/bin/xcodebuild
Languages:
Java: 11.0.4 - /usr/bin/javac
npmPackages:
@react-native-community/cli: ^5.0.1 => 5.0.1
react: ^17.0.2 => 17.0.2
react-native: ^0.64.2 => 0.64.2
react-native-macos: Not Found
npmGlobalPackages:
*react-native*: Not Found@beetlebum
We keep getting the 'FBReactNativeSpec/FBReactNativeSpec.h' error when building the iOS app using the CLI and the only way to make it go away is to clean the build and pods, which is a very time consuming process.
I'm not sure I understand, isn't the "clean builds and pods" a one-off thing? Or you are saying that it's inconsistently happening every time you do a build (and/or CI)? š¤
Reanimated 2 is also not ready for 65 so testing on Android was not even possible.
Oh wow I wasn't aware of that, do you know if they are tracking progress on that anywhere?
I'd be happy to provide any additional info that might help fix these issues.
I think that a repro would be ideal, the issue you are describing seems fairly tailored to your project config so it's kind of hard to "debug" without a testbench that can reproduce the problem consistently
ahmetbicer
commented
3 years ago Fresh install for android works without any issues in my machine. I couldn't update my own project because reanimated is not ready for RN-65 but it looks like there will be a new release this week according to this comment.
mrousavy
commented
3 years ago SConaway
commented
3 years ago I am very sorry for not providing that info.
Please let me know if there's anything else I can provide.
swrobel
commented
3 years ago @swrobel it seems that that change could also be manually done "user side" after 0.65.0 is released, so I'm not sure we'll cherry pick and do a new RC just for that commit.
Obviously that's the team's call, but I will say that figuring out the solution manually isn't easy, and I doubt many folks will do so. It would be nice to get this rather minor change into 0.65.0 since it has yet to be released, especially considering the unpredictable duration between RN releases.
mikehardy
commented
3 years ago For everyone hung up on reanimated release: 2.3.0-alpha.2 is out on npmjs.com with the RN65 commit so it will work on Android (I think). It appeared there were at least a couple people with test rigs set up blocked on android testing so I thought it was worth a callout
(note that if you use reanimated 2.3.0-alpha.2 with react-native < 0.65 and you have android build variants you will have a compile failure because nothing is easy... https://github.com/software-mansion/react-native-reanimated/issues/2245)
mikehardy
commented
3 years ago Haven't run this on Apple Silicon yet, but this shows success from npx react-native init --version=0.65.0-rc.3 with nearly all react-native-firebase modules in debug + release on android + ios with flipper + hermes (except for ios + static frameworks, then you have to toggle hermes + flipper off).
Only issue I detected was that I needed to pod install, then try the ios build, it would fail on the codegen ios file, run pod install again, then iOS would go off without a hitch (for build after build - it was only needed once) :shrug: ?
torture test / RNFB integration demo: https://github.com/mikehardy/rnfbdemo/blob/master/make-demo.sh
mikehardy
commented
3 years ago There's a summary below.
I have successfully gotten this whole shebang (https://github.com/mikehardy/rnfbdemo/commit/37dbe674474425dd49a651798411318d999fd88e#diff-3e27ae623577d0c559bd8ab973a0c34af8cc65ef9beb9868a9cdb029854f8078) to work on Apple Silicon from scratch now.
Apple Silicon requires something special for it to find the swift frameworks
...for some unknown root cause, or you get the error mentioned in this overly long thread (https://github.com/facebookarchive/react-native-fbsdk/issues/755) plus a few other issues and a bunch of stackoverflow posts. It's a showstopper for Apple Silicon people.
This is not a regression, it is present in react-native 0.64 as well (untested lower).
Many people recommend adding an empty Swift file with a bridging header, but I find this distasteful personally as
1) it is a manual thing that requires GUI manipulation in Xcode (hard to document, not automatic and
2) it is only done for the side effect it has of changing up library paths. I prefer this solution which directly has the desired effect, added in Podfile post_install stanza:
installer.aggregate_targets.each do |aggregate_target|
aggregate_target.user_project.native_targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['LIBRARY_SEARCH_PATHS'] = ['$(SDKROOT)/usr/lib/swift', '$(inherited)']
end
end
aggregate_target.user_project.save
endNote this is very specially constructed after a bit of trial and error: you don't need to clear the path (as some recommend), you need to make sure the swift path is first. That appears to be the trick. Why? :shrug: - it works reproducibly when automated though on 3 different projects.
Tested iOS Debug + Release with Flipper + Hermes on, Tested iOS Debug with static_frameworks and Flipper + Hermes off.
I did not test an Archive + TestFlight upload.
Separately, it's worth mentioning that react-native 0.65 has the only patch I think was necessary for android gradle plugin 7 support (https://github.com/react-native-community/cli/pull/1396) - with that patch I have successful builds using android gradle plugin 7.0.0 + gradle 7.1.1 (both current stable for those tools, as of this typing).
That's important because Android Studio will prompt people to update their plugin and many will. react-native 0.64 fails currently for people that do this, because of the already-fixed linked issue.
Xcode 13 betas are unverified. Anyone check those?
I have a stanza in my Podfile where I converge all build targets iPhone minimum deployment version to my apps version. Why do I do this? It gets rid of an incredible amount of build noise. I set it to 11 currently.
I set do this in post_install
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = $iOSMinimumDeployVersion
That appears to be the root cause of this bug + functional version-downgrade workaround in: Flipper https://github.com/facebook/flipper/issues/834#issuecomment-879346650
If you don't mess with build target deployment versions it appears to work out of the box. It's a common pattern though, I expect it will come up a lot for users
Summary:
In general: looks really good. It's not perfect, but I don't see any regressions and more importantly Hermes on apple silicon works now! That's a huge step.
SConaway
commented
3 years ago Xcode 13 betas are unverified. Anyone check those?
That's all I've been testing, actually. See my first comment for the issues with it.
Well, for whatever reason, adding @mikehardy's Podfile patch solved some of the iOS issues!
Specifically, it fixed all the errors that stemmed from ld. The thread_local errors still occur, though. Am I the only one running into it?
kelset
commented
3 years ago @SConaway @mikehardy n00b question, when is Xcode 13 supposed to come out?
AFAIK at FB they hardly ever test on anything "non-stable" (so the versions Steven has been testing on); this already created issues for things like Xcode 12.5 even if it was reported way ahead of release.
hsavit1
commented
3 years ago @SConaway @mikehardy n00b question, when is Xcode 13 supposed to come out?
AFAIK at FB they hardly ever test on anything "non-stable" (so the versions Steven has been testing on); this already created issues for things like Xcode 12.5 even if it was reported way ahead of release.
The official release / golden seed usually comes within a week within the next major version of iOS. No official date on that, but it's usually late September / early October
elicwhite
commented
3 years ago re: xcode 13 and the next version of Android. We filed tasks internally at Facebook last week for people on our team to figure out what is needed to be compatible so we can be aligned with when the FB app must be compatible. I don't expect it to be a part of 0.65.
mikehardy
commented
3 years ago @SConaway I do not confirm your issue using Xcode 13 beta 4 (13A5201i).
My react-native-firebase from-scratch install succeeds when using that version as my Xcode via download+unzip-to-Applications+xcode-select /Applications/Xcode-beta.app (and confirmed it was in use via xcode-select -p as well as xcodebuild -version + clang --version.
That's on an Intel mac, doing a release build. Apple Silicon + Xcode 13 beta 4 + react-native 0.65 unchecked so far.
Maybe it's specific to your project? Maybe it's Apple Silicon?
My script is reproducible, anyone can run it and verify my results, this is the actual commit version I'm using if someone (@SConaway ?) tries to probe the error and find the root cause: https://github.com/mikehardy/rnfbdemo/blob/37dbe674474425dd49a651798411318d999fd88e/make-demo.sh
Everything seemed to work fine.
The only thing that really seems like it will become a support issue, to me, is that I consistently have the codegen iOS file not generated first time through, I have to pod install, yarn ios (failure!), pod install, yarn ios (success!) for my first iOS build.
SConaway
commented
3 years ago Ok, sorry for being dead.
I've been testing on beta 3 (13A5192j) apparently (although it happened on previous betas), and just switched to beta 4. I will test with that and with the latest released version of Xcode 12. I'll also try with the steps from your script, although I'll run them normally in my shell.
I'm actually on a 2017 13" i5 MacBook Pro, so it shouldn't be AS-specific. I've recreated the project a few times, so I don't think it's something project-specific
hlspablo
commented
3 years ago Guys, I don't know if its the right place to speak about it, but the issue https://github.com/facebook/react-native/pull/29039 will be solved in this version? why no one gives attention to bugs here?
kelset
commented
3 years ago ok, I'm trying to catch up with everything, let's see if I manage to not forget anything:
react-native-codegen is defined as a dependency, we need to figure out / make sure it's correctly setup before proceeding with 0.65.0.
tido64
commented
3 years ago The only thing that really seems like it will become a support issue, to me, is that I consistently have the codegen iOS file not generated first time through, I have to
pod install,yarn ios(failure!),pod install,yarn ios(success!) for my first iOS build.
@mikehardy, @kelset: This seems to be caused by generate-specs.sh being run way too late. The generated files need to exist before CocoaPods generates the Xcode project, otherwise they won't be included.
Running pod install + yarn ios the very first time:
Running pod install the second time:
I think the fix is the move the generation step to prepare_command in the podspec. Anyone know whether this has been attempted? @grabbou, @hramos?
hramos
commented
3 years ago The prepare_command should take care of generating the empty FBReactNativeSpec.h and FBReactNativeSpec-generated.mm files, which is a necessary first step to ensure that CocoaPods picks up these files when it adds FBReactNativeSpec to the Pods project. The script in prepare_command only runs when the Pod is first installed, so moving the actual code-generation into prepare_command will not help if the issue is that prepare_command is not being invoked as part of your first pod install (if CocoaPods does not show that the FBReactNativeSpec Pod is being installed, then no, prepare_command is not being invoked).
Have you checked FBReactNativeSpec.podspec and generate-specs.sh to make sure they match what we already have in main?
tido64
commented
3 years ago Sorry, I will be oof the rest of the week and the week after. I won't have time to look at this until I'm back. Someone else should work on this if we want to release before then. That said, it sounds reasonable to add generate-specs.sh to prepare_command.
As for react-native-codegen not being installed with react-native, can we move it to dependencies of react-native? Having it under devDependencies in the template doesn't make sense to me as it only helps people who initialise a new project. react-native doesn't build without it, so we need to make it a direct dependency. We're essentially breaking everyone with an existing project.
hlspablo
commented
3 years ago hi @kelset , sorry for the off-topic, just to understand, how is the process of approving some feature / bug to master, I don't know where else to ask.
kelset
commented
3 years ago @hlspablo you can read about it here https://github.com/facebook/react-native/blob/main/CONTRIBUTING.md#our-development-process
swrobel
commented
3 years ago That appears to be the root cause of this bug + functional version-downgrade workaround in: Flipper facebook/flipper#834 (comment)
Perhaps I'm misreading the linked comment, but isn't it a Flipper upgrade that fixes the issue? If so, perhaps this is another reason to cherry-pick https://github.com/facebook/react-native/commit/41f45a77ad09b46de328fb2a72775a052dac1e93, as I requested here: https://github.com/react-native-community/releases/issues/238#issuecomment-885911580
mikehardy
commented
3 years ago That appears to be the root cause of this bug + functional version-downgrade workaround in: Flipper facebook/flipper#834 (comment)
Perhaps I'm misreading the linked comment, but isn't it a Flipper upgrade that fixes the issue? If so, perhaps this is another reason to cherry-pick facebook/react-native@41f45a7, as I requested here: #238 (comment)
One of the reasons I use an automated script to test is because my testing may be incomplete in any of an infinity of ways, but at least with it scripted it's reproducibly incomplete and thus fixable.
From my memory of exploring that specific issue, if you put in a Podfile stanza like this:
$iOSMinimumDeployVersion = '10.0'
post_install do |installer|
react_native_post_install(installer)
# We support a smaller range of deployment than some libraries, eliminate related noise
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = $iOSMinimumDeployVersion
end
end
...then nothing I tried worked except what I settled on:
use_flipper!({ 'Flipper' => '0.92.0', 'Flipper-Folly' => '2.6.7', 'Flipper-RSocket' => '1.4.3' })
I tried the stock one from the template (0.94 if I recall correctly) and I tried the one from the linked PR (0.99? or was it 0.94?) and I tried current (whatever it is). Nothing worked except that line of dependencies
Why? No idea - I personally use flipper in zero places so I'm trying to qualify it just from an interest in having some known-good versions of everything I can say works every time. That's technically uninteresting for root-cause analysis (sorry) but it does result in a successfully compile + app launch which is useful for release and support
mikehardy
commented
3 years ago Some pending good news - @Titozzz helped minimze my vague repro on the "codegen files missing" issue so that it was exactly on target and easy to run, and @hramos indicates he's got a patch.
Steady forward progress, I like it. I no longer have outstanding issues that I have seen and not documented, so now I'll go into standby and just wait eagerly for the release unless someone pings me. Cheers all
kelset
commented
3 years ago on the other pending topic of react-native-codegen, it looks like it should be a direct dependency: we ended up making that change in the 0.64 branch but was never backported to main https://github.com/facebook/react-native/commit/14db556963a63f0e7fbd74d2956fe56d7c941778
mikehardy
commented
3 years ago Unfortunately I have a new (to me) issue. I thought things were good as I was successfully doing debug and release configuration builds on iOS with demonstrators scripts, so I attempted to integrate react-native 0.65.0-rc.3 into a real app (with signing enabled) to do a real TestFlight build.
iOS archive fails with Hermes enabled, on both Intel and Apple Silicon macs, same error:
āø Compiling AppDelegate.m
āø Linking socioempleo
ā ļø ld: directory not found for option '-L/Users/mike/Library/Developer/Xcode/DerivedData/socioempleo-btbgxofzqbrkpfbbpdihdeurmixh/Build/Intermediates.noindex/ArchiveIntermediates/socioempleo/BuildProductsPath/Release-iphoneos/React-hermes'
ā ļø ld: directory not found for option '-F/Users/mike/Library/Developer/Xcode/DerivedData/socioempleo-btbgxofzqbrkpfbbpdihdeurmixh/Build/Intermediates.noindex/ArchiveIntermediates/socioempleo/BuildProductsPath/Release-iphoneos/XCFrameworkIntermediates/hermes'
ā ld: library not found for -lReact-hermes
ā clang: error: linker command failed with exit code 1 (use -v to see invocation)Hermes was working on this project on Intel macs while using react-native 0.64.2
I've tried the standard cleaning (npx react-native-clean-projecct etc) as well as pod deintegrate / pod install, it appears to reproducibly work in release configuration but not for archive.
Doing an archive requires signing so this is a little more difficult when sharing a reproduction but I'm curious if anyone else has attempted to do an Archive + TestFlight release of an iOS build + Hermes with rc3 ?
liamjones
commented
3 years ago Something I've just noticed while following the upgrade helper to try an RC3 upgrade...
mavenCentral is being added as the first repository in the list for Gradle: https://github.com/facebook/react-native/blob/main/template/android/build.gradle#L24.
Someone with more Gradle knowledge correct me if I'm wrong; doesn't the order of the repositories in this file dictate the order they're used for lookups?
If so, doesn't this mean that local node_modules dependencies will be looked for online first and, if one of them was suddenly published on Maven Central with the correct coordinates, it'd start pulling it from there - a potential attack vector?
mikehardy
commented
3 years ago Yes @liamjones the order in the file defines the precedence of lookup
However, the same was true before I think? In that mavenCentral is just replacing jcenter in the same slot, not that it is an ordering change. This is an assertion that bears verifying
I don't believe precedence in that file has been investigated from a security perspective at all. There is nothing stopping you from re-ordering locally or posting a PR to re-order the template once verified that local successfully works first
At the same time Maven Central does require some attestation prior allowing publishing on any coordinates. That's not an airtight guarantee of course - just means that an ankle-biter probably can't supply chain attack through that vector but an advanced persistent threat could probably slowly work out how to get it done
kelset
commented
3 years ago @mikehardy oh wow that's potentially a big one š±
mikehardy
commented
3 years ago @mikehardy oh wow that's potentially a big one š±
Yeah, I reverted to 0.64.2 and ios hermes archive works again. No root cause or hunches from me except that the release derived data contained hermes things while archive derived data did not. Maybe the xcframework copy? I really don't know.
Very curious to hear if anyone else is archiving 0.65 RC3 on ios with hermes
lunaleaps
commented
3 years ago @mikehardy So without hermes enabled this isn't an issue? Sorry quite unfamiliar with the process -- so when you archive and upload to testflight and in attempt to run the app that's when you see this error?
mikehardy
commented
3 years ago @lunaleaps I use fastlane to automate iOS TestFlight build delivery, and it in turn uses xcodebuild (with lots of arguments) via the command line to generate an Archive build. That archive build step fails, if hermes is enabled for iOS, on both intel and apple silicon macs with react-native 0.65.0-rc3. A linker error about React-hermes not found.
The same works fine with react-native 0.64.2 on intel macs (though hermes fails completely on apple silicon for 0.64.2, a known issue on that release)
I believe it works without hermes though I did not test that much. Xcode archive for iOS + hermes works on intel macs in react-native 0.64.2 thus this is a regression, and I simply reverted to 0.64.2 for the time being.
Arkkeeper
commented
3 years ago @mikehardy I've tested archiving with signing on 0.65.0-rc3 in several test apps (MacBook Air M1 with Monterey Beta), it worked flawlessly both with Xcode in UI and xcodebuild in command line. Thus, I doubt that the issue is really caused by react-native or hermes. Maybe we should compare xcodebuild arguments or parameters from "Build Settings" tab in Xcode?
tido64
commented
3 years ago @mikehardy Can you share more info about your setup? I tried locally and successfully created an archive using 0.65.0-rc3, hermes_enabled => true, on my Intel MacBook. Are you using use_frameworks! maybe?
mikehardy
commented
3 years ago I am not using use_frameworks! - I'm extremely happy to hear that others have successfully archived, that implies that I need to look a lot more closely at my setup. Given the variable in my setup that was independent was just the react-native-version I did not investigate much to start, rather I wanted to hear from others before spending a lot of time on it.
For now with multiple other people reporting success one may assume that it's something specific to do with my app and not cause for general concern. It won't be fast, but I'll investigate locally and if I discover anything notable, I'll certainly post it in case it helps others.
kelset
commented
3 years ago For now with multiple other people reporting success one may assume that it's something specific to do with my app and not cause for general concern.
yeah I agree, that's great to hear. Thanks @Arkkeeper & @tido64 for your reports!
kelset
commented
3 years ago hey folks, here's another update on the situation: @hramos' commit with the hotfix landed, but to cherry pick it without conflicts I had to go back in time and fetch a few more commits. This is the list of commits needed to make it cleanly pick (in chrono order):
We've cherry picked those, along with the CLI v6 bump (https://github.com/facebook/react-native/commit/54fbe0d2d63e086662478bfeeda1b9256ea0d6da) in the 0.65 branch.
On top of all of that, with @Titozzz we realised that on the 0.64 branch there was another reason why the issue reported by @mikehardy & @tido64 about the codegen generated files (React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec-generated.mm and React/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec.h) was not present. They were added manually by @grabbou before 0.64.0 was cut as empty files (you can read more about that in this comment) and then at a later stage they were "properly populated" by this other local 0.64 branch commit.
So, as an extra safety measure, we decided to look into doing the same in 0.65; this led us to this other commit from @hramos in which the two files were put in .gitignore https://github.com/facebook/react-native/commit/9218e0c2e635baf66dbb4b6628d6496ffb471568. This was probably motivated by the assumption that for RNTester pod install would always be run at least once. We have spent quite a bit of time today (actually, most of it) trying to get to the very bottom of this correlation of
generated files being there or not <-> ios build success/failure
Without too much success. But it's clear that if we replicate the 0.64 fix by removing the .gitignore line, in all scenarios for 0.65 those two files will be present (in a form or another) so that should ensure that ios builds will never hit the problem explained by Mike Hardy and Tommy. So here's the local 0.65 commit for that.
If all the above wasn't enough, there was one more problem šµ for reason even less clear than above, @hramos commit https://github.com/facebook/react-native/commit/98e1734451adf29cd6bdf4b378a3798a6d86da93 to put back react-native-codegen as a direct dependency breaks the Android pipeline (as you can see here). So we need to revert that one too.
Given that quite a few of these changes are not as clearly verifiable/understood by us, we decided to verify locally on two machines that this new state of 0.65-stable branch leads to a ā local E2E testing. We were also able to verify that flows that earlier would end up in the ios build error seems to be fixed.
So we are cutting an RC4 (that hopefully will have a shorter lifespan) to allow some of you to also verify the new state of 0.65; if everything goes well (š¤) this will be the last before .0.
kelset
commented
3 years ago Because of the above, let's move here https://github.com/react-native-community/releases/issues/242
This issue serves to track the status of work to reach 0.65.0.
Current latest: 0.65.0-rc.3
Left to do for 0.65.0
non code related
code related
Known issues
Commits (and PRs) to cherry pick
Non-blocking for RC release
Local commits to backport to main
Please limit your comments to reports of issues encountered with the RC and cherry pick suggestions. No ETA currently for when 0.65.0 will be released.