Summary:
As per the discussion on the previous [PR thread](https://github.com/facebook/react-native/pull/52028#issuecomment-2979481948), this PR uses `SwiftUI` to implement blur filter on iOS.
## Approach:
To implement blur filter on iOS, we have two options:
1. Use `CAFilter` (private API, app can get rejected/API can break). Earlier [PR](https://github.com/facebook/react-native/pull/52028) was using that approach. Thanks to Nick for suggesting SwiftUI API.
2. Use `SwiftUI`. Wrap the view in a SwiftUI view and apply [blur](https://developer.apple.com/documentation/swiftui/view/blur(radius:opaque:)). This PR builds on top of that approach. This also enables a way to add `SwiftUI` only features like this one. Additional filters (grayscale, saturate, contrast, hueRotate) can also be added.
There are a few ways we can implement the SwiftUI approach:
1. Create a new `RCTSwiftUIComponentView` -> do style flattening in View -> check if `filter` is present and conditionally render the `RCTSwiftUIComponentView` on iOS, wrap children with a `SwiftUI` view. Tradeoff with this approach is that it adds `StyleSheet.flatten` overhead on JS side.
2. Add a `SwiftUI` container view inside of `RCTViewComponentView`. Tradeoff with this approach is that it complicates `RCTViewComponentView` a bit.
I decided to go with **2** to avoid the flattening tradeoff and try to minimize complicating `RCTViewComponentView`. it only adds the wrapper if it's required and removes if not (in this PR, blur filter style will add the wrapper, it will get removed if blur filter styling gets removed). It uses the existing container view pattern.
## Changelog:
[IOS][ADDED] - Filter blur
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/52495
Test Plan:
Test filter blur example on iOS. SwiftUI view should be added to the hierarchy.
<img src="https://github.com/user-attachments/assets/742539f4-a96d-45f4-94ba-5eb588d0ad5a" width="300px" />
## Aside:
- This PR also adds a new swift podspec. Creating a new podspec felt the right approach as adding swift in existing ones were adding some complexity. But open for changes here. Also, need some eyes on the podspec configs. cc - chrfalch 🙏 this might also affect the SPM migration.
- Unrelated: Existing brightness filter has some inconsistency compared to android and web, it uses [self.layer.opacity](https://github.com/facebook/react-native/blob/6892dde36373bbef2d0afe535ae818b1a7164f08/packages/react-native/React/Fabric/Mounting/ComponentViews/View/RCTViewComponentView.mm#L1008) so transparent background color do not blend well unless the view has an opacity. One solution would be to calculate true background color by using brightness or else use the `SwiftUI`'s [brightness](https://developer.apple.com/documentation/swiftui/view/brightness(_:)), which would be cleaner imo (tested and it works).
Reviewed By: cipolleschi
Differential Revision: D79666764
Pulled By: joevilches
fbshipit-source-id: 05e43d75ce7b6f25b67b4eed632524a559ea1c2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53711
Changelog: [internal]
This removes some fields that contain the same time as `endTime`, which is confusing when documenting them.
Reviewed By: christophpurrer
Differential Revision: D82112473
fbshipit-source-id: 461e2b4b495ae641dcb3233874360a4f7b90dabf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53547
Changelog: [internal]
This creates a new feature flag to enable the modern Web performance APIs in RN by default. It's disabled by default so it shouldn't have any effect at the moment.
Reviewed By: rshest
Differential Revision: D80811430
fbshipit-source-id: 47d5fd12ac8809aa3c5ad37cdd31c0d9e3ed5912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53397
This is a runtime behaviour fix and an API change to `Appearance.setColorScheme`, motivated by a user report where providing `'unspecified'` (valid) to this function would trigger an incorrect invariant throw. Furthermore, there is already a [first party use](https://github.com/facebook/react-native/blob/aec35b896053d9372ccdaf67c939b2eb216d3455/packages/react-native/Libraries/Utilities/Appearance.js#L101) where we call `Appearance.setColorScheme('unspecified')`.
**Changes**
- `Appearance.d.ts` (current public API, manual types): Fix `ColorSchemeName` type to include `'unspecified'` value, and narrow to remove nullability — aligning with existing Flow source for this type in `NativeAppearance`.
- `Appearance.js` (implementation): Fix the invariant throw by **removing it**, and instead narrowing the input type to non-nullable. Redundant work in `getState` and `getColorScheme` is removed.
Changelog: [General][Breaking] `Appearance.setColorScheme` no longer accepts a nullable value
Reviewed By: andrewdacenko
Differential Revision: D80705652
fbshipit-source-id: cf221a33447606653050d471ca2d0347ab30db81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53481
Small fix to this RNTester example to clean up hanging `setInterval` side effect making repeat network fetches.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D81127809
fbshipit-source-id: 6036dd254888eb6160d2b1e116bbce63e5fd9328
Summary:
The `aria-label` prop was ignored on `TextInput` component. Which resulted in screen reader not able to read it.
This PR forwards `aria-label` to `accessibilityLabel` in a manner similar to e.g. `View` and `Text`
## 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] [FIXED] - a11y: fix `aria-label` on `TextInput`
Pull Request resolved: https://github.com/facebook/react-native/pull/53051
Test Plan:
Run RNTester => TextInput => Accessibility section under Accessibility Inspector or screen reader.
iOS fixed:
https://github.com/user-attachments/assets/68c3a2ef-7dfe-479c-97fc-cbe72108c45c
iOS baseline:
https://github.com/user-attachments/assets/2e8372ba-10dc-47d2-b6b1-9f664000de7d
Reviewed By: andrewdacenko
Differential Revision: D79635413
Pulled By: rshest
fbshipit-source-id: dd2f583d67c6c6c6393e02c5fe534308e1e2f921
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52846
Adding the Paragraph `disabled` property for RN Android.
This diff also adds a new Text example to RNTester for disabled text.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D78990840
fbshipit-source-id: dd25b890597bc9f728f929b38c2f680631b7f476
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52610
This diff removes `ReactNativeFeatureFlags` from `react-native/Libraries/ReactNative` and migrates
`shouldPressibilityUseW3CPointerEventsForHover` to common `ReactNativeFeatureFlags` in `src/private/featureflags`. The `shouldEmitW3CPointerEvents is removed as it is used in `rn-tester` to hide some examples.
Changelog:
[General][Breaking] - Migrate `shouldPressibilityUseW3CPointerEventsForHover` to common private feature flags and remove `shouldEmitW3CPointerEvents` flag.
Reviewed By: robhogan
Differential Revision: D75448698
fbshipit-source-id: 03942c9504b855f2054c9a5948c0521ce17365b5
Summary:
This module is currently unused, so we can clean it up.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/52705
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D78555763
Pulled By: cortinico
fbshipit-source-id: 0a6152ab3d357cac0c6d7669f292680af7b87074
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52691
Unannotated array literals are unsound in Flow right now. This diff adds in annotations and makes a few things readonly, to reduce future errors.
Changelog: [Internal]
Reviewed By: marcoww6
Differential Revision: D78519638
fbshipit-source-id: d98a7668ecf97bcc87dcb3fad25ade736d885d9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52388
Changelog: [Internal]
Similar to `AsyncCallback<>` (the foundation of `AsyncPromise`) we should allow `void` Promise types in C++ such as `AsyncPromise<>`
Reviewed By: rbergerjr
Differential Revision: D77712020
fbshipit-source-id: d7360df5cc1b77f1e03e5fb73b0b468f6e3a415b
Summary:
This change fixes an issue on iOS where gradients that fade to a transparent color-stop appear dark or "muddy." The fix ensures that the color's hue is preserved during the transition, matching the behavior on Android and web.
### The Problem
When creating a gradient on iOS (e.g., linear-gradient(red, transparent)), the transparent keyword is treated as transparent black (rgba(0,0,0,0)). The `CAGradientLayer` on iOS then interpolates all color channels linearly, causing the red, green, and blue components of the start color to fade to 0. This transition through black results in an undesirable dark or "muddy" appearance in the middle of the gradient.
## Changelog:
[IOS][FIXED] - Gradient interpolation for transparent colors
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/52249
Test Plan:
Checkout `LinearGradient` example in RNTester, checkout the newly added transparent color transition example, it should render same on android and iOS.
| Before | After |
| --- | --- |
| <img src="https://github.com/user-attachments/assets/c0bb54ad-ed0e-4a80-b37f-0458af0f1f77" width="300"> | <img src="https://github.com/user-attachments/assets/02da921a-bd0e-45c1-881c-cf6460d5ed43" width="300"> |
| `linear-gradient(to right, red, transparent)` transitions to black on iOS, creating a dark effect. | The gradient correctly fades the red color's alpha channel to zero |
Reviewed By: javache
Differential Revision: D77312194
Pulled By: NickGerleman
fbshipit-source-id: 053df8e44f52cd22a3f28fd01f583f7d03c66af5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52271
In my haste I messed up a few of these. Either type in the text, or giving them props they should not have.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D77310876
fbshipit-source-id: 9c5a28285d4bb3673fe99630fa7ed97033b17904
Summary:
This PR replaces Core Graphics implementation with Core Animation for radial gradients. I found that `endPoints` for radial gradient type works differently than linear gradient type. The `endPoint.x` accounts for horizontal length and `endPoint.y` accounts for vertical. This makes it possible to draw ellipse gradients. So we don't need the core graphics API anymore.
## Changelog:
[IOS] [CHANGED] - Optimised Radial Gradients.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/52117
Test Plan: Non breaking change. Test Radial gradient example from RNTester. Compare results with web, android and iOS. Each platform should render the gradients identically.
Reviewed By: rshest
Differential Revision: D77140709
Pulled By: javache
fbshipit-source-id: 6e3ad9fcf8e819d340ccf5f5946beb140e616cb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52122
Would love to have a place with all the edge cases we can come back to when we try and tweak things.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D76942595
fbshipit-source-id: ce6e293e2c068383e54404af71a29a0586dbc04e
Summary:
This PR replaces Core Graphics implementation with Core Animation for linear gradients. I came across a great [solution](https://stackoverflow.com/questions/38821631/cagradientlayer-diagonal-gradient/43176174#43176174) that makes the `CAGradientLayer`'s start and end point behaviour CSS spec compliant. This will make gradients much more performant.
## Changelog:
[IOS] [CHANGED] - Optimised Linear Gradients.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/52096
Test Plan:
Non breaking change. Test Linear gradient example from RNTester. Compare results with web, android and iOS. Each platform should render the gradients identically.
## Note:
I will be doing a PR to use `CAGradientLayer` for radial gradients as well. The next properties that I have locally working are `background-size`, `background-position` and `background-repeat`. These will be addressed in small PRs.
Reviewed By: NickGerleman
Differential Revision: D76905215
Pulled By: javache
fbshipit-source-id: 0094bdf70869d619272d491dd496983316b0dbf0
Summary:
This PR allows to interactively close the modal using the swipe down gesture.
It fixes 5 year old issue: https://github.com/facebook/react-native/issues/29319
In short it removes `modalInPresentation` which according to the documentation causes: "UIKit ignores events outside the view controller’s bounds and **prevents the interactive dismissal of the view controller while it is onscreen.**".
It also adds another delegate event to call onRequestClose whenever modal is closed by gesture.
https://github.com/user-attachments/assets/8849ecba-f762-47ec-a28b-b41c1991a882
## Changelog:
[IOS] [ADDED] - Allow to interactively swipe down the modal.
Add allowSwipeDismissal prop.
Pull Request resolved: https://github.com/facebook/react-native/pull/51483
Test Plan: Test if swiping down the modal calls onRequestClose
Reviewed By: rshest
Differential Revision: D75125438
Pulled By: javache
fbshipit-source-id: d4f2c8b59447680f405b725d0809573a937f97cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51880
Updates the `sort-imports` lint rule.
The main change is that it enforces newlines after the last import statement.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D76149902
fbshipit-source-id: 928871655c5de0613b18334d6fc0d71b3a971a18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51725
This change builds upon the focus/blur portion showcased in ViewExample but showcases several more components all in one spot. This can be shared with additional platforms or expanded to include more component examples like Image, but the goal is to target Android and not distract from the primary use cases.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D75747410
fbshipit-source-id: 7d53366d9f32192ca6b3da45dd127836fb6efdf6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51788
Adds `flow` to the remaining files that are lacking it in the `packages/rn-tester` directory.
This also adds any necessary type annotations and fixes lint warnings.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D75899307
fbshipit-source-id: 27a74ed0007b3b754446a45931c2c148312d5e3a
Summary:
The Image component in Android now supports the same cache control behaviour as in iOS, the examples needed to be separated in the past because the support was not the same for iOS and Android, but now that it is, we can unify the example.
## Changelog:
[INTERNAL] - Unify RNTester Cache Policy Image example
Pull Request resolved: https://github.com/facebook/react-native/pull/51580
Test Plan:
<details>
<summary>RNTester Screenshots</summary>
| iOS | Android |
|--------|-------|
|  |  |
</details>
Reviewed By: yungsters
Differential Revision: D75538812
Pulled By: Abbondanzo
fbshipit-source-id: 7705c8f824cb18cebc39e84b6f48979035dc104c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51673
Fixes a lint warning that seems to inconsistently fire, by improving the code that it complains about.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D75583443
fbshipit-source-id: b6df191e2e51dee688df3f3c960704dea28a4ece
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51634
Creates an example in the ViewExample setup for how onBlur/onFocus behave when using keyboard navigation
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D75238317
fbshipit-source-id: e69122ca17727fc7f71e9bb7a09098a2771b098e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51666
The platforms handle this in pretty different ways right now. Let's add a test showing the differences.
Android also adds a bunch of unicode zero width spaces in there...
Changelog: [Internal]
Reviewed By: mlord93
Differential Revision: D75567210
fbshipit-source-id: 98cac7d3fd23451868b55b69478e2667a2de3716
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51551
This allows hit RN's hit testing to find nested spans, and click them.
This mechanism is fully separate from the one used by a11y virtual views, and ClickableSpan, such as those added for links via dataDetectorType (and also the `link` role).
When we do have a link accessibilityRole, that ClickableSpan hit test seems to prevent the React one, and we only activate the onPress once (but then add keyboard interaction, press visual, and add to the a11y tree).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75257326
fbshipit-source-id: 0c693f581ec121cf4b4e3e2040d141985118224f
Summary:
As I reviewed some examples, I noticed that this one's dark mode could be improved, and the code could be modernised a bit as well by converting its classes into functional components.
## Changelog:
[INTERNAL] - Fix InputAccessoryView example in dark mode and convert to functional components
Pull Request resolved: https://github.com/facebook/react-native/pull/51583
Test Plan:
<details>
<summary>Screenshots</summary>
| Dark | Light |
|--------|-------|
|  |  |
</details>
Reviewed By: fabriziocucci
Differential Revision: D75404561
Pulled By: cortinico
fbshipit-source-id: 3318e9869919e99055e47b59c89de0b22976f142
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51603
In `rn-tester` TextAncestor was used to create a inlineView wrapper:
```js
function InlineView(props) {
return (
<TextAncestor.Provider value={false}>
<View {...props} />
</TextAncestor.Provider>
);
}
```
however, it is already done in View.js and TextAncestor shouldn't be used outside of react-native package:
```js
if (hasTextAncestor) {
return <TextAncestor value={false}>{actualView}</TextAncestor>;
}
return actualView;
```
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75408231
fbshipit-source-id: 7f12278296dcfe56246f6b7065f5a094e4099f7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51600
The `infoLog` is a `console.log` wrapper to separate ad-hoc console debug logging, however console logs are already used in some files in rn-tester (ex. RNTesterAppShared.js). The same applies to files in react-native package.
Changelog:
[General][Changed] - Removed `infoLog` from react-native package
Reviewed By: huntie
Differential Revision: D75402930
fbshipit-source-id: 1a14a9122552130415f058d3647d715225321ab8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51550
`adjustsFontSizeToFit` will adjust font size so that given text fits in both veritcal and horizontal bounds. The algorithm to mutate text to fit is executed during TextLayoutManager during layout creation for Fabric, and then re-executed in `TextView.onDraw()`. See D56134348 which introduced the logic.
In Facsimile, we were not seeing font size adjusted when text is too tall. This is because we are only incorporating the height constraint during Spannable mutation during draw, but not the original layout, which Facsimile uses directly.
This could potentially fix other bugs, where width may not corredpond to the final font size we settle on during drawing.
Changelog:
[Android][Fixed] - Fix missing height constraints when creating Fabric layout for `adjustsFontSizeToFit`
Reviewed By: mdvacca
Differential Revision: D75251391
fbshipit-source-id: 77d90c49d48911e63131f9f088cfce13946c67d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51524
Links in error suppressions will point to the announcement post in Flow FYI.
Changelog: [Internal]
drop-conflicts
Reviewed By: marcoww6
Differential Revision: D75188177
fbshipit-source-id: 27ea1fbee848e9371e679cf423e30bc9608edea0
Summary:
The Flow team is improving the way Flow infers type for primitive literals. This diff prepares the codebase for the new behavior by adding type annotations, or annotations of the form `'abc' as const`.
Changelog: [internal]
Reviewed By: marcoww6
Differential Revision: D75188179
fbshipit-source-id: be50990f23f79cf2d8dae7576af5190218adcafe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51488
The Flow team is improving the way Flow infers type for primitive literals.
Announcement: https://fb.workplace.com/groups/flowlang/permalink/1725180268087629/
This diff prepares the codebase for the new behavior by codemoding `as const` annotations.
## Repro steps
1/ Used steps in D73610163 to produce the code changes.
2/ Reverted files where `flow` errored:
```
flow status --show-all-errors > errors.log
node ~/fbsource/fbcode/flow/facebook/error-analyzer.js errors.log |
awk -F':' '{ print $1 }' | sort -u | grep -v 'Total Error Count' |
xargs hg revert --rev .
```
3/ Reverted files that did not improve error count in new Flow mode
```
# Run Flow before change
~/fbsource/fbcode/flow/facebook/flowd status --show-all-errors > errors-0.log
# Run Flow after change
~/fbsource/fbcode/flow/facebook/flowd status --show-all-errors > errors-1.log
# Compute error counts before and after
node ~/fbsource/fbcode/flow/facebook/error-analyzer.js errors-0.log | sort > errors-counts-0.log
node ~/fbsource/fbcode/flow/facebook/error-analyzer.js errors-1.log | sort > errors-counts-1.log
# Revert files with no change in error count
comm -12 errors-counts-0.log errors-counts-1.log | awk -F':' '{ print $1 }' | xargs hg revert --rev .~1
```
## Note to code owners
Due to the large number of errors involved in this rollout, adding `as const` was the most feasible large-scale automated solution. Ideally, a lot of these errors would be fixed by adding other appropriate type annotations. For example instead of annotating
```
type Shape = {type: 'circle', radius: number} | {type: 'square', side: number} | ...;
type ShapeKind = 'circle' | 'square' | 'triangle';
const circle = {
type: "circle" as const, // <-- annotation added here
radius: 42,
};
shape.type as ShapeKind;
takesShape(circle);
```
a more appropriate annotation would be
```
const circle: Circle = { type: "circle"; radius: 42 };
...
```
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D75114154
fbshipit-source-id: 67ee5673816da9625431e2a2466a1e0038386151
nishan (o^▽^o)
ismarbesic
Rubén Norte
Sam Zhou
Maciej Jastrzębski
Alex Hunt
Marco Wang
Nick Lefever
Dawid Małecki
Nicola Corti
Nick Gerleman
Christoph Purrer
Joe Vilches
Pieter De Baets
Oskar Kwaśniewski
Tim Yung
Peter Abbondanzo
Mateo Guzmán
Panos Vekris