Summary:
XCode privacy files might not contain a `NSPrivacyAccessedAPITypes` key, which causes the following error:
```
[!] An error occurred while processing the post-install hook of the Podfile.
undefined method `each' for nil
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
```
## 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
-->
[IOS] [FIXED] - Privacy Manifest aggregation failing due to no `NSPrivacyAccessedAPITypes` key
Pull Request resolved: https://github.com/facebook/react-native/pull/44628
Test Plan: I tested this patch on our own app and it solved the issue.
Reviewed By: christophpurrer
Differential Revision: D57618425
Pulled By: cipolleschi
fbshipit-source-id: 1a36ab5a1bb45b8507d3663b782c95258d97c8a4
Summary:
The new cocoapod post install script includes aggregation and generation of privacy manifests for iOS, which is great. However, the script doesn't consider the case where the file reference doesn't have a path.
Example, for a project setup like the screenshot:
<img width="249" alt="image" src="https://github.com/facebook/react-native/assets/22592111/45dd1cf4-c2f6-4abb-940f-136a4d502966">
The code
https://github.com/facebook/react-native/blob/05a4232dd591e2d43f192d69ca14a04f4a3fb6a1/packages/react-native/scripts/cocoapods/privacy_manifest_utils.rb#L80-L81
prints `file_refs`:
```
[
<PBXFileReference name=`LaunchScreen.storyboard` path=`learnX/LaunchScreen.storyboard` UUID=`81AB9BB72411601600AC10FF`>,
<PBXVariantGroup name=`InfoPlist.strings` UUID=`D40B9F832B248EF5004BC08C`>,
<PBXFileReference path=`AppCenter-Config.plist` UUID=`D40B9F802B248EC2004BC08C`>,
<PBXFileReference name=`PrivacyInfo.xcprivacy` path=`learnX/PrivacyInfo.xcprivacy` UUID=`D403DD362BCA2BCF00E5295C`>,
<PBXFileReference name=`Assets.xcassets` path=`learnX/Assets.xcassets` UUID=`D40B9F652B248AEB004BC08C`>
]
```
where a `PBXVariantGroup` exists and it doesn't have `path`. The error `undefined method 'end_with?' for nil` occurs as a result.
## 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] [FIXED] - In privacy manifest post install script, handle the case where the file reference doesn't have a path
Pull Request resolved: https://github.com/facebook/react-native/pull/44410
Test Plan:
1. Add a new "Strings File (Legacy)" in Xcode to the project.
2. Run `pod install` for iOS.
3. See the error `undefined method 'end_with?' for nil`.
4. Apply the fix and rerun `pod install`.
5. The script runs successfully.
Reviewed By: javache
Differential Revision: D57056159
Pulled By: cipolleschi
fbshipit-source-id: 42caaf1a98efb9111f6ff1014a5c8b7703b042f2
Summary:
After upgrading my app from React Native 0.74.0 to 0.74.1, iOS builds were failing due to the privacy manifest ruby script failing due to what seemed to be a missing nil check.
```
[Privacy Manifest Aggregation] Appending aggregated reasons to existing PrivacyInfo.xcprivacy file.
[Privacy Manifest Aggregation] Reading .xcprivacy files to aggregate all used Required Reason APIs.
[!] An error occurred while processing the post-install hook of the Podfile.
no implicit conversion of nil into Array
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in `+'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in `block (5 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in `block (2 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in `block in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in `get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:18:in `add_aggregated_privacy_manifest'
node_modules/react-native/scripts/react_native_pods.rb:301:in `react_native_post_install'
ios/Podfile:38:in `block (3 levels) in from_ruby'
vendor/bundle/ruby/3.3.0/gems/cocoapods-core-1.15.2/lib/cocoapods-core/podfile.rb:196:in `post_install!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1013:in `run_podfile_post_install_hook'
vendor/bundle/ruby/3.3.0/gems/cocoapods-pod-sign-1.3.0/lib/cocoapods-pod-sign/pod_installer.rb:45:in `run_podfile_post_install_hook'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1001:in `block in run_podfile_post_install_hooks'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:149:in `message'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1000:in `run_podfile_post_install_hooks'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:337:in `block (2 levels) in create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer/xcode/pods_project_generator/pods_project_writer.rb:61:in `write!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:336:in `block in create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:64:in `section'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:315:in `create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:307:in `generate_pods_project'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:183:in `integrate'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:170:in `install!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/command/update.rb:63:in `run'
vendor/bundle/ruby/3.3.0/gems/claide-1.1.0/lib/claide/command.rb:334:in `run'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/command.rb:52:in `run'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/bin/pod:55:in `<top (required)>'
vendor/bundle/ruby/3.3.0/bin/pod:25:in `load'
vendor/bundle/ruby/3.3.0/bin/pod:25:in `<top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:58:in `load'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:58:in `kernel_load'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:23:in `run'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:451:in `exec'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/command.rb:28:in `run'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor.rb:527:in `dispatch'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:34:in `dispatch'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/base.rb:584:in `start'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:28:in `start'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/exe/bundle:28:in `block in <top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/exe/bundle:20:in `<top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/bin/bundle:25:in `load'
/Users/swrobel/.gem/ruby/3.3.1/bin/bundle:25:in `<main>'
```
Adding some good old `puts` debugging to this file indicated that the problem was that an invalid manifest file was being generated for react-native-image-crop-picker, which I don't understand, because it [doesn't currently have a Privacy Manifest](https://github.com/ivpusic/react-native-image-crop-picker/issues/2040).
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSPrivacyTracking</key>
<false/>
<key>NSPrivacyTrackingDomains</key>
<array/>
<key>NSPrivacyCollectedDataTypes</key>
<array/>
<key>NSPrivacyAccessedAPITypes</key>
<array>
<dict/>
</array>
</dict>
</plist>
```
It seems there may be some upstream issue in whatever tool generates these missing privacy manifests, but that seemed beyond the scope of a simple nil check.
## Changelog:
[iOS] [FIXED] - Privacy Manifest aggregation failing due to missing nil check
Pull Request resolved: https://github.com/facebook/react-native/pull/44400
Test Plan: Build completes successfully after making this change.
Reviewed By: cipolleschi
Differential Revision: D56921303
Pulled By: philIip
fbshipit-source-id: 1b6b10b05d403bf71f78f5b80543a2d82f043e23
Summary:
As pointed out by liamjones here:
https://github.com/facebook/react-native/pull/44214#discussion_r1587755403
The original PR did introduce a bug in the `find/first` check, but in my testing, we do need to look at `group.name`, so let's make sure we check both.
This also makes it play nice with an existing file even if it is added to a different directory, by appending to it instead of forcing it to exist in the main group.
## Changelog:
[IOS] [FIXED] - Fix privacy aggregation
Pull Request resolved: https://github.com/facebook/react-native/pull/44390
Test Plan: Tested on rn-tester
Reviewed By: cipolleschi
Differential Revision: D56893594
Pulled By: philIip
fbshipit-source-id: b92589bc2bed9d07e9af20c56a8b9f6c61d864f0
Summary:
As of now, Apple does not respect privacy manifests added as cocoapods resource bundles. This forces react-native developers to manually copy `.xcprivacy` files content for each native dependency that accesses restricted reason APIs to the root file.
This PR adds an aggregation step that crawls through pod dependencies to collect all reasons into the root privacy info file.
[IOS][ADDED] – Add privacy manifest aggregation.
Pull Request resolved: https://github.com/facebook/react-native/pull/44214
Test Plan:
When run on RNTester, it appends aggregated entries (while keeping existing ones) to existing .xcprivacy file without modifing .pbxproj:

When run on RNTester with the xcprivacy file removed from xcode beforehand, it creates a new .xcprivacy file, and adds it to Compile Bundle Resources in the same way as in the new template:

When run on RNTester with an empty .xcprivacy file, it appends aggregated entries from pods AND reasons for react-native core.
When run with `privacy_file_aggregation_enabled: false` in `use_react_native`, it falls back to existing behavior:

Reviewed By: cipolleschi
Differential Revision: D56481045
Pulled By: philIip
fbshipit-source-id: 1841bad821511c734d0cc0fcff5065ed92af76d8
Summary:
Set the proper build flags for debugging in Bridgeless mode.
This fixes [#44240](https://github.com/facebook/react-native/issues/44240)
## Changelog:
[iOS][Fixed] - Add `HERMES_ENABLE_DEBUGGER=1` flag to React-RuntimeApple
Reviewed By: cortinico
Differential Revision: D56575647
fbshipit-source-id: a0613a5d46caeb1d3e636e54ecd43428fbaf46e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44185
This change will fix a symbol not found for JSC Runtime.
The `if` check was not a compile time check, therefore the symbol ended up in the binary even if it is not available.
Following this post on [Apple forum](https://forums.developer.apple.com/forums/thread/749534), this changes should do the trick.
## Changelog
[iOS][Fixed] - Fix Symbol not found: (_JSGlobalContextSetInspectable)
Reviewed By: hash3r
Differential Revision: D56425834
fbshipit-source-id: a37af51b078bd47a938e6b65d9d8e0f7506e746f
Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
Summary:
This allows build configuration named like `StagingDebug` to match with settings applied to `Debug` This fixes https://github.com/facebook/react-native/issues/43185
Custom build setting were only applied to `Debug` build configurations, preventing configurations named `StagingDebug` or similar to access the new experimental debugger, as reported in https://github.com/facebook/react-native/issues/43185
This now applies the setting to every configuration ending with `Debug`
## Changelog:
[IOS] [CHANGED] - fix: build settings for custom build configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/43780
Reviewed By: dmytrorykun
Differential Revision: D55688996
Pulled By: cipolleschi
fbshipit-source-id: 1f34cd722f6acfaa08d3377e19a04d08af97ed7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43563
Fixes https://github.com/facebook/react-native/issues/42874
## Sumary
D9405703 added some custom logic for Flings, to support FlatList scenarios where content is being added on the fly, during Fling animation. This works by allowing start Fling to not have bounds, then correcting/cancelling Fling when overscroll happens over a bound that would normally be allowed.
This has some math to try to determine max content length, and will clamp to this when scrolling over it. This logic is incorrect when content length is less than scrollview length, and we end up snapping to a negative offset.
This change adds clamping, so that we don't snap to negative position in horizontal scroll view. This clamping was already indirectly present on vertical scroll view. https://www.internalfb.com/code/fbsource/[b43cdf9b2fec71f5341ec8ff2d47e28a066f052e]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=609
## Test Plan
Above issue no longer reproes. Flinging while content is being added to horizontal FlatList still works correctly.
Changelog:
[Android][Fixed] - Fix Android HorizontalScrollView fling when content length less than ScrollView length
Reviewed By: javache
Differential Revision: D55108818
fbshipit-source-id: 7cf0065f9f92832cc2606d1c7534fc150407b9c9
Summary:
Problem Causes: In ReactViewGroup, there is a conflict between the zIndex attribute and the removeClippedSubviews optimization attribute. When both are used at the same time, the array mDrawingOrderIndices in ViewGroupDrawingOrderHelper that records the rendering order of subviews is not reset when super is called in the updateSubviewClipStatus method to add and remove subviews.
Solution:�Because there are many third-party components that inherit from or depend on ReactViewGroup, all methods for adding and removing subviews in ViewGroup need to be override in ReactViewGroup, and ViewGroupDrawingOrderHelper corresponding to handleAddView and handleRemoveView needs to be called in these methods. And all the precautions for directly calling super to add and remove subviews are changed to calling the overridden method by ReactViewGroup.
Special Note: All addView related methods in ViewGroup will eventually be called to the addView(View child, int index, LayoutParams params) method, except addViewInLayout. Regarding the method of adding subviews, we only need to override addView(View child, int index, LayoutParams params) and addViewInLayout(View child, int index, LayoutParams params,boolean preventRequestLayout) in ReactViewGroup.
## Changelog:
[Android] [Fixed] - Fix the crash in ReactViewGroup of https://github.com/facebook/react-native/issues/30785
Pull Request resolved: https://github.com/facebook/react-native/pull/40859
Reviewed By: NickGerleman
Differential Revision: D50321718
Pulled By: javache
fbshipit-source-id: 7fa7069937b8c2afb9f30dd10554370b1be5d515
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42922
changelog: [fix][ios] prevent unwanted border animation
The problem: CALayer and its properties are animatable. If RN applies mutations inside an animation block, it will animate. In this particular example, it was animated because of a transition applied by the library and because we were not creating new views, but recycling views from previous screen.
This caused size of _borderLayer to change from value A to value B inside of animation block. To resolve this, call removeAllAnimations on borderLayer.
Reviewed By: cipolleschi
Differential Revision: D53566886
fbshipit-source-id: 98e0b01a9185046e1ee500665c1832060ecc8884
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42639
When I reverted part of the deprecation of `RCT_NEW_ARCH_ENABLED`, I forget a little bit which was breaking RCTFabric podspec.
This diff fixes that.
[Internal] - Bring back `RCT_NEW_ARCH_ENABLED` to Fabric to make the `RCTThirdPartyFabricComponentsProvider` work again.
Reviewed By: cortinico
Differential Revision: D53048270
fbshipit-source-id: d21e833c10b332fb70147cc65b690f88016655e6
* Add Flow, add positive test case for monorepo publish step (#42936)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42936
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607809
fbshipit-source-id: 990826fda5538af9a13e3f24978295a2f3b0c8c3
# Conflicts:
# scripts/monorepo/__tests__/find-and-publish-all-bumped-packages-test.js
# scripts/monorepo/find-and-publish-all-bumped-packages.js
* Update exit cases for monorepo publish script (#42937)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42937
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607810
fbshipit-source-id: 18e79f23060ee70e96bd8ac6e9995b0a8ba300b3
# Conflicts:
# scripts/monorepo/__tests__/find-and-publish-all-bumped-packages-test.js
# scripts/monorepo/find-and-publish-all-bumped-packages.js
* Refactor package discovery in publish script (#42938)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42938
Substitutes the `forEachPackage` util with a replacement async `getPackages` function. This will be used further in the next diff.
The new function aims to be more erganomic/versatile than `forEachPackage` by returning a package mapping (see updated test mock). The API aligns roughly with `yarn workspaces list` and [Lerna's `detectProjects`](https://lerna.js.org/docs/api-reference/utilities#detectprojects).
This also aligns with / replaces similar attempts in our existing scripts:
- [`getPackagesToPublish`](https://github.com/facebook/react-native/blob/2ca7bec0c2a7d821ceaaf39840a6cdc5eceb8678/scripts/monorepo/get-and-update-packages.js#L56)
- [`getPublicPackages`](https://github.com/facebook/react-native/blob/2ca7bec0c2a7d821ceaaf39840a6cdc5eceb8678/scripts/releases/set-version/index.js#L19)
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607806
fbshipit-source-id: 00ec34edadab863dc8f2f0c7852f6e835a5dddf5
# Conflicts:
# scripts/monorepo.js
# scripts/monorepo/find-and-publish-all-bumped-packages.js
# scripts/monorepo/for-each-package.js
* Use npm as source of truth for updated packages (make publish script rerunnable) (#42944)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42944
Updates `find-and-publish-all-bumped-packages` to use the npm registry as the source of truth, similar to tools like Lerna (`lerna publish from-package`). **This enables safe reruns of the publish script**, and replaces the previous Git-diff-detection implementation.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D53607807
fbshipit-source-id: 135808b7ce36cf463c9f53a8059500b83f8b6679
# Conflicts:
# scripts/monorepo/find-and-publish-all-bumped-packages.js
* Add retry to monorepo publish script (#42964)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42964
We've seen npm publishes fail occasionally in CI as part of this script, most recently in S391653. This change adds a single retry, per package, during the execution of this script, in an attempt to reduce the chance of manual interventions after a broken pipeline.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607808
fbshipit-source-id: 526d9c33d51ec57702efba3c199bad313c1bf2d4
# Conflicts:
# scripts/monorepo/find-and-publish-all-bumped-packages.js
* Rename and document monorepo publish script (#42989)
Summary: Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607805
fbshipit-source-id: babe9bbd7fb5e7016b567193727c6a441bee60a3
# Conflicts:
# scripts/__tests__/publish-updated-packages-test.js
# scripts/publish-updated-packages.js
# scripts/releases-ci/README.md