Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45492
Changelog: [internal]
When testing the changes in https://github.com/facebook/react-native/pull/45473 / D55491870, I saw that the reported time spans for long tasks didn't perfectly align with the long tasks themselves in traces (Perfetto).
Taking a closer look, I realized that I wasn't doing the conversion between times and durations from `chrono` and `DOMHighResTimeStamp` (a `double`) correctly, and we're doing this conversion very often.
This moves the definition of `DOMHighResTimeStamp` to its own library and adds conversion methods to make sure we don't make this mistake in the future.
Reviewed By: rshest
Differential Revision: D59820241
fbshipit-source-id: c123920de56336da384ddc484f6ac9d287724301
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43333
This change fixes https://github.com/facebook/react-native/issues/43285.
Basically, when using a `yarn` alias to install pods, yarn creates a copy of the `node` and `yarn` executables and the `command -v node` command will return the path to that executable.
## Changelog
[iOS][Fixed] - Do not use temporary node when creating the .xcode.env.local
Reviewed By: dmytrorykun
Differential Revision: D54542774
fbshipit-source-id: 3ab0d0bb441988026feff9d5390dcfd10869a1b5
Summary:
After `pod install`, it would set some empty flags, which seems useless. cc cipolleschi .
## Changelog:
[IOS] [FIXED] - Don't set empty string when remove ccache
Pull Request resolved: https://github.com/facebook/react-native/pull/45400
Test Plan: No empty flags should be set after we exec `pod install`.
Reviewed By: cortinico
Differential Revision: D59671357
Pulled By: cipolleschi
fbshipit-source-id: 26b55da9efaeed36876649cc27f09ecafaba412a
Summary:
This PR adds cocoapods utility to set `SWIFT_ACTIVE_COMPILATION_CONDITIONS` to DEBUG, which is set to this value by default (when generating a new native Xcode project).
This allows to use the `#if DEBUG` compilator directive in Swift to work out of the box, without any changes on user's side:
```swift
override func bundleURL() -> URL? {
#if DEBUG
RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
#else
Bundle.main.url(forResource: "main", withExtension: "jsbundle")
#endif
}
```
## Changelog:
[IOS] [ADDED] - Set SWIFT_ACTIVE_COMPILATION_CONDITIONS to DEBUG
Pull Request resolved: https://github.com/facebook/react-native/pull/42330
Test Plan:
Run `bundle exec pod install` and check if the active compilation flags are populated:
Reviewed By: cortinico
Differential Revision: D58188103
Pulled By: cipolleschi
fbshipit-source-id: 64746f3c7bfbdf47c2dea5e5e8cb2962635b719b
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.
## Changelog:
[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/44128
Changelog: [Internal]
idk what happened but this link got abbreviated when i copypastad it, fixing it here
Reviewed By: javache
Differential Revision: D56228228
fbshipit-source-id: 35c5c9fb44e82083773302618474c1e3bbc71712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44089
While doing the release of 0.74.0-RC.9, we encountered some failures while building because the committed project had some new flags that have been added by cocoapods and that required Ccache.
However, Ccache is not a hard requirement to run React Native and the build started failing on systems that does not have ccache installed.
That happened because we were missing the piece of code that removed Ccache from the project in case the tool is not installed in the system.
We already committed such commit in the stable branch of 0.74, with [this commit](https://github.com/facebook/react-native/commit/2b18fdf8063b423a0fb5762f2c6044244b4c35e6). This change will port the same fix in main.
## Changelog
[iOS][Fixed] - Make sure to remove ccache scripts when ccache is not installed
Reviewed By: cortinico
Differential Revision: D56140015
fbshipit-source-id: 24e7ebb4e5c08766b29705e8b6f03c3f164a96ab
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:
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/43583
Fail during `pod install` if user's version of XCode is too old to avoid cryptic errors (e.g. https://github.com/reactwg/react-native-releases/issues/163).
I reused existing mechanism for version detection, though it may not be reliable for future versions of XCode.
Changelog:
[iOS][Changed] - Warn users during "pod install" if XCode is too old
Reviewed By: dmytrorykun
Differential Revision: D55149636
fbshipit-source-id: 78387ff19a6eb10f3ca0d4aa78e6b934ae3b0711
Summary:
This diff renames React-Codegen to ReactCodegen. This way we'll no longer have to try both
```
#include <React-Codegen/MyModule.h>
```
and additionally
```
#include <React_Codegen/MyModule.h>
```
for cases with `use_frameworks`.
Changelog: [iOS][Breaking] - Rename React-Codegen to ReactCodegen
Reviewed By: cipolleschi
Differential Revision: D54068492
fbshipit-source-id: dab8ea2034d299266482929061caa14397421445
Summary:
This PR removes the `apply_ats_config` function of ReactNativePodsUtils that was used inside `react_native_post_install` because it was preventing users from configuring `NSAllowsArbitraryLoads` to true in their projects, especially when building in CI as the plist file would be reset after running pod install.
## Changelog:
[IOS] [CHANGED] - Remove ATS config patch from react_native_post_install
Pull Request resolved: https://github.com/facebook/react-native/pull/42637
Test Plan: Edit `Info.plist`, run `pod install` and check if changes have not been overwritten
Reviewed By: cortinico
Differential Revision: D53048299
Pulled By: cipolleschi
fbshipit-source-id: 8dc335fae2e05a62daf931a50fa3f7a314e76a2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42230
While developing Xcode 15, Apple reimplemented the linker.
In Xcode 15.0, the linker was making old iOS (< 15) crash when they were built using Xcode 15.
To fix that, we make Apple create new compiler flags (`-ld_classic`) to have a backward compatible linker.
In Xcode 15.1, Apple fixed that behavior, so the flags should not be required anymore.
But now, if we pass `-ld_classic` to the linker and we have an app that is using `use_framworks!`, that app crashes at startup.
This change remove the flags if the Xcode that is used is 15.1 or greater.
*Note:* The previous change added the flags to Hermes as well. I tested this fix in a configuration where Hermes has the flags and React Native does not, and it works. So we are removing the flags only from React Native.
This Fixes https://github.com/facebook/react-native/issues/39945
## Changelog:
[Internal] - Do not add the `-ld_classic` flag if the app is built with Xcode 15.1 or greater.
Reviewed By: cortinico
Differential Revision: D52658197
fbshipit-source-id: 37d6bc895921c0fc3661f301870477191e7e42b3
Summary:
Building native modules from source, may take a long time. Xcode already helps bring this down, by providing incremental builds, as long as the user doesn't delete their `ios/build` directory. But in some situations, i.e. when iterating the native code of an app or library or when the developer need to delete that `ios/build` directory, it's advantageous to use a compiler cache, such as ccache. This is already outlined in our ["Speeding up your Build phase"](https://reactnative.dev/docs/build-speed#xcode-specific-setup) guide.
But setting up an Xcode project to use Ccache with the correct configuration, isn't trivial in a way that doesn't require symlinking `clang` and `clang++` or passing configuration via environment variables on every `npm run ios` invokation.
This PR takes its inspiration from the existing guide on [setting up Ccache for Xcode](https://reactnative.dev/docs/build-speed#xcode-specific-setup), but applies the build settings only if an installation of `ccache` is detected and the feature is explicitly opted into via an argument to the `react_native_post_install` function or a `USE_CCACHE` environment variable. It uses two shell scripts to wrap the call to `ccache`, which both injects a default `CCACHE_CONFIGPATH` environment variable (i.e. it won't override this if already provided, to allow for customisations on CI), pointing to a `ccache.config` which works well with React Native projects (it has the same values as the guide mentions).
For context, I posted about this change in the ios channel of the contributors Discord server, where I discussed it with cipolleschi and saadnajmi
### Additional output printed when running `pod install`
#### When `ccache_available and ccache_enabled`
```
[Ccache]: Ccache found at /opt/homebrew/bin/ccache
[Ccache]: Setting CC, LD, CXX & LDPLUSPLUS build settings
```
#### When `ccache_available and !ccache_enabled`
```
[Ccache]: Ccache found at /opt/homebrew/bin/ccache
[Ccache]: Pass ':ccache_enabled => true' to 'react_native_post_install' in your Podfile or set environment variable 'USE_CCACHE=1' to increase the speed of subsequent builds
```
#### When `!ccache_available and ccache_enabled`
```
[!] [Ccache]: Install ccache or ensure your neither passing ':ccache_enabled => true' nor setting environment variable 'USE_CCACHE=1'
```
#### Otherwise
If the user doesn't have ccache installed and doesn't explicitly opt into this feature, nothing will be printed.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Added better support for `ccache`, to speed up subsequent builds of native code. After installing `ccache` and running `pod install`, the Xcode project is injected with compiler and linker build settings pointing scripts that loads a default Ccache configuration and invokes the `ccache` executable.
Pull Request resolved: https://github.com/facebook/react-native/pull/42051
Test Plan:
I've tested this manually - would love some inspiration on how to automate this, if the reviewer deem it needed.
To test this locally:
1. Install Ccache and make sure the `ccache` executable is in your `PATH` (verify by running `ccache --version`)
2. Create a new template app instance and apply the changes of this PR to the `node_modules/react-native` package.
3. Set the `USE_CCACHE` environment variable using `export USE_CCACHE=1`.
4. Run `pod install` in the `ios` directory.
5. Check the stats of Ccache (running `ccache -s`).
6. Run `npm run ios` or build the project from Xcode.
7. Check the Ccache stats again to verify ccache is intercepting compilation ("Cacheable calls" should ideally be 100%).
8. To check the speed gain:
a. Delete the `ios/builds` directory
b. Zero out the ccache stats (by running `ccache -z`)
c. Run `pod install` again (only needed if you ran the initial `pod install` with new architecture enabled `RCT_NEW_ARCH_ENABLED=1`).
d. Run `npm run ios` or build the project from Xcode.
e. This last step should be significantly faster and you should see "Hits" under "Local storage" in the ccache stats approach 100%.
Reviewed By: huntie
Differential Revision: D52431507
Pulled By: cipolleschi
fbshipit-source-id: 6cfe39acd6250fae03959f0ee74d1f2fc46b0827
Summary:
This PR fixes https://github.com/facebook/react-native/issues/41874.
## 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] - Fix NSAppTransportSecurity being overwritten during pod install
Pull Request resolved: https://github.com/facebook/react-native/pull/41875
Test Plan:
1. Delete the whole `NSAppTransportSecurity` in Info.plist and run `pod install`: `NSAllowsArbitraryLoads` and `NSAllowsLocalNetworking` are added as expected.
2. Modify `NSAppTransportSecurity` to only contain `NSExceptionDomains` and run `pod install`: `NSAllowsArbitraryLoads` and `NSAllowsLocalNetworking` are added, and `NSExceptionDomains` is still there.
3. Run `pod install` again: nothing changes.
Reviewed By: christophpurrer
Differential Revision: D52032400
Pulled By: dmytrorykun
fbshipit-source-id: 48cf29809c283af80613ffbf1ac0dc663a0a2fb5
Summary:
Currently React Native defines `NDEBUG` flag for all pods in Fabric only. This is useful for other libraries, like Reanimated, because they have no easy way of defining their compilation flags (at least none that I know of). Therefore defining `NDEBUG` for both architectures would be beneficial.
## Changelog:
Pick one each for the category and type tags:
[IOS] [CHANGED] - Add `NDEBUG` flag for Release builds for both architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/41715
Test Plan:
Run ruby test suite.
## Notes
For the time being I just copied
`prepare_pod_target_installation_results_mock`
and
`def prepare_installer_for_cpp_flags`
to `utils-test.rb` since I wasn't sure how to handle the installer mock.
Reviewed By: cortinico
Differential Revision: D51708382
Pulled By: cipolleschi
fbshipit-source-id: ff206f8fc151934dbae89aacd1bc69c57b4f28ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41561
The RN_FABRIC_ENABLED has been deprecated and superseded by the RCT_NEW_ARCH_ENABLED for a while now.
This change removes it, from the codebase as now we always have the Fabric pod available to the codebase.
## Changelog
[Internal] - Remove RN_FABRIC_ENABLED flag
Reviewed By: dmytrorykun
Differential Revision: D51468332
fbshipit-source-id: 6b2fc554e6bf5ac748b9e45d7c14f9ba9b57820c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41500
Right now, the old architecture uses Codegen in a slightly different way w.r.t. the New Architecture.
In the Old Architecture, codegen is used to generate some basic TM and components that are part of Core.
Both architectures use the same scripts that actually generates the code, but they are invoked differently.
This is causing some maintenance costs that we would like to reduce.
## Changelog:
[Internal] - Defragment how Codegen is run between old and new architecture
Reviewed By: dmytrorykun
Differential Revision: D51349874
fbshipit-source-id: 188d3ed436a30a77bd42a26306d4a08666d3a00b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41486
Now that React-Hermes does not depends on folly::Futures anymore, we can safely delete the `libevent` dependency.
This will speedup the pod install step and potentially also the bundle size (to be tested)
## Changelog
[iOS][Removed] - Remove libevent dependency
Reviewed By: javache
Differential Revision: D51307333
fbshipit-source-id: 029c1d6aaad46fc261502241f7df28b4d5f59eb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41358
This change expose a missing function to create Header Search Paths when a podspec can't depend on another one explicitly.
This also migrate the ruby code to this new function.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068390
fbshipit-source-id: ba9e09cd2f0671a9f3f00cc72496a0d5682eeb90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41354
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that automate adding a dependency to a podspec and it generates the required search paths.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51027343
fbshipit-source-id: 33ac4c07112eacb08067220397e38db0a19240fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41353
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that should factor out the platforms from the generation of header search paths.
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51026356
fbshipit-source-id: 7cf03601d94d7680f3fdfcaf52b2fd6bcd48c5b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41002
Following up the deprecation of Flipper in 0.73 and preparing for the removal of Flipper in 0.74, we are removing Flipper integration from the Codebase.
## Changelog:
[iOS][Breaking] - Remove the Flipper integration
Reviewed By: dmytrorykun
Differential Revision: D50321255
fbshipit-source-id: d2f4488ada7acdbd3687f54db4204ba7f09370af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39710
Last week Apple released Xcode 15, which required us to ship a workaround for the new linker.
Unfortunately, the previous fix was not good enough and there were some edge cases that were not covered.
For example, in some occasions the flags are read as an array and the `-Wl` and the `-ld_classic` flags were separated and not properly removed when moving from Xcode 15 to Xcpde 14.3.1.
This change fixes those edge cases, with a more robust solution where:
- We convert the flags to a string.
- We trim the string and the values properly.
- We add the flags when running `pod install` with Xcode 15 as the default iOS toolchain.
- We remove the flags when running `pod install` with Xcode <15 as the default iOS toolchain.
## Changelog:
[Internal] - Make the Xcode 15 workaround more robust.
Reviewed By: dmytrorykun
Differential Revision: D49748844
fbshipit-source-id: 34976d148f123c5aacba6487a500874bb938fe99
Summary:
Thanks for working through Xcode 15 compatibility issues!
I reviewed the diff of the PR (https://github.com/facebook/react-native/issues/39474) that altered Xcode 15 settings for react-native release 0.72.5 and I noticed that
- everything looked great (worth saying)
- there was a grammatical error in another of the method names
Trivial errors but, as long as I was in there, thought I'd submit a PR
## Changelog:
[IOS] [FIXED] - fix grammar in Xcode 15 helper method name
Pull Request resolved: https://github.com/facebook/react-native/pull/39658
Test Plan: CI should catch it of course, but in general I did a full grep for the name and changed everything / typical method name refactor
Reviewed By: cortinico
Differential Revision: D49641551
Pulled By: cipolleschi
fbshipit-source-id: d77d33bbd6941f039dd30766e1308d5c4c4a6ca8
Summary:
Fix typo in `packages/react/native/scripts/cocoapods/utils.rb`
## 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] - Fix the typo for the method `is_using_xcode15_or_greater`
Pull Request resolved: https://github.com/facebook/react-native/pull/39572
Reviewed By: dmytrorykun
Differential Revision: D49594275
Pulled By: cortinico
fbshipit-source-id: 8637fc9b10cfad3742b038ed9402585fe2af56b7
Summary:
While merging new commits into React Native macOS, I noticed https://github.com/facebook/react-native/pull/39478/
I would like to also set `MACOS_DEPLOYMENT_TARGET` in our fork, and thought this slight rename would be something I can do upstream
## Changelog:
[Internal] - updateIphoneOSDeploymentTarget -> updateOSDeploymentTarget
Pull Request resolved: https://github.com/facebook/react-native/pull/39570
Test Plan: CI should pass
Reviewed By: NickGerleman
Differential Revision: D49514693
Pulled By: ryancat
fbshipit-source-id: b4dafb1f9736d2977510712652cb8097263c489d
Summary:
Remove Xcode 15 `_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION` workaround for boost. If we update boost, we don't need the workaround anymore.
This PR is based on https://github.com/facebook/react-native/issues/39552. Not sure how Meta internally deal with stacked PRs. This PR just adds a new commit based on https://github.com/facebook/react-native/issues/39552 anyway.
## Changelog:
[IOS][CHANGED] - Remove Xcode 15 `_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION` workaround for boost
Pull Request resolved: https://github.com/facebook/react-native/pull/39555
Test Plan: RNTester + Xcode 15
Reviewed By: cortinico
Differential Revision: D49454494
Pulled By: cipolleschi
fbshipit-source-id: aacabaa130b61598cf8bd206fdbb96d3b50ba74f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39474
When it comes to Xcode 15 RC, we are aware of two issues:
1. `unary_function` and `binary_function` not available in Cxx17
2. [Weak linking](https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking) is not supported anymore.
This change should fix both of the issues, adding the flags to allow for `unary_function`and `binary_function` to be called and adding the `-Wl -ld_classic` flag to `OTHER_LDFLAGS` in case Xcode 15 is detected.
## Changelog:
[Internal] - add the `_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION` and the `-Wl -ld_classic` flags to projects when needed
Reviewed By: dmytrorykun
Differential Revision: D49319256
fbshipit-source-id: bb895f1e60db915db79684f71fa436ce80b42111
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39478
When testing Xcode 15, we realized that a few pods we do not control directly have the IPHONEOS_DEPLOYMENT_TARGET set to old versions of iOS.
We can update that setting to silence the warning with Cocoapods and this is what this script does.
Notice that bumping that setting generated other warning as some APIs have been deprecated.
## Changelog:
[Internal] - Bump min IPHONEOS_DEPLOYMENT_TARGET for 3rd party pods
Reviewed By: dmytrorykun
Differential Revision: D49274837
fbshipit-source-id: 584d105c76d654daa2ecf5eb2f1b9381e70f567a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39454
1. Build with C++ 20 everywhere.
2. Update folly in OSS build to avoid a warning, and let us opt out of heavy bits required for supporting coroutines (we are still more than a year behind).
3. Update the folly podspec for the new version of folly
4. Update the many, many, copy/pasted header search paths for folly dependencies to be able to resolve fmt, now exposed to folly headers
4. Replaces a deprecated atomic usage with equivalent.
5. Fixes a deprecated implicit capturing `this` by value in lambda (same behavior, added a TODO because it seems sus)
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D49271685
fbshipit-source-id: 16610f7bcd1032d5796cc11f1cfa92a33d8c2593
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39389
The Podfile of the Template is using a function called `get_default_flags` to get the default flags.
Its behavior is duplicated in both the default value of the `use_react_native!` function and in the body of the same function, making that helper actually redundant.
In this change, we are deprecating it so we can remove it in 0.74 with no breakages.
## Changelog:
[iOS][Deprecated] - Deprecate `get_default_flags` in Ruby scripts
Reviewed By: dmytrorykun
Differential Revision: D49147290
fbshipit-source-id: 41a9f9aa4ba5d1a31d86953fe78778b45d28d9b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39128
`HERMES_ENABLED` was supposed to indicate wether hermes-engine pod is present in the project. It was initialized by grepping `hermes-engine` from `Podfile.lock`.
This is redundant because Hermes is enabled by default and it is sufficient to check that `$USE_HERMES != false` for cases that are Hermes specific.
Changelog: [Internal] - Remove usage of HERMES_ENABLED from react-native-xcode.sh
Reviewed By: cipolleschi
Differential Revision: D48600174
fbshipit-source-id: 522d4edb89517fd432cc159624a41219c9e00124
Summary:
- if an existing iOS project specifies `EXCLUDED_ARCHS`, these settings are overwritten by the `react_native_post_install` step as part of the Cocoapods install
- this can break the build of existing iOS apps that want to include React Native
- a previous PR (https://github.com/facebook/react-native/pull/38132) updated the Cocoapods utils to that we only update `EXCLUDED_ARCHS` when using Hermes
- this worked around the issue for apps that opted to use JSC
- however if you _do_ want to use Hermes (the default) this problem persists
### Existing Behaviour
- one of the functions called as part of the `react_native_post_install` step is `exclude_i386_architecture_while_using_hermes`
- see [/packages/react-native/scripts/cocoapods/utils.rb](https://github.com/facebook/react-native/blob/v0.72.1/packages/react-native/scripts/cocoapods/utils.rb#L56-L69)
```
def self.exclude_i386_architecture_while_using_hermes(installer)
projects = self.extract_projects(installer)
# Hermes does not support `i386` architecture
excluded_archs_default = self.has_pod(installer, 'hermes-engine') ? "i386" : ""
projects.each do |project|
project.build_configurations.each do |config|
config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = excluded_archs_default
end
project.save()
end
end
```
🐛 **However** 🐛
- this means existing projects that have `EXCLUDED_ARCHS` set, the existing value will be overwritten either to `"i386"` or a blank string
### Changed Behaviour
- appends `"i386"` to existing string if set, or just sets the value to `"i386"` if there is no existing value
## 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] don't override `EXCLUDED_ARCHS` when installing Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/39060
Reviewed By: dmytrorykun
Differential Revision: D48515441
Pulled By: cipolleschi
fbshipit-source-id: 8cb3c8b680d92272da0b106553179af051d0f84e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38879
When creating a new app for iOS, you need to have Node installed properly and in the right paths in order for Xcode to pick it up.
Xcode, by default, looks into the following folders for executables:
- /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
- /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/appleinternal/bin:
- /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/local/bin:
- /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/libexec
- /Applications/Xcodefb.app/Contents/Developer/Platforms/iPhoneSimulator.platform/usr/bin
- /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/usr/appleinternal/bin
- /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/usr/local/bin
- /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin
- /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/local/bin
- /Applications/Xcode.app/Contents/Developer/usr/bin
- /Applications/Xcode.app/Contents/Developer/usr/local/bin
- /usr/local/bin
- /usr/bin
- /bin
- /usr/sbin
- /sbin
If `node` is not in one of them, our JS codegen scripts will fail to run. However, as soon as we run some scripts in Xcode, it is too late to properly look for node.
We already had a cocoapod step, running before the build phase, which was creating the `.xode.env` file, setting `NODE_BINARY` to `$(command -v node)`. Unfortunately, when executed by Xcode, that's too late too.
This change creates an `.xcode.env.local` file with the `$(command -v node)` command expanded, so I user can start working locally and quickly.
We had multiple reports and issues related to this configuration online. For example:
- https://www.reddit.com/r/reactnative/comments/15jpj0a/is_there_a_react_native_version_that_just_works/?utm_source=share&utm_medium=web2x&context=3
Note: we cannot automatically create simlinks to node in `/usr/local/bin` as it requires `sudo`.
## Changelog:
[Internal] - Generate `.xcode.env.local` to simplify the creation of an app.
Reviewed By: rshest
Differential Revision: D48111724
fbshipit-source-id: 49cc6375bd80458d69adbc343ead6c4408805eee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38549
Out of tree platforms may need different implementations of ViewProps. In fact, Android does already with props like `needsOffscreenAlphaCompositing` and `focusable`. This diff is not opinionated on whether these props should actually be shared on all platforms. Props like `focusable` may be a good candidate for generalizing to all platforms. However, there will always be a need for one platform to experiment with a new prop while it's not available yet on another, especially when considering out of tree platforms.
This diff moves the existing ViewProps class to BaseViewProps, aliases ViewProps as BaseViewProps for iOS for now, and moves Android-specific view props to it's own header and implementation.
## Changelog:
[General] [Added] - Support additional View props in out of tree platform Fabric implementations
Reviewed By: christophpurrer
Differential Revision: D47492635
fbshipit-source-id: 5739174a2b1d28ba84f4398ccc1cc0b846ebea79
Summary:
Use Apple Silicon instead of M1 because we have M2 and other variations too.
I did not change the name of `__apply_Xcode_12_5_M1_post_install_workaround` as it's in use.
## 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] - Use Apple Silicon instead of M1
Pull Request resolved: https://github.com/facebook/react-native/pull/38344
Test Plan: None as no behavioral changes
Reviewed By: christophpurrer
Differential Revision: D47466540
Pulled By: javache
fbshipit-source-id: d770189e065899181a8b4ea17465beef09607d2f
Summary:
Currently, we ask users to reinstall the pods using the `PRODUCTION` flag when they want to either profile their app or prepare a release.
This way of working with the Release mode is not standard. One of the reason why we introduced it was to provide a different binary for Hermes and reinstalling the pods was the quickest way.
With this change, we are deferring the decision on when Hermes should be installed for apps to the moment where the app is actually build by the system.
These changes are not applied to Nightlies, when a specific tarball is passed to the cocoapods using the `HERMES_ENGINE_TARBALL_PATH` env var, and when hermes is built from source as in these scenarios we are usually not interested in building for Release.
The system is also smart enough not to redownload the tarball if the configuration does not change. It assumes that the default configuration when the pods are installed for the first time is Debug.
## Changelog:
[IOS] [CHANGED] - Download the right `hermes-engine` configuration at build time.
Pull Request resolved: https://github.com/facebook/react-native/pull/37850
Test Plan:
- CircleCI green for the Release template jobs
- Tested locally modifying the `hermes-utils` to force specific versions.
- Tested locally with RNTestProject
Reviewed By: dmytrorykun
Differential Revision: D46687390
Pulled By: cipolleschi
fbshipit-source-id: 375406e0ab351a5d1f5d5146e724f5ed0cd77949
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37723
React-hermes pod sets the `GCC_PREPROCESSOR_DEFINITIONS` flag for Debug config only, by leveraging the `PRODUCTION=1` flag.
This flag is not standard for iOS, therefore we want to remove it from the condebase to simplify the build APIs.
This change moves the setting of the `GCC_PREPROCESSOR_DEFINITIONS` flag from the podspec xcconfig (which can't distinguish between Debug and Release configurations) to a post install hook (which can).
## Changelog:
[internal] - Remove dependency on PRODUCTION=1 from React-hermes podspec
Reviewed By: dmytrorykun
Differential Revision: D46316662
fbshipit-source-id: b5764e1bf60f2e71ff171556bccbc00c0c0c62aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37276
When enabling dynamic linking, we had a circulr dependency between Fabric and the Image Manager.
Specifically, Image Manager depends on Fabric, but the Image component, in Fabric, is using some implementation specific files from the Image Manager that surface only when enabling the dynamic linking.
Xcode fails to find those symbols unless the dependencies are explicitly added to the podspec.
This change is technically breaking, but we tried to minimize the breakage by adding the new pod in all the required search paths.
## Changelog
[iOS][Breaking] - Add React-FabricImage pod.
Reviewed By: NickGerleman
Differential Revision: D45517278
fbshipit-source-id: 994aa8c40301c68bf9fecdf46de7833028f0d3c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37228
As discussed offline, the current approach for the Hermes profiler is not the right one.
I'm partially reverting [the commit](https://github.com/facebook/react-native/commit/dce9d8d5de381fe53760ddda0d6cbbdfb5be00e4) which introduced it.
The commit did also a bit of refactoring to improve the quality of the cocoapods scripts we would like to keep.
## Changelog:
[iOS][Removed] - Remove support of Hermes profiler as that's not the right approach.
Reviewed By: cortinico
Differential Revision: D45527507
fbshipit-source-id: acea5f8b610d8b67ee7a6a91993bb8e4592d093f
