Performance Issues with React Native Bridgeless Architecture

[santhoshkumarvgds]

Description

The Bridgeless Architecture in React Native 0.74 and later introduces significant performance issues, particularly for apps with complex logic and high demands for UI responsiveness. Here are the main concerns:

Key Issues

1. Screen Load Times

• Problem: Synchronous communication with the native runtime slows down screen loading, particularly when multiple API calls are made.
• Impact: Initial loads are bottlenecked, reducing overall app responsiveness.

2. UI Responsiveness and Touch Lag

• Problem: The switch to synchronous communication impacts touch response, causing a laggy and less fluid user experience.
• Result: Reduced interaction quality and increased user frustration.

3. Lazy Module Loading

• Default Behavior: Bridgeless architecture loads modules lazily by default, contributing to delayed responses in complex pages.
• Partial Fix: Disabling lazy loading improves response slightly but doesn’t fully solve the underlying delay issues.

Comparative Performance with Older Versions

• Testing Results:
  • React Native 0.71.8 (asynchronous bridge): Modal with 32 API calls loads in approximately 3 seconds.
  • React Native 0.74.x / 0.76.1 (bridgeless): Modal with only 14 API calls takes over 10 seconds.

Attempts to Improve Performance

• Native Threads & Configuration Adjustments: Shifting API calls to native threads, and enabling/disabling options like Hermes and New Architecture, failed to yield significant performance improvements.

Call for Optimizations

The React Native community and core team are urged to provide optimizations or alternative solutions to enhance performance under the bridgeless architecture.

Feedback Needed: Community support and solutions for the architectural limitations causing these performance issues.

Steps to reproduce

1. Create a page/modal with 10-30 API calls.
2. Test in React Native 0.74.x or later (Bridgeless).
3. Measure load time and UI responsiveness.
4. Compare with 0.71.8 (Async Bridge).

Expected: Slower performance in the bridgeless versions.

React Native Version

0.74+

Affected Platforms

Runtime - Android, Runtime - iOS

Areas

Bridgeless - The New Initialization Flow, Other (please specify)

Output of npx react-native info

System:
  OS: macOS 14.5
  CPU: (8) arm64 Apple M1
  Memory: 206.23 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.14.0
    path: /usr/local/bin/node
  Yarn:
    version: 1.22.19
    path: /usr/local/bin/yarn
  npm:
    version: 10.7.0
    path: /usr/local/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods: Not Found
SDKs:
  iOS SDK: Not Found
  Android SDK: Not Found
IDEs:
  Android Studio: 2021.3 AI-213.7172.25.2113.9123335
  Xcode:
    version: 16.1/16B40
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.11
    path: /usr/bin/javac
  Ruby:
    version: 2.7.4
    path: /Users/santhoshkumarvgds/.rvm/rubies/ruby-2.7.4/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.0.0
    wanted: ^15.0.0
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.76.1
    wanted: ^0.76.0
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: Not found
  newArchEnabled: false

Stacktrace or Logs

The issue occurs when multiple API calls are made on initial screen load. The app becomes unresponsive and takes significantly longer to load the screen. Despite attempts to optimize by disabling lazy loading and using native threads, the issue persists. No crash or stack trace is generated, but the app's performance degrades considerably.

Reproducer

Reproducer: Unfortunately, I cannot provide a public repository or Expo Snack at this time. Please let me know if you would like further details or an isolated example of the issue.

Screenshots and Videos

No response

[react-native-bot]

Warning

Could not parse version: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2.

[react-native-bot]

Warning

Could not parse version: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2.

[react-native-bot]

Warning

Missing reproducer: We could not detect a reproducible example in your issue report. Please provide either:

• If your bug is UI related: a Snack
• If your bug is build/upgrade related: a project using our Reproducer Template
• Otherwise send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.

[cortinico]

Reproducer: Unfortunately, I cannot provide a public repository or Expo Snack at this time. Please let me know if you would like further details or an isolated example of the issue.

Yes we would need an isolated reproducer to look into this.

[arasrezaei]

I agree, there are lots of lags and crashes.
When I turn newArch off, the app is much smoother

[lovegaoshi]

i know this isnt particularly helpful to most others, but i also oberved performance degradation when migrating my app to bridgeless. my sprcific issue is react-navigation drawer opening is particularly choppy and wont switch screens completely. this is not exactly the rn teams fault, but the general DX/UX of our apps are still impacted

[JustJoostNL]

@lovegaoshi did you manage to fix that choppy drawer animation? The new architecture heavily slows down my app, is there any timeline for fixing this?

[lovegaoshi]

unfortunately no. im reliant on react navigation and react native paper, and both have minor but unacceptable UX issues that i could not upgrade to the new arch with. right now im reinventing the wheel to write my own ui lib and migrate away from these ui libs. given other important libs like rn firebase or notifee also breaks, its peobably the best to not chase the newest feature.

…

On Wed, Nov 13, 2024, 11:43 AM Joost ***@***.***> wrote: @lovegaoshi <https://github.com/lovegaoshi> did you manage to fix that choppy drawer animation? The new architecture heavily slows down my app, is there any timeline for fixing this? — Reply to this email directly, view it on GitHub <#47490 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZMOVVT3NCGMGDL4IRIDT732AOTXLAVCNFSM6AAAAABRLKPMCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUGU4TKMJRG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[YasinAkimura]

I can also confirm that the new arch is causing a few performance issues regarding responsiveness,
and I think react-navigation / expo-router are not ready for the new arch yet.

I can notice a significant lag in catching touch events when doing things quickly which may indicate the blocking nature of synchronous events?

Also a few bugs where Views seem to always fade / animate when layout changes or Text with adjustToFitSize and "unacceptable" lineHeight completely bug out but these are different issues.

[JustJoostNL]

Yeah the navigation and the overall responsiveness is horrible for me. I really hope this gets fixed because other than the performance issues, the new architecture is very promising. @santhoshkumarvgds are you able to create a minimal reproducible example?

[thespacemanatee]

I just wanted to add that on our project (which is quite massive but well-maintained), we also see significant performance degradations in debug mode on RN 0.76, even with the new architecture turned off. The problem might be related to hermes, which has steadily declined in performance over the past few releases. Can anyone confirm that 0.76 + new arch disabled also causes performance regressions?

[JustJoostNL]

I haven't tested without the new arch. But I can confirm that it's probably related to Hermes as the JS frames are very low which makes the app unresponsive.

[lovegaoshi]

okay, im probably able to provide a repo soon(tm). i have a MotionLayout equivalent component just built from scratch using reanimated and gesture handler, and new arch is noticably choppier than old.

…

On Thu, Nov 14, 2024, 10:49 AM Joost ***@***.***> wrote: I haven't tested without the new arch. But I can confirm that it's probably related to Hermes as the JS frames are very low which makes the app unresponsive. — Reply to this email directly, view it on GitHub <#47490 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZMOVVQCYXGRUJDMZ7BAZVD2ATWENAVCNFSM6AAAAABRLKPMCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZXGE3TEOBUHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lovegaoshi]

here for android. I have a MotionLayout (black bar at the bottom) that drags to expand to fullscreen. This is fluid with the old arch, new arch without expo's stack component, new arch with flatlist, but choppy with new arch and expo's stack or flashlist.

im not sure how useful this actually is, as this is an expo template (nowadays loaded with expo bloats. i used it for convenience) rather than a reproducer, and technically all react native components work as expected, just 3rd party libs are not.

not sure who to ping to get visibility.

[C0rren]

We have similar issues both in Android and iOS for our app running RN 0.76.2.

[katche70]

Unfortunately, I have to completely agree with this. I spent the whole week, full of anticipation and euphoria, painstakingly converting our app to the new architecture.
I am now completely disillusioned. There are a lot of places where you notice it's really stuck and you just can't get to the previous version on iOS. A lot of marketing for nothing. What a shame ☹️

[thespacemanatee]

@cortinico @cipolleschi any chance the React Native team can look into this with the reproducer from @lovegaoshi? It's not feasible for me to provide my company repo for obvious reasons, and creating a new project is not going to truly reflect the performance regressions in more complex applications. I find it hard to believe that Meta is using 0.76 internally unless it is really a case of user error, but it seems unlikely as many people are facing this issue.

To reiterate, here is my "minimally reproducing setup" on a complex application:

• RN 0.76
• Expo SDK 52
• Tried both New Architecture ON and OFF but performance impact is identical
• Tried both hermes-2024-11-12-RNv0.76.2-5b4aa20c719830dcf5684832b89a6edb95ac3d64 and hermes-2024-08-15-RNv0.75.1-4b3bf912cc0f705b51b71ce1a5b8bd79b93a451b but performance impact is identical

Performance is terrible on debug builds but seemingly faster than 0.75 on production, so the performance impact is only felt in debug mode. However, it makes for a horrendous development experience. Making changes and interactions take seconds.

I believe 0.76 has been the most insidious upgrade cycle because the changes according to the upgrade helper are minimal, but there are so many invisible moving parts under-the-hood that makes it impossible for us to have a reasonable timeline for any action items to pinpoint any sort of root cause. Many of us have to build features for our companies and upgrading should not be this tedious.

Although I greatly appreciate the work that the Meta team have put into this release, it has been an impossible one for us, and this is very worrying for the future of my company project due to the tight deprecation cycles in the React Native ecosystem.

[cipolleschi]

@thespacemanatee I'm so sorry to hear that it is not working for you.

I find it hard to believe that Meta is using 0.76 internally unless it is really a case of user error, but it seems unlikely as many people are facing this issue.

At Meta we use React Native from main, the latest commit available, and yes, all our internal app are using or are migrating to the New Architecture. We might have some extra fix that we shipped between the branch cut of 0.76 (beginning of September) and today, but I can't think of anything that might dramatically change the performances of the app running in Debug.

Is this happening for Android, iOS, or both of them?
One thing that we saw causing slowness in builds was the NDEBUG flag. Release builds have these flag set to true to skip some extra check we run in debug that might be expensive and that can slow down the app.

---

Without a reproducer is pretty hard for us to do any work. The issue you are facing might be coming not from React Native core but from some external libraries you are using.
We have evidence of big apps running smoothly (e.g.: Bluesky, which is a pretty big app, on Android) with the New Architecture.

Multiple people are reporting the issues, so I'm not downplaying them, I'm sure they are there and real. It would be quite helpful to try and find the minimum common denominator of the set of libraries or patterns that are causing the slowness.

[thespacemanatee]

@cipolleschi Thank you so much for the response.

Is this happening for Android, iOS, or both of them?

Both of them are slow in debug mode. Both are fast in production mode.

On our end, we will try to reverse engineer and determine whether an external dependency is causing this debug performance regression. The current list of dependencies we are using is reputable though as far as I can tell, comparing it against https://reactnative.directory/.

Also, CMIIW, but Bluesky is still using RN 0.74? Do they have a branch where they have validated that 0.76 + New Arch runs smoothly?

EDIT: They have a 0.76 branch that seems to be inactive currently, maybe someone from the team can chime in about the issues they are facing with upgrading.

[C0rren]

Small consolation, but for those of you running react navigation as your navigation package, it appears that native stack navigators run slightly faster than "normal" stack navigators for screen transitions.

[cipolleschi]

@thespacemanatee can you try something for me. On iOS, can you try to modify the node_modules/react-native/scripts/cocoapods/utils.rb file like this:

    def self.add_ndebug_flag_to_pods_in_release(installer)
        ndebug_flag = " -DNDEBUG"

        installer.aggregate_targets.each do |aggregate_target|
            aggregate_target.xcconfigs.each do |config_name, config_file|
-                is_release = config_name.downcase.include?("release") || config_name.downcase.include?("production")
-                unless is_release
-                    next
-                end
                self.add_flag_to_map_with_inheritance(config_file.attributes, 'OTHER_CPLUSPLUSFLAGS', ndebug_flag);
                self.add_flag_to_map_with_inheritance(config_file.attributes, 'OTHER_CFLAGS', ndebug_flag);

                xcconfig_path = aggregate_target.xcconfig_path(config_name)
                config_file.save_as(xcconfig_path)
            end
        end

        installer.target_installation_results.pod_target_installation_results.each do |pod_name, target_installation_result|
            target_installation_result.native_target.build_configurations.each do |config|
-                is_release = config.name.downcase.include?("release") || config.name.downcase.include?("production")
-                unless is_release
-                    next
-                end
                self.add_flag_to_map_with_inheritance(config.build_settings, 'OTHER_CPLUSPLUSFLAGS', ndebug_flag);
                self.add_flag_to_map_with_inheritance(config.build_settings, 'OTHER_CFLAGS', ndebug_flag);
            end
        end
    end

Then reinstall pods and try again?

What this does is basically to set the NDEBUG flag to every build config. This should disable some expensive runtime checks we are doing in debug mode to ensure the correctness of the framework. Those checks are disabled in production so that could be one of the causes why Debug is slower than development.

---

AFAIK, Bluesky made an Android release with the New Architecture that they asked users to try. I think they are also doing a phased rollout using the Play Store, but I am not completely sure.

[thespacemanatee]

@cipolleschi Thanks for the suggestion but unfortunately it's still as slow as before, though at least we can probably rule out NDEBUG as the root cause.

[cipolleschi]

To set expectation, I'll be off next week and @cortinico will be back on Thursday.

We will try to prioritize this once we are back.

[ustuncem]

Hello @cortinico thanks for the response. Are we doing something that we aren't supposed to then? Are these apps using packages like reanimated, gesture hander etc. from the example repo or are they using the Animated API directly from the react-native repo?

[talaikis]

What I am curious about is whether any other projects have experienced this during migration.

Each RN version since 0.72 is worse than version before in terms of performance mainly due to JS thread overload. Moving parts of heavy JS code to native improves things, but that's all with old arch. New arch never worked, a lot of lags, constant freezes, etc. Bridgeless crashes immediately after start. An app has a of libs, mostly from expo.

[lovegaoshi]

im unfortunately plagued by another performance issue (reanimated when using RN-video as a background element) so im back to this grind. but Ive resolved a performance issue b4, where react-native-navigation's drawer will recalculate its height every time even when hidden if you have an expandable element that resizes it, causing a performance degradation. in other words I have a miniplayer that expands, and a hidden drawer behind it; the drawer will cause severe miniplayer expand/collapse lag. fix is set the height in its style to be a constant number.

its a difficult problem that roots from meta, but ultimately caused by 3rd party libs that meta has no control over (or they elected to be, after meta spun out their libs to be 3rd party supported). unfortunately we are at this stage of pointing fingers where meta strictly only supports whatever their core lib is (which is actually fine by all means), 3rd party is often unmaintained (look at react-native-paper's new arch support fiasco, and many others that arent even doing it yet) and probably is fine until you and me the devs combine them in a weird manner, and all we saw is simply switching the newarch flag caused a huge performance degradation.

lastly there is probably nothing anyone can do except for you and me the devs. identify what element is lagging, literally remove everything else and decide if its still lagging; if so make it into a reproducer here. else slowly add the elements back. this is debug 101 that we all should be familiar of at this point. get the chrome profiler and start profiling.

=====
just confirmed I have yet another issue with expanding/collapsing a miniplayer with a view in the background with flex:1. fix is simple. throwing it out here in case it helps anyone. only happens to the new arch.

Screencast.from.01-14-2025.11.09.33.AM.webm

[cortinico]

Are we doing something that we aren't supposed to then?

Sadly that's kinda hard to say.

I'm reading this conversation daily and I'm seeing generic messages about 'performance regressions' between old and new arch, without metrics or actual proof that there is actually a regression.

Historically, we always had folks in the community sharing that newer version 'feels slower' than older one. However, we validated with our partners and with real metrics that this is not the case.

During 2023/2024 we fixed a number of performance regressions that were reported by the community, but those came with a isolated reproducer + with graphs showing how the framerate dropped before/after.

Sadly, just commenting on this issue saying that the app feels 'slower' is not doing any help. The best we can all do is isolate a reproducer and identify a small set of libraries or APIs that are regressing (if any) on the New Architecture.

[cipolleschi]

For performance in debug mode, we had a lengthy investigation on the Bluesky app that seems to point to the <Profiler> component.

If you are using this component in your app, can you try to remove it and report back whether it improves the performance? Meanwhile, we are investigating why this is slow and how can we improve it.

This could improve the performance when the app is in Debug mode, not in Release mode.

[hosseinmd]

We are not using the Profiler.
I sent a reproduced code above. Why you won't check it?

[rubennorte]

React Native 0.71.8 (asynchronous bridge): Modal with 32 API calls loads in approximately 3 seconds.
React Native 0.74.x / 0.76.1 (bridgeless): Modal with only 14 API calls takes over 10 seconds.

@santhoshkumarvgds just to clarify, what do you mean with N API calls? Are those network calls? Is the performance issue still reproducing for you if you don't make network requests?

(Btw, if they're network requests, dispatching 32 network requests in any client interaction seems like a bad pattern that will lead to a bad experience in general).

[kirillzyusko]

I created a new react-native project with new arch and added your login page. it has performance issue yet and app freeze after few seconds, but after i remove keyboard controller everything work perfectly.
i don't know why keyboard controller has this issue. @cipolleschi Could you check this package?

@hosseinmd @cipolleschi I'll have a look on that 👀

[kirillzyusko]

@hosseinmd okay, I took a project @ustuncem and pasted your code (keeping KeyboardProvider in place) - everything works well:

Screen.Recording.2025-01-16.at.19.36.11.mov

@hosseinmd may I kindly ask you to upload your project to GitHub and share a video what exactly you are doing to get a crash? Using your code I'm not able able to reproduce any freezes 🤷‍♂

Alternatively you can go to KeyboardProvider and remove lines one-by-one. KeyboardProvider simply receives keyboard/TextInput events and stores them as Animated/Reanimated values. Maybe frequent updating of these values trigger a crash?

[kirillzyusko]

@hosseinmd Okay, it seems like some styles were missing - if I add style={{ width: 200, height: 50, backgroundColor: 'yellow', marginBottom: 10 }} to BottomSheetTextInput then I can receive an application freeze.

After quick debugging it seems like it happens only if Reanimated handler is attached to a view (i. e. onKeyboardMoveReanimated={keyboardHandler} in KeyboardProvider).

I think it's reanimated issue, but I will try to debug it further tomorrow to have a 100% confidence in my words 🙂

[ustuncem]

@kirillzyusko thank you so much for looking into this.

[bartlomiejbloniarz]

@kirillzyusko This could be a recursive commit problem. There is a fix for that in the newest RN version.

[hosseinmd]

@bartlomiejbloniarz could you add the link of fix please

[bartlomiejbloniarz]

I think this PR might help, but I didn't check.

[kirillzyusko]

@bartlomiejbloniarz I confirm, if I update react-native to 0.76.6 then the issue is gone and app not freezes/crashes anymore.

@hosseinmd @ustuncem can you try to update RN to 0.76.6 and see if the issue is still present in reproduction and your projects?

[JustJoostNL]

The fix seems only for Android, so I assume this doesn't fix the performance problem in iOS debug builds?

[kirillzyusko]

@JustJoostNL the repro provided by @ustuncem contained information about Android issues only. I tested iOS and it works well there. Do you have a reproduction example which shows the problem on iOS?

[ustuncem]

@kirillzyusko @bartlomiejbloniarz hello, I will test it as soon as I can thanks for the update. I am not using any drawer navigation so maybe that's why my repro didn't experience any performance issues on iOS. As @lovegaoshi pointed out here:

im unfortunately plagued by another performance issue (reanimated when using RN-video as a background element) so im back to this grind. but Ive resolved a performance issue b4, where react-native-navigation's drawer will recalculate its height every time even when hidden if you have an expandable element that resizes it, causing a performance degradation. in other words I have a miniplayer that expands, and a hidden drawer behind it; the drawer will cause severe miniplayer expand/collapse lag. fix is set the height in its style to be a constant number.

its a difficult problem that roots from meta, but ultimately caused by 3rd party libs that meta has no control over (or they elected to be, after meta spun out their libs to be 3rd party supported). unfortunately we are at this stage of pointing fingers where meta strictly only supports whatever their core lib is (which is actually fine by all means), 3rd party is often unmaintained (look at react-native-paper's new arch support fiasco, and many others that arent even doing it yet) and probably is fine until you and me the devs combine them in a weird manner, and all we saw is simply switching the newarch flag caused a huge performance degradation.

lastly there is probably nothing anyone can do except for you and me the devs. identify what element is lagging, literally remove everything else and decide if its still lagging; if so make it into a reproducer here. else slowly add the elements back. this is debug 101 that we all should be familiar of at this point. get the chrome profiler and start profiling.

===== just confirmed I have yet another issue with expanding/collapsing a miniplayer with a view in the background with flex:1. fix is simple. throwing it out here in case it helps anyone. only happens to the new arch.

Screencast.from.01-14-2025.11.09.33.AM.webm

It maybe because of how views with uninitted heights interact with the parent content that is provided from @react-navigation/drawer. Another project that I am currently developing is migrated to react-native 0.76 without enabling the new arch. I also updated the react-navigation packages to version 7.x.x. I immediatly noticed performance issues even when not enabling the new arch. Drawer's opening and closing animations are extremely laggy on debug(Haven't tested in production yet.) but when downgrading drawer navigation to version 6.7.2, lags are gone. So this maybe about what changed in @react-navigation/drawer on version 7.x.x rather than a new arch problem. Should we open an issue there as well?

Edit:
This here is with react native version 0.76.6 and new arch enabled. @react-navigation/drawer version is 6.7.2:

Screen.Recording.2025-01-21.at.18.03.13.mov

This one here is with react native version 0.76.3 and new arch disabled. @react-navigation/drawer version is 6.7.2

Screen.Recording.2025-01-21.at.18.07.05.mov

[ustuncem]

Tested on iOS also:
With React Native 0.76.6, the new architecture enabled, and @react-navigation/drawer version 7.1.1:

Screen.Recording.2025-01-21.at.18.28.53.mov

With React Native 0.76.6, the new architecture disabled, and @react-navigation/drawer version 7.1.1:
https://github.com/user-attachments/assets/1a49e6a4-426c-4ec7-a0ac-65758a3f51b7

Disabling the new architecture significantly reduces flickering. I will try to provide a reproduction example for this issue. Unfortunately, I can't open source the project as my company doesn't allow it.

I'm unsure where to report this issue. Should I continue discussing it here, or should I open an issue in the react-navigation repository? Any guidance would be greatly appreciated.

[ustuncem]

I've been testing it for more than 10 minutes and issue seems to have been gone. No crashes/freezes happening on Samsung Galaxy S22. Thanks for looking into this. At least it seems like I can ship it in new arch now.

@bartlomiejbloniarz I confirm, if I update react-native to 0.76.6 then the issue is gone and app not freezes/crashes anymore.

@hosseinmd @ustuncem can you try to update RN to 0.76.6 and see if the issue is still present in reproduction and your projects?

[ustuncem]

Sorry for posting back to back but maybe this helps someone solve the issue here and I need to confirm if this is an expected behaviour. Enabling new architecture adds an extra 21 MB to release apks on Android. Is this valid?

Before enabling the new architecture:

After enabling the new architecture:

Before it was 107 MB and after enabling the new arch, apk size is 128 MB. Do we know what does that extra 21MB contain and where is it coming from?

[Antisane76]

Tested on iOS also: With React Native 0.76.6, the new architecture enabled, and @react-navigation/drawer version 7.1.1:

Screen.Recording.2025-01-21.at.18.28.53.mov
With React Native 0.76.6, the new architecture disabled, and @react-navigation/drawer version 7.1.1: https://github.com/user-attachments/assets/1a49e6a4-426c-4ec7-a0ac-65758a3f51b7

Disabling the new architecture significantly reduces flickering. I will try to provide a reproduction example for this issue. Unfortunately, I can't open source the project as my company doesn't allow it.

I'm unsure where to report this issue. Should I continue discussing it here, or should I open an issue in the react-navigation repository? Any guidance would be greatly appreciated.

@ustuncem with new arch enabled does disabling react-native-screens help with the flickering/performance? I noticed the flickering disappeared when using drawer version 6.7.2 on Android with enableScreens(false)

in root of project:

import { enableScreens } from "react-native-screens"
enableScreens(false)

[ustuncem]

Tested on iOS also: With React Native 0.76.6, the new architecture enabled, and @react-navigation/drawer version 7.1.1:

Screen.Recording.2025-01-21.at.18.28.53.mov
With React Native 0.76.6, the new architecture disabled, and @react-navigation/drawer version 7.1.1: https://github.com/user-attachments/assets/1a49e6a4-426c-4ec7-a0ac-65758a3f51b7

Disabling the new architecture significantly reduces flickering. I will try to provide a reproduction example for this issue. Unfortunately, I can't open source the project as my company doesn't allow it.

I'm unsure where to report this issue. Should I continue discussing it here, or should I open an issue in the react-navigation repository? Any guidance would be greatly appreciated.

@ustuncem with new arch enabled does disabling react-native-screens help with the flickering/performance? I noticed the flickering disappeared when using drawer version 6.7.2 on Android with enableScreens(false)

in root of project:

import { enableScreens } from "react-native-screens"
enableScreens(false)

Hello, thank you for the response. I will test it tonight and notify you.

[gaearon]

Perhaps react-native members think this is other packages responsibility because their bluesky app working correctly, maybe this should be clarified first of all.

Just to clarify, Bluesky app is not yet working perfectly with the New Architecture. We don't want to migrate until it runs at least as good or better, and for now it's not there yet. I've commented with latest issues we're discovering in bluesky-social/social-app#6755 so this will be an ongoing process until we can confidently cut over.

[LouisSyfer]

I'm experiencing significant performance issues on iOS since I upgraded from SDK 51 to 52. Already, I had to disable the new architecture (my application was literally broken). Then, the flashlist lost considerable performance. But still, navigating from one screen to another is sometimes tedious. Anyone else have this problem? Thank you for your feedback.

[cipolleschi]

Hi @ustuncem. Regarding

Before it was 107 MB and after enabling the new arch, apk size is 128 MB. Do we know what does that extra 21MB contain and where is it coming from?

I think that the answer is yes, it is expected (cc. @cortinico who has more Android expertise). The reason is that the New Arch is basically a rewrite of the Old Arch in C++ so we can share code between iOS and Android. The New Arch has some extra code that we need to build and that could account for those extra MB.

---

@LouisSyfer have you tried opening an issue on Expo repository?
Flashlist losing performance on the New Arch only or also on the Old Arch?

[LouisSyfer]

@cipolleschi hi ! No I did not open an issue on the Expo repository. But I talk about it on Expo Discord server. For the moment, I don't have any answer. And anyway I can't provide an Minimal reproducible example. All I can say : it's was working very well with expo sdk 51. And the loss of performance happens with the old and new arch. Only with my iOS app (on Android it works well!).
Something tells me this might be from reanimated. This wouldn't be the first time I've had a problem with this package when I upgrade an Expo sdk...