Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46168
## This Diff
This removes the legacy path from ReactScrollView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61658081
fbshipit-source-id: d6db43e25faf8e1ebd42d2816c7a915b3ed9404e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46161
## This Diff
This removes the legacy path from ReactHorizontalScrollView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61658082
fbshipit-source-id: 98cab5dfcad8beee6d131fcfe122313730a6f665
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46162
## This Diff
This removes the legacy path from ReactEditText and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61658080
fbshipit-source-id: 6ac7c5ed230e44fe307640a730e076b903e0674a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46171
## This Diff
This removes the legacy path from ReactTextView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61658083
fbshipit-source-id: b753d4eb45091aa31ea870a684c35b71c1ee5036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46159
## This Diff
This removes the legacy path from ReactViewGroup and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61657251
fbshipit-source-id: 6d00a1cac79450d306cf28446e6397d31ceffb19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46167
## This Diff
This removes the legacy path from ReactImageView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61657253
fbshipit-source-id: 96cf1160e466de78c2f133f0e4fb2d9b2e7cf478
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46524
There's an interesting behavior in Animated where we effectively perform an O(N + M) traversal of the Animated graph, calling `__makeNative` on each "input", which in turn tends to call `__makeNative` on each "output" (so we revisit the current node M times when calling `__makeNative` on the M inputs). In practice, the behavior is still O(N), because M is small and finite (most Animated nodes have 1 or 2 inputs).
All that said, some platforms (e.g., react-native-windows) rely on this revisiting behavior, where on the first visit, we recurse the node to its inputs, and on the subsequent visit, we update the `_platformConfig` value without recursion (see https://github.com/facebook/react-native/pull/32736 for the original change adding platformConfig).
A recent change to AnimatedWithChildren (https://github.com/facebook/react-native/pull/46286) eagerly invokes `__getNativeTag` on AnimatedWithChildren in the initial recursion step, which forces materialization of the NativeAnimated node *before* it's `_platformConfig` is set.
There is certainly some refactoring that needs to be done to improve all this, but for now, this change reverts to delay the call to `__getNativeTag` until after at least one `__makeNative` occurs on an input.
## Changelog
[General][Fixed]: Order of operations related to platformConfig propagation in NativeAnimated
Reviewed By: yungsters
Differential Revision: D62768179
fbshipit-source-id: ca9d911503e0630bc3a1309b21f9686aa77ac8b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46509
With ARG_DISABLE_HOST_LIFECYCLE_EVENTS it's possible to conditionally set mDisableHostLifecycleEvents when the ReactFragment gets created.
## Changelog:
[Android][Fixed] ARG_DISABLE_HOST_LIFECYCLE_EVENTS in ReactFragment to allow unmounting a surface without destroying ReactHost.
Reviewed By: rozele
Differential Revision: D62714185
fbshipit-source-id: b6518ff67a9644421b8fe9c7cdc2aa6d62a23651
Summary:
This PR adds an ifdef to declare `supportedInterfaceOrientations` only on iOS as this property does not affect other platforms causing a build issue.
## Changelog:
[IOS] [ADDED] - declare supportedInterfaceOrientations only on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/46512
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D62754746
Pulled By: javache
fbshipit-source-id: e2ca5d96cba87e611c48a87f10bf7831e9051646
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46508
Changelog: [internal]
This cleans up the "fixMissedFabricStateUpdatesOnAndroid" feature flag and enables the fix permanently.
This fixes some state updates in the Fabric shadow tree being missed in some edge cases.
See https://github.com/facebook/react-native/pull/45236 for context.
Reviewed By: rshest
Differential Revision: D62743019
fbshipit-source-id: c24ab8a49a97ca26e60efa2fa4bc6a21ccac52d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46515
Changelog: [internal]
This reduces the depth of the Systrace/Perfetto blocks by 1 removing this unnecessary nesting. If for some reason `ShadowTree::tryCommit` runs more than once, it will still show up.
Reviewed By: bgirard, sammy-SC
Differential Revision: D62499855
fbshipit-source-id: 48cce7532a308221c22d04de874870be509fe315
Summary:
This PR removes `available` for `RCTKeyWindow` after minimum version bump to iOS 15 this check is not needed anymore.
## Changelog:
[IOS] [REMOVED] - remove available for RCTKeyWindow check
Pull Request resolved: https://github.com/facebook/react-native/pull/46510
Test Plan: CI Green
Reviewed By: rshest
Differential Revision: D62752434
Pulled By: javache
fbshipit-source-id: 7b7745d4f27128cdb66053f7fa1cc234435eac31
Summary:
Solves these issues:
- https://github.com/facebook/react-native/issues/18398
- https://github.com/facebook/react-native/issues/12478
Solves this proposal: https://github.com/react-native-community/discussions-and-proposals/discussions/774
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [ADDED] - added overlayColor prop to modal component for customisable background overlay
**Motivation:**
Currently, the React Native Modal component only allows the background to be set to either `transparent` or `white`. This limits the ability to dim the background or apply custom colors, which is essential for creating a more polished and user-friendly interface.
**Change Log:**
Modal Component Enhancements:
- Introduced a new optional prop `overlayColor` to the Modal component.
- Updated the background color logic to prioritize `overlayColor` when transparent is `false`.
- Ensured backward compatibility by defaulting to `white` when `overlayColor` is not provided.
Pull Request resolved: https://github.com/facebook/react-native/pull/46322
Test Plan:
- Test the changes on both iOS and Android devices/emulators to ensure consistent behavior.
- Added example in **rn-tester** app
**Sample screenshot with custom overlayColor passed as 'red'.**
Reviewed By: cipolleschi
Differential Revision: D62201559
Pulled By: alanleedev
fbshipit-source-id: e990d7f18f5edf61f0107026ea899c5f22d47bfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46506
Changelog: [Android][Fixed] Fixed incorrect scroll event/position for scroll views when doing a smooth scroll animation.
We tested this in production and the fix is safe to land.
Reviewed By: rshest
Differential Revision: D62738925
fbshipit-source-id: e1198dac76cf850dfa76a5cee1ef205d5b367d19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46511
changelog: [internal]
task is not used after this line of code. Let's avoid copy shared_ptr's copy constructor.
Reviewed By: rubennorte
Differential Revision: D62751612
fbshipit-source-id: 92b0da44972b200870ef66f3a8482fbde55052ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46462
While adding D62583337, I noticed that `react-native` doesn't specify `babel-jest` as a dependency, despite referencing it in the included `jest-preset.js` — instead this would need to be installed by the template/project.
If we want to change this in future, we should consider a separate `react-native/jest-preset` package. However, I strongly believe this is the right location for this dependency: installing `react-native` = all parts of it work.
(Note that in the React Native monorepo, we are using `dependencies` for both dev and runtime deps in packages.)
Changelog: [Internal]
allow-executable-binary
## allow-executable-binary: Bypassed as this is a managed JavaScript dependency that is pre-existing in other parts of the codebase
Reviewed By: robhogan
Differential Revision: D62583665
fbshipit-source-id: 8bbcc8736e2740e45793d7b7e225ccfd1ca7f898
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46502
changelog: [internal]
At the moment, Linking module has undocumented restriction that if you call it twice when Android Activity is not available, it will return with an error.
This is unnecessary and can be handled more sensibly.
Reviewed By: javache, yungsters
Differential Revision: D62708123
fbshipit-source-id: 79a6beb70e834e631f7bedaf6a64076b050a7daa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46484
We recently realized that we don't have TS types for Codegen.
These are needed to let our users use these types when writing Specs in TS
## Changelog
[General][Added] - Add CodegenTypes for TS
Reviewed By: christophpurrer
Differential Revision: D62644516
fbshipit-source-id: 92bb7e8998d31806f6eb63319fb6d406fcd65ad8
Summary:
Following one of my previous PRs: https://github.com/facebook/react-native/pull/45176 I'm adding same conditionals to another module.
StatusBar API is supported on this platforms:
| Platform | Support |
| ------------- | ------------- |
| macOS | ❌ |
| tvOS | ❌ |
| visionOS | ❌ |
| iOS/iPadOS | ✅ |
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [ADDED] - Conditionals for iOS only code in RCTStatusBarManager.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/45896
Test Plan: CI Green / Make sure everything works as before
Reviewed By: cortinico
Differential Revision: D62579943
Pulled By: cipolleschi
fbshipit-source-id: 0c198c7732d253993638d825ca83be076bb09b90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46452
`babel-plugin-codegen` transforms `codegenNativeComponent`s by expending it with a whole set of many commands (~40 lines) that don't have a good equivalent on the source file.
Currently these lines are pointing to random parts of the due to a bug that causes the source maps to be incorrect and confusing.
Instead, I point all these generated lines of code to the default export as the only line that can represent them.
This way, if an error is thrown from that generated code it would point to that export.
If the users are confused by how it works, there's a comment in the function that is used in the default export in these that explains it:
```
// If this function runs then that means the view configs were not
// generated at build time using `GenerateViewConfigJs.js`. Thus
// we need to `requireNativeComponent` to get the view configs from view managers.
// `requireNativeComponent` is not available in Bridgeless mode.
// e.g. This function runs at runtime if `codegenNativeComponent` was not called
// from a file suffixed with NativeComponent.js.
function codegenNativeComponent<Props>(
componentName: string,
options?: Options,
): NativeComponentType<Props> {
```
The transformation is from all the types and exports after the imports:
[`MyNativeViewNativeComponent` for example](https://github.com/facebook/react-native/blob/773a02ad5d3cc38e0f5837b42ba9a5e05a206bf9/packages/rn-tester/NativeComponentExample/js/MyNativeViewNativeComponent.js#L4)
Which is roughly (ignoring all typing):
```
// types and exports
export const Commands: NativeCommands = codegenNativeCommands<NativeCommands>({
supportedCommands: [
'callNativeMethodToChangeBackgroundColor',
'callNativeMethodToAddOverlays',
'callNativeMethodToRemoveOverlays',
'fireLagacyStyleEvent',
],
});
export default (codegenNativeComponent<NativeProps>(
'RNTMyNativeView',
): MyNativeViewType);
```
to roughly:
```
var React = require('react');
var nativeComponentName = 'RNTMyNativeView';
var __INTERNAL_VIEW_CONFIG = {
uiViewClassName: 'RNTMyNativeView',
bubblingEventTypes: {
topIntArrayChanged: { /* */ },
topAlternativeLegacyName: { /* */ },
},
validAttributes: {
opacity: true,
values: true,
...require('ViewConfigIgnore').ConditionallyIgnoredEventHandlers({
onIntArrayChanged: true,
onLegacyStyleEvent: true
})
}
};
var _default = require('NativeComponentRegistry').get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
var Commands = {
callNativeMethodToChangeBackgroundColor(ref, color) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToChangeBackgroundColor", [color]);
},
callNativeMethodToAddOverlays(ref, overlayColors) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToAddOverlays", [overlayColors]);
},
callNativeMethodToRemoveOverlays(ref) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToRemoveOverlays", []);
},
fireLagacyStyleEvent(ref) {
require('RendererProxy').dispatchCommand(ref, "fireLagacyStyleEvent", []);
}
};
exports.default = _default;
exports.__INTERNAL_VIEW_CONFIG = __INTERNAL_VIEW_CONFIG;
exports.Commands = Commands;
```
Changelog: [Fix] Fixed source maps in Native Components JS files that use codegenNativeComponent
Reviewed By: robhogan, huntie
Differential Revision: D62443699
fbshipit-source-id: 522b4382736a8fed93a1bc687a78d6885fe7c9d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46473
This diff extends the renderer of react native to ensure that pre-allocated views that were never mounted on the screen are deleted as soon as the shadow node is deleted from JS
This feature is controlled by the ReactNativeFeatureFlag: enableDeletionOfUnmountedViews
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D62559190
fbshipit-source-id: 1af6785fc57256d12750db64489c9ecc6cf98c9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46488
React.Ref includes string | number to support legacy string ref, which will be killed in React 19. Therefore, the type is deprecated in Flow. This diff changes the type to use React.RefSetter instead.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62649800
fbshipit-source-id: 81bcfbb052e2039b23829dac8de242bfb0fdca3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46498
Looks like this is still necessary because we still run into this error when using the Components tab when using React DevTools:
> TypeError: cyclical structure in JSON object
This effectively reverts https://github.com/facebook/react-native/pull/46382.
Changelog:
[General][Changed] - AnimatedNode (and its subclasses) once again implement `toJSON()`.
Reviewed By: javache
Differential Revision: D62690380
fbshipit-source-id: d5b7c1d156b49838abefe48a7d7b61471cc3488a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46500
We're in the process of adding the required native component to all apps we maintain.
Until that is fully completed, fall back to using View if the native component
doesn't exist.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D62701331
fbshipit-source-id: d26c946af3a68231d0714e89d5e41be311399036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46469
This causes VS Code to syntax highlight incorrectly, so let's use a type alias to workaround that limitation.
Changelog:
[Internal]
Reviewed By: tyao1
Differential Revision: D62595120
fbshipit-source-id: 97fc3caded51190a7840de91025eeb71c6290be8
Summary:
Before we were dividing proportionally and were noticing some truncation at the bottom. It seems that the truncation was disproportionately because of the way the metrics are calculated. Through guess and check, dividing equally between top and bottom seems to yield better results... 🤡
Changelog: [internal]
Reviewed By: NickGerleman, xunrongl
Differential Revision: D62665295
fbshipit-source-id: b1589c75251d68eaf75e32598ee84fbac457ae4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46487
Changelog: [General][Fixed] Fixed accuracy of FlatList estimations to determine what elements are visible in the rendering window.
This fixes a bug in FlatList where it thinks that some elements are visible in the rendering window, when they're not. Specifically, if a cell hasn't been laid out yet, it ignores all the information it already has on the ones that had, and estimates its position and offset based on the estimated size of the cells. In this case, if the first element has a larger offset because the list has a header, that offset is ignored in this case.
One observed result of this is that in a list where there's a header and a single cell that occupy the whole rendering window, FlatList thinks it needs to pre-render an additional element because the header is ignored.
Reviewed By: NickGerleman
Differential Revision: D62649060
fbshipit-source-id: 437bae79916707ca1d08784190508a9f7e36688e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46467
This diff introduces a new feature flag called ReactNativeFeatureFlag.enableDeletionOfUnmountedViews, which will ensure that pre-allocated views that were never mounted on the screen are deleted as soon as the shadow node is deleted from JS
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D62559188
fbshipit-source-id: 61f19a6dd38536de9f70fecc2937793681036f68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46478
These are all supported in the new arch (default as of 0.76), across all platforms. but were previously hidden from types, and undocumented.
I will make a pick request for this change, and we should then add these to documentation.
Changelog:
[General][Added] - Unhide new arch layout props
Reviewed By: cortinico
Differential Revision: D62616897
fbshipit-source-id: f6c2e71785284e667824a76918ccf2724adc4e98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46486
We probably don't need this extra log anymore as this information is already avaialbe from the start application log.
Changelog:
[General] [Changed] - Do not print Bridgeless Mode is enabled on console anymore
Reviewed By: fkgozali
Differential Revision: D62639866
fbshipit-source-id: 720bb1446a1e1be71bf27830fe4156ae64a1586f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46483
Original commit changeset: 631d741bd2ec
This is breaking the RedBox on React Native 0.76 on Android when not connected to Metro.
Original Phabricator Diff: D62213722
Changelog:
[Internal] [Changed] - Back out "[react-native] Remove some Tasks overhead"
Reviewed By: cipolleschi
Differential Revision: D62644614
fbshipit-source-id: a092614da78bef65546c2539a3ebc9bff5e807b2
Summary:
This PR is a follow-up after https://github.com/facebook/react-native/issues/46181 this change makes sure that if the `require.resolve` fails we still fall back to the old behavior.
The `require.resolve` was failing for local builds of OOT platforms (because in OOT platforms mono repo `react-native` is renamed to `react-native-platform-name`)
## Changelog:
[IOS] [FIXED] - Fallback to old resolve mechanism when node require fails to resolve react native path
Pull Request resolved: https://github.com/facebook/react-native/pull/46432
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D62577183
Pulled By: cipolleschi
fbshipit-source-id: d62d9c2a5eee3546a81d2aad52b7f73763315b18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46463
We had some basic warnings emitted by React Native components due to unused parameters or missing documentations.
This change fixes some of those
## Changelog:
[Internal] - Fix some build warnings
Reviewed By: NickGerleman
Differential Revision: D62583790
fbshipit-source-id: 329acc67ce64c00757a8568460ee68b85a62b6e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46464
React Native uses some 3P libraries that are emitting some warnings for which we can't do anything about.
This change suppress those warnings.
## Changelog:
[Internal] - Suppress 3p warnings
Reviewed By: cortinico
Differential Revision: D62582960
fbshipit-source-id: 79e8c28725177f5f47359da86f865e770dcf7c7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46472
Currently, we are building the Debug symbols (dSYM) for hermes dSYM but we are not shipping them with the xcframework.
This is correct, because Debug symbols can increase the size of Hermes thus enalrging the iOS IPA and increasing the download time when installing pods.
We distribute the dSYM separatedly, in case users needs to symbolicate Hermes stack traces.
However the path to the dSYM still appears in the Info.plist of the universal XCFramework and this can cause issues when submitting an app to apple.
This change should remove those lines from the universal framework.
It fixes https://github.com/facebook/react-native/issues/35863
## Changelog
[Internal] - Remove dSYM path from Info.plist
Reviewed By: cortinico
Differential Revision: D62603425
fbshipit-source-id: 038ec3d6b056a3d6f5585c8125d0430f56f11bb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46454
The SVC Validator have no idea on how to process a simple NSArray *.
With this change, we are creating two named types for the NSArray:
* BoxShadowArray
* FilterArray
To create unique types that we can reference in JS.
We are then enhancing the `getProcessor` function to return the proper processor when those types are found in the NativeViewConfig
## Changelog:
[iOS][Fixed] - Fixed warnings when validating SVC
## Facebook:
This change is OTA safe: even when we ship the JS before the native code, the new cases in the switch will be never hit, similarly to the situation we have right now.
As soon as the native code is shipped, the new cases will start get hit and the wrning will disappear
Reviewed By: NickGerleman
Differential Revision: D62574612
fbshipit-source-id: d173bf5534ee5e436f23a4bc6e2fb25e72a4b06d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46439
The SVC for some components on iOS got out of sync.
This was creating warnings in the React Native DevTools and it was affecting the release of 0.76.
With this change, I updated the manually written SVC so that we don't have warnings anymore.
We still have to fix the `boxShadow` and `filter`. This will happen in a later change.
## Changelog
[iOS][Fixed] - Solved SVC warnings for RNTester
Reviewed By: NickGerleman
Differential Revision: D62501704
fbshipit-source-id: 3c02f7615c3511a97eba73a2ddaa713d2e4e30f0
Summary:
AppRegistry was not treated as a Callable Module in bridgeless mode. This is breaking headless tasks on Android.
Fixes:
- https://github.com/facebook/react-native/issues/46050
## Changelog:
[ANDROID] [FIXED] - Made AppRegistry callable from Native code in Bridgeless (fixes headless tasks)
Pull Request resolved: https://github.com/facebook/react-native/pull/46480
Test Plan: Used repro from linked issue
Reviewed By: javache
Differential Revision: D62637486
Pulled By: cortinico
fbshipit-source-id: 756527003ac6d712e76c02c188e280d15c010068
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/46276
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [ADDED] - fire onMomentumScrollEnd when UIScrollView is removed from window
**Why the issue is happening?**
The `onMomentumScrollEnd` event is typically triggered by the `UIScrollView` delegate methods `scrollViewDidEndDecelerating` and `scrollViewDidEndScrollingAnimation`. However, if the scroll view is removed from the window while navigating away, these delegate methods are not called, resulting in the event not being dispatched.
This behaviour was particularly problematic in scenarios where a scroll view is in motion, and the user navigates away from the screen before the scrolling completes. In such cases, the `onMomentumScrollEnd` event would never fire, which further make scroll area un touchable or un responsive.
**What we changed?**
In the didMoveToWindow method, we added logic to handle the scenario where the UIScrollView is being removed from the window (i.e., when the component is unmounted or the user navigates away). Here’s a breakdown of the changes:
- **Added a Check for Scroll State:** We check if the UIScrollView was decelerating or had stopped tracking (_scrollView.isDecelerating || _scrollView.isTracking == NO).
- **Manually Triggered onMomentumScrollEnd:** If the scroll view was in motion and is being removed from the window, we manually trigger the `onMomentumScrollEnd` event to ensure that the final scroll state is captured.
**_I had fixed this issue on both Old and New arch._**
Pull Request resolved: https://github.com/facebook/react-native/pull/46277
Test Plan:
Attaching a video with working solution:
https://github.com/user-attachments/assets/1a1f3765-3f11-46c3-af18-330c88478db8
Reviewed By: andrewdacenko
Differential Revision: D62374798
Pulled By: cipolleschi
fbshipit-source-id: 014be8d313bab0257459dc4e53f5b0386a39d5e0
Nick Gerleman
Eric Rozell
Alan Lee
Vincenzo Vitale
Oskar Kwaśniewski
Rubén Norte
Stephanie Nicholson
shubhamguptadream11
Samuel Susla
Alex Hunt
Pascoal Júnior
Riccardo Cipolleschi
Vitali Zaidman
Rodolfo Gomez Sirimarco
David Vacca
Sam Zhou
Tim Yung
Kevin Gozali
Melissa Liu
Jorge Cabiedes Acosta
Nicola Corti
Robert Pasiński