Road to v0.65.0 - RC3 phase #238
Comments
kelset
added
rc
|
Cherry pick request: facebook/react-native@41f45a7 Flipper Pod >= 0.94 has a fix for incorrect timestamps in the network tab in iOS apps |
|
Found a few iOS issues:
I've tried using Xcode 13db3 and CLI. Upgrading flipper did not help, if that's the issue.
error (and another file, missed the name) as in facebook/react-native#31179 (comment). |
|
And the android ones:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Thanks @ivanmoskalev, I just sent the apk as a -- 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:
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:
This was without Hermes enabled. I tried running a release version (simulator) but I got the folly issue:
Environment details: p.s. I tried using this facebook/react-native@b77948e 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 facebook/react-native@f31c610. 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 However I wasn't able to build with Hermes, and getting the I tried the latest version from folly, same thread_local issue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@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. |
|
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. |
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)? 🤔
Oh wow I wasn't aware of that, do you know if they are tracking progress on that anywhere?
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 |
|
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. |
|
I am very sorry for not providing that info.
Please let me know if there's anything else I can provide. |
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. |
|
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... software-mansion/react-native-reanimated#2245) |
|
Haven't run this on Apple Silicon yet, but this shows success from Only issue I detected was that I needed to torture test / RNFB integration demo: https://github.com/mikehardy/rnfbdemo/blob/master/make-demo.sh |
|
There's a summary below. I have successfully gotten this whole shebang (mikehardy/rnfbdemo@37dbe67#diff-3e27ae623577d0c559bd8ab973a0c34af8cc65ef9beb9868a9cdb029854f8078) to work on Apple Silicon from scratch now. Apple SiliconApple 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 (facebookarchive/react-native-fbsdk#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
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? 🤷 - 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. Android Gradle Plugin 7 compatibilitySeparately, it's worth mentioning that react-native 0.65 has the only patch I think was necessary for android gradle plugin 7 support (react-native-community/cli#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 betasXcode 13 betas are unverified. Anyone check those? iOS build fails if you adjust iPhone minimum deploy versionI have a stanza in my Podfile where I converge all build targets iPhone minimum deployment version to my apps version. I set do this in post_install
That appears to be the root cause of this bug + functional version-downgrade workaround in: Flipper facebook/flipper#834 (comment) 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 "Looks Good To Me"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. |
Xcode 13
That's all I've been testing, actually. See my first comment for the issues with it. iOS IssuesWell, for whatever reason, adding @mikehardy's Specifically, it fixed all the errors that stemmed from |
|
@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 |
|
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. |
|
@SConaway I do not confirm your issue using My react-native-firebase from-scratch install succeeds when using that version as my Xcode via download+unzip-to-Applications+ That's on an Intel mac, doing a release build. 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 |
|
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 |
This comment has been minimized.
This comment has been minimized.
|
ok, I'm trying to catch up with everything, let's see if I manage to not forget anything:
|
@mikehardy, @kelset: This seems to be caused by Running Running I think the fix is the move the generation step to |
|
The Have you checked |
|
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 As for |
|
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. |
|
@hlspablo you can read about it here https://github.com/facebook/react-native/blob/main/CONTRIBUTING.md#our-development-process |
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:
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 |
|
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 |
|
on the other pending topic of |
|
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: Hermes was working on this project on Intel macs while using react-native 0.64.2 I've tried the standard cleaning ( 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 ? |
|
Something I've just noticed while following the upgrade helper to try an RC3 upgrade...
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? |
|
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 |
|
@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 |
|
@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? |
|
@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 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. |
|
@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? |
|
@mikehardy Can you share more info about your setup? I tried locally and successfully created an archive using 0.65.0-rc3, |
|
I am not using 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. |
yeah I agree, that's great to hear. Thanks @Arkkeeper & @tido64 for your reports! |
|
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 (facebook/react-native@54fbe0d) 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 ( 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 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 facebook/react-native@98e1734 to put back 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. |
|
Because of the above, let's move here #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.
The text was updated successfully, but these errors were encountered: