2022: How can we improve React Native?

[lunaleaps]

Update - Nov. 17, 2022

The survey is now closed.

This discussion will remain unlocked as there is still valuable feedback to be shared and its great to have it one place but do not expect team engagement.

We will be running another survey in 2023 and will reference any new comments here.

You can read the team's feedback to comments shared before Nov. 17th in this dedicated discussion.

---

Update - Nov. 1, 2022

Thanks everyone for all your feedback! I will leave this survey unlocked for now as there continues to be great discussion. We are actively reviewing your comments, drafting a reply which we hope to share by next couple of weeks. Thank you again!

---

The React Native team is looking for feedback to improve the developer experience of React Native. Our team has gotten so much value from past responses in 2019, 2018 (#64) — we had to miss 2020, 2021 😔.

This year, your input matters more than ever as we look to prioritize your feedback into our planning.

Guidelines:

• We’re excited to hear from you! Let’s keep conversation respectful and within our code of conduct.
• Scan through existing comments and upvote/downvote posts that also affect you. Feel free to comment and expand to provide more context.
• Please make one comment per issue so that feedback stays focused
• Keep your descriptions short and ideally link to other places with more context. See example post below:

[Example Issue] Cmd+R doesn’t work

React Native docs and the new app template all mention that cmd+r is the way to reload. On my simulator, cmd+r starts a screen recording as documented on this issue. This has been a huge source of confusion on my team when new engineers join and are mis-led and we’ve spent hours trying to debug it and we have a fix on our fork.

Example areas of feedback

• Tooling: Metro, Flipper, React DevTools
• Debugging, Profiling your apps
• Adopting React 18, TurboModules, Fabric, Concurrent features
• Developing for many platforms
• Upgrading
• Education, Documentation, Staying informed
• Contributing to React Native, community support

What happens next?

• We’ll leave this discussion unlocked for roughly two weeks (Oct. 25th, 2022). During and after, our team will closely review responses and attempt to consolidate issues to themes.
• After, we will share responses to each point, share our thoughts and how we plan to action on it.
• We hope build out and run this survey yearly to help us measure our progress and also share with our community. If you have feedback about this, feel free to also share!
• We also started a discussion about workflows in React Native, if you'd like to share yours! https://github.com/react-native-community/discussions-and-proposals/discussions/530

[sixpathdev]

UI Difference

React Native makes cross-platform development easy, but one feature I'd appreciate is if there are little to no difference in cross-platform looks. I think it's one edge flutter has when it comes to development, spending less time customizing the user interface across platforms.

[gochev]

the whole point is to have native widgets and they are different. If you want them the same just use a webview

[kevinvangelder]

React Native is intended to looks like the native platform by default. If that's a negative to you use a different library.

[intrnl]

I feel like it would still be good to have this option regardless, no?

[stanleyugwu]

I used to think It's an edge that flutter has, but lately I've realised it's a disadvantage. Having same looks on all platforms hurts UX badly.

Users need to have that "native feeling" when using the app and I guess that's the whole point of "Native" in React Native 😀

Think about it when the native alert dialog of iOS and Android are same-looking.

[likeSo]

I agree. Because it's very hard to find a component that both works on iOS and Android...

[tom-sherman]

CSS Features

Yoga has fallen behind modern CSS features such as grid.

[nandorojo]

Flex Gap is a huge addition to RN. Echoing my appreciation for the recent work there.

Some other gaps with CSS I find myself wanting regularly:

• fixed & sticky position

• Modern things like like mask and clip-path, as mentioned here

• Multiple shadows, as mentioned on the umbrella styles issue

• filter for things like blur(20px)

• All kinds of gradient backgrounds

[natew]

Some other big ones:

• display: contents - really important for attaching events to child components you don’t have control over without changing flex behavior
• shadows not breaking with overflow hidden
• Multiple shadows

[efstathiosntonas]

Bottom shadows only, without the need to wrap the element in a parent with overflow: hidden

[aliveornot]

Shadows that can be used consistently in android and iOS

[dmahajan980]

Text outline support on both Android and iOS.

[a7medev]

Upgrades

React Native upgrades have always been very painful and the react-native upgrade command doesn't work even for new apps, the upgrading experience should be easier.

[bogas04]

Solve this problem first, you drive quicker adoption.
Add other crazy features first, you cause segmentation.

[AtilaDev]

Agree! But Expo does upgrade very good recently. I use one command, expo upgrade from expo 45 to 46. It works like a charm. Try it.

But not all companies use Expo. It would be convenient if React Native works in a similar way to Expo in terms of version updates. Upgrading an app with Expo is a delight. I can't say the same for React Native CLI.

[yurykorzun]

I never use react-native upgrade because every project is different and I always do it manually by referencing https://react-native-community.github.io/upgrade-helper/. Lack of transparency in the upgrade process prevents using the upgrade command.

[lovetingyuan]

offer an easy way to get updates on the fly.

[varemenos]

Changes to project.pbproj are very easily missed/ignored when upgrading, and even if notice them, 99% of the time, the changes are very hard to comprehend or apply. References are being moved around and they generate unique IDs, files are added/removed, build scripts are changed, it's just chaos for someone that doesn't have a very concrete understanding of how iOS development works.

If React Native wants to improve it's upgrade experience, this is the #1 issue to take.

[aarongrider]

Enabling The New Architecture

Fabric & TurboModules are obviously the future of React Native, and a vital component of continued relevance.

Unfortunately the upgrade story is a non-starter for any app at scale using dozens of native packages that are either abandoned or unwilling to migrate. (abandoned packages are also a huge problem).

We need to find a story for these cornerstone apps, and ideally provide an upgrade path to enable the new architecture.

[kelset]

the "tracker" is here: reactwg/react-native-new-architecture#6

[ltcaosj]

Support legacy component in New Architecture app by a proxy or a virtualization layer. This will motivate people adopts the New Architecture much quicker and earlier.

[alexandrius]

Support legacy component in New Architecture app by a proxy or a virtualization layer. This will motivate people adopts the New Architecture much quicker and earlier.

This should get most attention tbf

[aarongrider-sx]

Support legacy component in New Architecture app by a proxy or a virtualization layer. This will motivate people adopts the New Architecture much quicker and earlier.

This would be ideal. Any ideas on the technical feasibly of this?

[zoontek]

@ltcaosj This could be amazing.

I maintain several libraries (react-native-{localize, permissions, bootsplash, etc.}) and don't really want to supports both architectures at the same time (at least, without a compatibility layer).
My current strategy is maybe to wait a bit until it's stable enough, ship a library new major version which is only compatible with the new arch. Users would have to stick to the previous version if they still use the previous one.

PS: It's currently quite hard to maintain RN libraries: The documentation is light (until recently, no guides for Kotlin / Swift), OS features evolves each year (the permissions changes, ugh), we often have to support multiple platforms: iOS, Android, but also the web, windows and macOS!

Focusing on maintainer DX could be a nice, necessary move.

[dylancom]

Add native UITableView (iOS) integration for lists. Which has much better performance than FlatList and extra features such as a A-Z list (sectionIndexTitles).

Large lists are a pain now.

[dylancom]

FlashList is still missing native features such as the sectionIndexTitles as far as I'm aware.
(A-Z list on the right which allows fast scrolling trough a large set.)
https://github.com/aksonov/react-native-tableview came pretty far but isn't maintained anymore unfortunately.

[NickGerleman]

react-native-tableview takes an approach that's good for performance, where list items are purely native components, controlled by props, instead of arbitrary complexity React components. So it gives you some styling options, and works for lists where items are just text and an image.

If React Native offered a similar API, would that fit the usages where folks are seeing perf issues? Or should we be spending the effort on lists which allow children to be React components?

[enahum]

items with dynamic height is a pain, specially trying to render initially a item on an index that it hasn't been already measured.

Ex: Say a list of 1000 items all with different heights (unknown heights like the posts in this discussion) and you want to render item 458 as the first visible item on the list.

[jacobp100]

https://github.com/jacobp100/react-native-tableview-list

[todorone]

react-native-tableview takes an approach that's good for performance, where list items are purely native components, controlled by props, instead of arbitrary complexity React components. So it gives you some styling options, and works for lists where items are just text and an image.

If React Native offered a similar API, would that fit the usages where folks are seeing perf issues? Or should we be spending the effort on lists which allow children to be React components?

We definitely want to leave React components as items. FlashList proofed that performant lists are possible(maybe with some constraints like fixed height), it's performance significantly superior to the FlatList.

[scarlac]

Debugging with Flipper

"How do I debug a RN app?" - The official answer is Flipper. However, anyone working with Flipper eventually experiences the same thing: Flipper is unbearably slow and buggy. Flipper is slower to boot than both Xcode and Android Studio.
Once booted, every click is an exercise in patience and luck. Expanding the "Disabled" plugins list may take a few seconds. The UI frequently freezes up for seconds. It ships with a log of plugins by default, but few of them are actually usable, e.g. "Headless-Demo", "Bridge-Spy", "KaiOS RAM graph". Even "Databases", which could be helpful, only works on Andriod, which isn't at all clear.

There's a very long list of bugs and useless warnings, e.g. "You're using an outdated version" which must be dismissed manually, socket warnings that cannot be fixed, clicking the settings icon doesn't open settings, dev menu button does nothing, screenshot button fails, plugin manager search doesn't show results that it should, it's hard to figure out what plugin maps to what GitHub project, plugins come with no instructions, and the list just goes on.

To sum up, when people ask me "What do you do to debug?" I simply avoid mentioning Flipper. The whole plugin arch is a nice thought but what we really need is a performant, bug-free, tool for a small set of problems that many have:

• Debugger
• Redux state inspector (reality is that many use redux, so even if it's a bit specific, this is an extremely useful tool)
• Database inspector (AsyncStorage, SQLite)
• App filesystem browser
• Network inspector
• ADB Logcat / Xcode logs

Improving the debug cycle would have an enormous effect on developing apps.

[declanelcocks]

Definitely one of the main pain points and something that a lot of devs coming from web development struggle with. On the web you have things like Profiler, debuggers, flame graphs etc. that are all helpful. On React Native issues with UI, animation, performance etc. can easily crop up and it's difficult to debug the root cause or measure improvements.

[abhay-rana]

yeah react-native flipper is not compaitable with the latest version of firebase

[Return-1]

You are not alone, every team/company i've ever worked with small to big has always had grievances with the DX experience ( a testament to how great RN is overall since they still use it ).

Debugging is hard. It's generally difficult understanding what went wrong, where in the code the error actually is and how to fix it. Not being able to debug properly ( including native side of things which is already arcane to most RN developers that aren't coming from a native background ) takes a lot of time.

P.S : Flipper also consumes so much memory as things are

[Bardiamist]

Flipper uses many CPU resourses so I don't used this
I still always have Reactotron in background
I'd keep Flipper if background if it will not load CPU much (and will fork with Firebase)

[birminghamallen]

Interesting. I need to learn more about flipper.

[irekrog]

• create a docs with cases and examples that developers can meet every day (like beta.reactjs.org)
• add examples related to different libraries, tools, problems: eg. store sensitive data like auth tokens etc. (like examples folder in next.js repo)
• more frequent updates
• better support for monorepos and different packages manager like pnpm
• nice to have would be videos on yt for every release with described changes

[EvanBacon]

Metro team is working on pnpm support cite.

[arasrezaei]

There is no way to specify items of context menu in textInputs ... I think it's pretty easy to implement and should be a prop for text input, like:
<TextInput contextMenu={[{title: 'remove', icon: myIcon}, ...]} withDefaultContextMenuItems={true/false} />

[fabOnReact]

An explanation of the requirement is in this StackOverflow code example.

• Adding the contextMenu prop to the TextInput component [{title: 'remove', icon: myIcon}]
• Adding ReactEditText API setCustomSelectionActionModeCallback (an example of implementation on StackOverflow)
• Trigger a JavaScript callback as done with onAccessibilityAction.

[niraj-khatiwada]

Native forms, better debugging information in Logbox, performant list, and better UI Inspector.

[pushpender-singh-ap]

1. Provide better support for control of every single pixel that is drawn on the screen like flutter control.
2. Provide support for watchOS and wearOS.
3. Provide better documentation for VR.

[alexandrius]

Use react-native-svg or skia.

[pushpender-singh-ap]

Use react-native-svg or skia.

But what about 2 & 3 points?

[AdityaPahilwani]

These are some things which I would like to be addressed and fixed.

• The new architecture is out, but there are no performance benchmarks to check on what benefits we are getting.
• No proper documentation if synchronous methods in new architecture can harm or have any penalties attached to it, bridge synchronous clearly mentions cautions around synchronous methods.
• No documentation around concurrent rendering in react-native, any benefit or benchmark to properly look upon.
• Document the native areas. for example, createContextInBackground was advocated in Parashurama's talk otherwise nobody knew about it.
• There are plenty of react-native packages on which many projects depend on, and all of them are abandoned becoming a big hurdle to migrate.
• Fix nested text accessibility issues.
• Please fix the Modal issues.
• Give better support to handle blob files.
• Please give us a nice performant list component.

[kelset]

@AdityaPahilwani can you add links for the issues you mention for nested text and modal?

[fabOnReact]

can you add links for the issues you mention for nested text and modal?

@kelset [a11y] Accessibility for nested text components #32004 (iOS)
facebook/react-native#32004

[fabOnReact]

facebook/react-native#32004 (comment)

VID_20221219_153333.mp4

[fabOnReact]

Please fix the Modal issues.

He may refer to the issue facebook/react-native#30097, which is fixed with facebook/react-native#34969. This comment includes a video and the explanation of the fix.

[arasrezaei]

Another issue:
Measure function (positions) of nested Text component returns 0 or undefined always, and not working And you should use View inside text.
And if you put a view inside a text component you will get a misaligned text.

[fabOnReact]

Hidden as Outdated

react-native uses android spans for nested text components https://developer.android.com/develop/ui/views/text-and-emoji/spans
There is a related issue facebook/react-native#30375

[fabOnReact]

Hidden as Outdated

#528

Similar issues have been reported in react-native. Text on Android is represented with TextView, while nested Texts are represented as spans (Images as TextInlineImageSpan).

The style prop does not apply to nested Text. A solution to this issue is supporting the style prop for Nested Text on Android. The issue has also been reported here. I will work on landing a series of PRs that add this functionality to react-native. The PRs will close following react-native issues (if you have an open issues in react-native, feel free to comment it here):

• [Android] textAlignVertical doesn't work on nested text #30375
• Nested Text on Android broken with fontWeight and fontStyle #34554
• Nested View and Text vertical alignment issue. #31955
• [Android] Bad fontFamily and color styles merging with 3 Text nesting levels #31826
• display: none style property ignored on Android for nested text #31717
• Image nested in Text only show half content part on Android. facebook/react-native#29559
• [Android] Custom fonts not applied on nested text facebook/react-native#20398
• Nested text with different lineHeight are cropped on Android facebook/react-native#30794
• Nested Text with onPress / TouchableOpacity Bug facebook/react-native#27549
• [TextInput] Nested Text Components not able to have different Colors [iOS] facebook/react-native#29584

[fabOnReact]

The parameters returned from the measure callback are calculated in TextLayoutManagerBuffer method measureMapBuffer. Changing the value returned in measureMapBuffer changes the callback parameters.

The functionalities are implemented as follows:

• measure callback is defined as a Spec of FabricUIManager.js (link)
• codegen generates native types for the measure Spec (more info in generator tests, parser tests, codegen implementation, generateMethods)
• The JavaScript implementation of measure is included in UIManager and FabricUIManager
• ReactFabric-dev.js adds the measure method to the prototype (ref) (more info in Eli commit)
• The JavaScript measure method calls the FabricUIManager.java measureMapBuffer (FabricUIManager => MountingManager => ReactTextViewManager => TextLayoutManagerMapBuffer)
• The measureText method in TextLayoutManagerMapBuffer already includes logic to calculate the position of attachments (inline images). A modified version could be used to calculate the position of nested text.

[fabOnReact]

The measure callback is invoked from CPP to Javascript:

Paper (bridge) - MessageQueue dispatches calls between JS and Native
The previous solution used nativeToJsBridge, getRuntimeExecutor and RuntimeExecutor.

The runtime is managed by a JSExecutor, which is created by a JSExecutorFactory, which is passed in to the bridge when it is constructed. Each type of JS VM has its own executor factory (JSC, Hermes, etc.). The JSExecutor is owned by the NativeToJSBridge, which ensures that all operations on the JS runtime take place on the JS message queue thread. The NativeToJSBridge is then owned by the Instance, which interfaces with platform-specific code.

Fabric (bridgeless) - UIManagerBinding method UIManager::get calls the #measure callback with the parameters x, y, width, height (in the screenshot, frame.width and height are passed from CPP to JavaScript).
The measure callback returns 0 for Nested Text because computeLayoutMetrics always returns EmptyLayoutMetrics.
Adding support for Nested Text requires the following:

1. Implement similar logic to the one in TextLayoutManagerMapBuffer #measureText. The logic in measureText calculates the position of the inline images and saves them in the attachments array. The logic loops around each Inline Image and saves x, y coordinates of each attachment in the attachments array. The x, y coordinates are calculated based on the text and the inline image height/width (more info in discussioncomment-4998056) https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/text/TextLine.java;l=386;drc=caabd536e8fea82b888902f359b33e637267966c;bpv=1;bpt=0
2. Modify computeLayoutMetrics to return the values above instead of 0 (see the section above about EmptyLayoutMetrics).

[rawrmonstar]

Better built in images and image caching. It seems strange to have to reach for a third party library like react-native-fast-image for something that the built in image component should be able to do by itself IMO.

[efstathiosntonas]

Or this one: https://github.com/georstat/react-native-image-cache

[todorone]

Please make Metro able to follow symlinks. This 5yo old issue was locked, but the problem is still there - we can't use pnpm in performant symlinks mode, and some other tools that use them w/o 3rd-party tools from MS(kudos by the way).

facebook/metro#1

[rawrmonstar]

Yes please! or at least have some way to do something like yarn link without having to hack your own solution together

[sleaper]

Totally agree! More history for this issue: pnpm/pnpm#1252 (comment)

[wallzero]

This should also help with monorepo support!

[kelset]

For those who are curious, the MSFT tool @todorone is referring to is: https://github.com/microsoft/rnx-kit/tree/main/packages/metro-resolver-symlinks 😉

[evelant]

Integrate WebAssembly

Integrating a WebAssembly runtime into react-native would greatly expand the options for developers to abstract their business logic into a cross platform library and to write more performant apps.

[evelant]

Bring metro up to modern standards or remove it in favor of more modern tooling

Metro lags quite far behind modern JS development tooling. Specifically some of the things it is missing:

• Symlink support (doesn't work well with monorepos which are widely used)
• Input source map support (if you compile to js first with other tooling metro won't consume the source maps properly)
• Better file watching (watchman gobbles memory, crashes a lot, watches files it doesn't need to)
• Performance (compared to esbuild or swc it's very slow)
• Documenation (there are options in the documentation which literally do nothing in the code)
• Standard package resolution support (metro doesn't support the "exports" standard in package.json, uses non standard react-native field)

Since metro is so far behind in so many areas perhaps the team would consider dropping it and instead adopting and contributing to a project like esbuild. I fail to see where metro delivers any value that isn't already surpassed by existing community tooling.

[tido64]

I think this was also mentioned elsewhere, but the Metro team is working hard to close the gap. For example, support for the exports field spec is being worked on: #534

cc @huntie @motiz88 @robhogan

[EvanBacon]

Everything you mentioned is being developed by the team at Meta.

We’ve started using Metro much more heavily at Expo. Expo just released beta web support for Metro along with the first ever native File System-based Router, built on Metro. These required some of the largest external contributions ever to Metro, which wouldn’t have been possible without the new Metro maintainers at Meta.

In regards to performance, Metro is actually so fast for subsequent bundling that it’s created an ecosystem which cannot be bundled any faster by other bundlers. Everyone ships untranspiled code in their libraries which must be bundled locally every time, this would take Webpack substantially longer and cause memory issues. Many other bundlers are fast by making assumptions about the web platform. We need better standards for library authors to ship transpiled code which the bundler can ignore, here’s an experimental look at how that might be done.

Metro is also leading the way in terms of subsequent bundling / advanced memoization. The general architecture of brand new bundlers like Turbopack are very similar to how Metro works.

But subsequent isn’t enough, production builds, CI builds, and many monorepo cases require fast initial bundling as well. Metro has a lot of room to improve here.

In regards to the whole native bundler movement. The Metro file watcher (watchman), is already native, the AST parser uses Hermes (WASM) parser (not on by default), and the transpilation could be swapped to SWC in user-space with a custom transformer, but due to the massive size (swc is ~58MB) it probably shouldn’t be added by default, this is why Vite uses Babel by default.

You can also swap the minifier over to ESBuild for substantially faster production bundling.

——

The future of Metro (over the last few months) has been looking really bright. We’re excited to help make it better at Expo. There’s still a lot of work to do, but fundamentally there’s nothing preventing Metro from being one of the fastest bundlers in the JS ecosystem.

[evelant]

Thanks for all the details! I'm looking forward to seeing metro get some love. It's been a source of pain for a long time and those pain points when solved by community PRs never got merged (6 years and counting on a PR for symlink support IIRC). If the project starts moving again it could make the react-native dx overall a lot nicer.

[dmahajan980]

Excited to see Metro being pushed forward. I wish if the Metro team can also provide support for tree shaking in the future.

[IvanIhnatsiuk]

Add dimiss method for ActionSheetIOS and Alert.

Many applications have these components and can implement autologout functionality after some time and Alerts/ActionSheet remain on the screen :(

So, It would be very cool to have such a method to fully manage these modules 🙂

[jamesxabregas]

Improve the Image component

...or make react-native-fast-image part of core.

There are some fairly well documented issues with the Image component.

For network images the caching functionality only works on iOS and even then testing would indicate that it doesn't work particularly well. Also a change of screen orientation frequently causes a tearing appearance on image re-renders.

As a result most projects use react-native-fast-image instead. Seems to me it should be merged into core and maintained properly.

[alanjhughes]

I would agree here. It doesn't go against lean core, you'd just be improving the implementation of the the provided image component

[romantseg]

react-native-fast-image is great, but it has some significant memory issues on Android, which haven't been resolved. But yeah, improving Image component would be the most ideal

[jamesxabregas]

Yes, this is what I mean by maintaining it properly. react-native-fast-image has a number of open issues that still haven't been resolved... but even then the vast majority of the React Native community still uses it over the core Image component which is why I suggested bringing it into core. If there is a better way of improving the Core Image component well then great, that's up to the core development team to decide, but ultimately I think we just really need a rock solid Image component that handles caching properly out of the box. It's such a fundamental requirement of any app that we shouldn't need third party libraries.

[romantseg]

@jamesxabregas definitely agree, assets management is an issue in React Native for sure

[varemenos]

project.pbproj is a major PITA

Changes to project.pbproj are very easily missed/ignored when upgrading, and even if notice them, 99% of the time, the changes are very hard to comprehend or apply. References are being moved around and they generate unique IDs, files are added/removed, build scripts are changed, it's just chaos for someone that doesn't have a very concrete understanding of how iOS development works.

If you want to see a practical example of this, check the changes to project.pbproj between 0.67 and 0.68 via the RN upgrade helper:

• AppDelegate.m was deleted and AppDelegate.mm added, they act like two different files inside Xcode and it generates two different ids for them.
• The build phase scripts have changed (this is not mentioned anywhere).

If React Native wants to improve it's upgrade experience, this is the number 1 issue to tackle.

I left a comment regarding this in one of the "Upgrade needs improving" thread, but I think this is important enough to deserve it's own thread.

[Baraa-bi]

• Change the way we should open the dev-menu instead of shaking the device (maybe as Flutter)
• Third-party packages that are highly demanded should be added to react native and be well maintained.

[efstathiosntonas]

Totally agree, there’s a package for this: https://github.com/pie6k/react-native-dev-menu-on-touch

[lunaleaps]

Thanks everyone for all the great feedback. We've gone through all the comments and took time to digest them and are also using this feedback to directly influence our planning for next half. There is a lot of work to be done and keeping the conversation going is a large part of it!

We've shared our thoughts on the major points raised: #546 (comment)

Please take a read and let us know what you think

[lunaleaps]

Edit: I'm going to unlock this conversation as we still have people contributing more areas of improvement and we do want to funnel this feedback to one area for easier lookup.

Although to clarify, since the survey is not actively open, please do not expect team feedback.

We are planning on doing this again next year. Once the 2023 survey comes out we'll also review any new comments here. Thanks!

[likeSo]

Just sharing some of my real feelings when using RN (I am using both RN and Flutter):

• I've never used a debugger, not because I don't need it, but because it sucks, especially when using 3rd party editors
  • Every time I encounter an error, I have to look through my code line by line, otherwise it will be difficult to find the bug
• The stability of the RN App is not ideal, it still crashes, while the Flutter App hardly crashes
• I'm having a hard time finding a component that works well on both iOS and Android platforms
• For now, react-native-macos, react-native-web, and react-native-windows are almost unusable, because too many components are incompatible, and the styles of each platform are also very different. Almost every step will encountered an error
• Upgrading the RN version is a pain unless you use Expo
• When I have a new requirement, I always spend a lot of time looking for solutions or components. In many cases, one component library cannot meet the requirements, and multiple component libraries must be used. For example, I used both Native-Base and react-native-paper
  • But the problem of multiple component libraries comes, the styles of different components are inconsistent
  • While Flutter can almost easily take out a ready-made component from the standard library
• I have to do a lot of work to optimize performance, such as long list performance optimization, in contrast, I never have to do this when developing Flutter, I think performance issues are one of the reasons why most people choose Flutter instead of RN
• Configuring the RN Android development environment is a scary thing, unless you use Expo
• keyboard handling is also a nightmare, although there are many solutions, they are not ideal
• As far as I know, most third-party frameworks are discontinued or slowly maintained

[shokimble]

Hey - I think a lot of your questions can be addressed elsewhere and aren't issues with RN. Try Reddit or one of the Discords etc.

Good point on third party support of all platforms though.

[likeSo]

Well. I don't think this attitude helps RN improve at all. In other words, why doesn't Flutter have these problems while RN does?

You can also read this: https://stackoverflow.blog/2022/10/31/comparing-frameworks-for-cross-platform-apps-flutter-vs-react-native/

This blog said

Flutter always had what I needed and it worked perfectly. React Native pointed me to an NPM package and a Stack Overflow answer and said “good luck.”

Just describing some of my feelings during daily development

[shokimble]

I was trying to be helpful to you and keep the noise down here at the same time.

You posted usage based questions and issues that can be answered. It's not about Flutter vs React Native or anything that's lacking in React Native.

[likeSo]

The title of this channel is "How to Improve RN", so I compared and listed which places are not doing well.

Because I believe that many people have encountered the same problems I encountered. At present, these problems may eventually be solved, but the cost is much higher than that of Flutter, and it is not necessarily perfect.

I have raised and voted for many feature-requests on this site, but never got a response. If you don't like it, you can pretend I didn't say anything. But if we really want RN to be improved, we should pay attention to these voices and user experience

[badasscodr]

Make it rusty to tackle so called JavaScript bridge. There are two ways to install a single project. If you ditch expo cli for React native cli, it will also improve ecosystem.

[usrbowe]

🧰 Developer tools: Flipper 🟣

I would like to propose a change to the way React Native uses a Flipper developer tool.

Currently it's using native dependency to establish the connection&communication channel. This adds on the build time of app and also sometimes caused issue with production builds containing Flipper SDK.

It also doesn't provide a full fledge support to all devices, as it's relying on the certificate exchange + it depends on idb for iOS devices (which is rather unstable).

JS based connection model

I've recently migrated to use a JS based connection model over WS. This only requires the JS side of RN project to add js-flipper package and it doesn't limit support of any specific device.
This approach can also be easily reused for react-native-web and other react-native like libraries.

So I would like to mainly open discussion for this approach and clarify any questions.

[cortinico]

This adds on the build time of app

I'd say that the build time impact on the apps is negligible, at least on Android. Moreover, adding js-flipper as a dependency on the package.json will come with a cost at install time so the benefits on this point are limited.

[usrbowe]

Actually the main issue is the support for all devices. I don't think Flipper is currently at the stage, where we can easily connect iPhone devices (idb is really unstable in terms of discovering devices and be able to help exchange certificate), all Android devices (lot of time Samsung device would reject the certificated exchange)

[mfbx9da4]

Multithreading

Multithreading is fundamental to building performant mobile applications and currently a major limitation of RN. NativeScript support workers, RN should do the same. Without workers, a whole class of apps which do heavy processing and are offline first are ill suited to RN.

Related to this feature is that all high performance RN UI libraries such as reanimated take great pains to support an API which can control the main UI thread synchronously from Javascript. RN should also facilitate a way to run synchronous JS on the main thread.

[jfaq89]

How is this not on top?

[Leandro201927]

As a new member of the world of react native, I really assumed that this was already implemented, what a big surprise I get when I realize that it does not exist.

[migueldaipre]

Do we have any news about this?

[kyimoemin]

RN team should focus on this, Flutter has it.

[vksgautam1986]

agree

[gomes042]

Some ideas

• borderRadius percentage (%) support Percentage units (%) support on borderRadius style property 🚀 #577

• Workers 2022: How can we improve React Native? #528 (comment)

• Better debugging tools 2022: How can we improve React Native? #528 (comment)

• JSI C++ Documentation

• New styling viewport units (like vw, vh, vmin and vmax) without external hooks Viewport Units (vw, vh, vmin, vmax) support 📐 #576

• Encouragement for React Native Web library, highlighting the possibility of creating cross-platform applications (web, android, ios) sharing the same code (may also creating an official monorepo boilerplate or start guide)

• Metro symlinks resolver 2022: How can we improve React Native? #528 (comment)

• NavigationBar Component for Android (Since there is StatusBar) Why doesn't React Native offer native support for changing the color or visibility of the "NavigationBar" for android? #279

• fontSize percentage (%) support Percentage units (%) support on fontSize style property 🚀 #578

• background support strings like linear-gradient() and others

[passengerV]

Idea about connecting the Simulator/Emulator UI inspector with the Code editor

(If there is already an existing solution, please let me know)
I think it would be really useful during the UI component inspection on the Simulator/Emulator (with the help of RN Debug Menu Inspector) to have an option to open the selected component's source file in the code editor.
While inspecting a component with the Inspector a component tree and UI properties are revealed. In case the selected component requires some adjustments, a Show source button would be really useful from developers perspective as it would cut the component look-up time in the code editor. Whats are your thoughts on this?

[AlirezaHadjar]

There's this bug with Text inputs in scrollviews on Android. TextInput prevents scrolling on ScrollView within its boundaries.

I wonder why it hasn't been fixed in the last 4 years. Are there any native limitations? It would be great if anyone in the core could respond.

facebook/react-native#25594

[vksgautam1986]

Do we have survey for 2023 RN improvement ?