Summary:
when integrates with swift, the compiler will build clang module based on the *React-Core-umbrella.h*. however, the include chain reaches some c++ headers that are not available from swift. it will cause build error.

this pr adds `#ifdef __cplusplus` guard for it.
## Changelog
[iOS] [Fixed] - Fix React module build error with swift integration on new architecture mode
Pull Request resolved: https://github.com/facebook/react-native/pull/34527
Test Plan:
one thing we didn't figure out is that we require reanimated to repro the build error.
1. `npx react-native init RN070 --version 0.70.0-rc.4`. # can also repro this issue on 0.69
2. `cd RN070`
3. `yarn add react-native-reanimated@next`
4. `cd ios && rm -rf Pods build && RCT_NEW_ARCH_ENABLED=1 pod install`
5. add `import React;` in `main.m` for clang module generation
```diff
--- a/ios/RN070/main.m
+++ b/ios/RN070/main.m
@@ -1,5 +1,6 @@
#import <UIKit/UIKit.h>
+@import React;
#import "AppDelegate.h"
int main(int argc, char *argv[])
```
6. `yarn ios`
Reviewed By: cipolleschi
Differential Revision: D39128716
Pulled By: jacdebug
fbshipit-source-id: d9e9130f99e3b9e5f7807c475a24cdd84880e720
Summary:
This fix solves a problem very well evaluated [here](https://github.com/Expensify/App/issues/2727) as well as this [one](https://github.com/facebook/react-native/issues/29290).
The issue is that when the app goes to background, in landscape mode, the RCTDeviceInfo code triggers an orientation change event that did not physically happen. Due to that, we get swapped values returned when going back to the app.
I debugged the react-native code, and to me it seems that react native publishes the orientation change event one extra time when switching the state of the app to 'inactive'. Here is what is happening:
1. iPad is in landscape.
2. We move the app to inactive state.
3. Native Code queues portrait orientation change (no such change happened physically), and immediately after it triggers landscape change (same as we had in point 1).
4. We restore the app to active state.
5. The app receives two queued orientation change events, one after another.
6. The quick transition between portrait and landscape happens even though it never went back to portrait.
Fresh `react-native init` app repro case can be found here: https://github.com/lbaldy/issue-34014-repro
Video presenting the issue (recorded while working on: https://github.com/Expensify/App/issues/2727 ): https://www.youtube.com/watch?v=nFDOml9M8w4
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix the way the orientation events are published, to avoid false publish on orientation change when app changes state to inactive
Pull Request resolved: https://github.com/facebook/react-native/pull/34014
Test Plan:
### Test Preparation
1. Make sure you have a working version of E/App.
2. Open App/src/components/withWindowDimensions.js and update the constructor by changing this line:
`this.onDimensionChange = _.debounce(this.onDimensionChange.bind(this), 100);`
to
`this.onDimensionChange = this.onDimensionChange.bind(this);`
3. Open the NewExpensify.xcodeproj in xCode.
4. Open the RCTDeviceInfo.mm file and replace it's contents with the file from this PR.
5. Select your device of choice (I suggest starting with iPad mini) and run the app though xCode.
6. From this point you can move to the test scenarios described below.
### iPad Mini tests:
Reproduction + Fix test video (Test 1): https://youtu.be/jyzoNHLYHPo
Reproduction + Fix test video (Test 2): https://youtu.be/CLimE-Fba-g
**Test 1:**
1. Launch app in portrait, open chat - no sidebar visible.
7. Switch to landscape - sidebar shows.
8. Put app to background.
9. Put app back to foreground - make sure the side menu doesn't flicker.
**Test 2:**
1. Launch app in portrait, open chat - no sidebar visible.
2. Switch to landscape - sidebar shows.
3. Put app to background. Switch orientation back to portrait.
4. Put app back to foreground - make sure the side menu hides again as it should be in portrait.
### iPad Pro tests:
Reproduction + Fix test video (Test 3, Test 4): https://youtu.be/EJkUUQCiLRg
iPad mini test 1 applies.
Scenario 2 does not as the screen is too wide in both orientations and iPad pro shows sidebar always.
**Test 3:**
1. launch the app.
2. Make sure you're in landscape mode.
3. See split screen with some other app. Make sure the side bar is visible.
4. Play with the size of the view, resize it a bit. When the view shrinks it should hide the sidebar, when it grows it should show it.
10. Move the app to background and back to foreground, please observe there are no flickers.
**Test 4:**
1. Launch the app.
2. Make sure you're in landscape mode.
3. Make the multitasking view and make Expensify app a slide over app.
4. Move back to fullscreen/split screen. Make sure the menu is shown accordingly
5. Move the app to background and back to foreground, please observe there are no flickers.
### iPhone:
Non reg with and without the fix video: https://youtu.be/kuv9in8vtbk
Please perform standard smoke tests on transformation changes.
Reviewed By: cipolleschi
Differential Revision: D37239891
Pulled By: jacdebug
fbshipit-source-id: e6090153820e921dcfb0d823e0377abd25225bdf
Summary:
In https://github.com/facebook/react-native/pull/32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock.
This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements.
With this change, the clock is now monotonic (and the implementation stays consistent between platforms).
More details and repro steps can be found in [this issue](https://github.com/facebook/react-native/issues/33977)
Closes https://github.com/facebook/react-native/issues/33977
## Changelog
[General] [Fixed] - Use monotonic clock for performance.now()
Pull Request resolved: https://github.com/facebook/react-native/pull/33983
Test Plan:
Run on iOS and Android:
```
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: JoshuaGross, cipolleschi
Differential Revision: D37066999
Pulled By: dmitryrykun
fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b
Summary:
Using Fabric with a Swift native module is currently broken. There are currently two issues.
If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules.
To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries),
you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`.
Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix using Swift in a native module with Fabric enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/33743
Test Plan:
1. Clone [this](https://github.com/fortmarek/react-native) repo
2. From `main`, apply changes from [this](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58) commit (adding Swift file to the `MyNativeView` native module in the RN tester app)
3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester`
4. Observe errors
5. Apply [the commit](https://github.com/facebook/react-native/commit/9772c6209d73257f679b76407e1b5a27ffe03219) from this PR
6. Both pod install and the subsequent build should succeed.
I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main`
Reviewed By: dmitryrykun
Differential Revision: D36097852
Pulled By: cipolleschi
fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
Summary:
This would fix test errors caused by including <string> in non-C++ compatible files.
Changelog:
[General][Changed] - Remove usage of std::string in EarlyJsErrorHandler.
Reviewed By: RSNara
Differential Revision: D35645334
fbshipit-source-id: 7f04d2c66d53dc1eef63367de1a64ed9273898f5
Summary:
Changelog:
[iOS][Fixed] - Expose the extraData dict attached to JavaScript errors to the native ExceptionManager on iOS, similar to Android
Attaching the `extraData` dict to JavaScript crash reports is something that was done for Android only in 2019 (D16133080 (https://github.com/facebook/react-native/commit/3a825c036065783aae6fb734028f986dbead80d7)), and somehow we never really got around to adding it in iOS. This diff finally adds the capability to iOS as well. `extraData` can be used to attach various bits of data to a crash report for better debugging and categorization. As with the Android implementation, `extraData` is not attached if the `reportException` API is not used.
Reviewed By: dmitryrykun
Differential Revision: D35743658
fbshipit-source-id: de4060cb6e514db1d85907441a8962f98e9b8392
Summary:
Apple suggested to this new API on iOS 10+.
> // Any new bitmap drawing code is encouraged to use UIGraphicsImageRenderer in lieu of this API.
WWDC18 Reference: https://developer.apple.com/videos/play/wwdc2018/219/
> Use UIGraphicsImageRenderer to create and draw to an image buffer
Supports Wide Color, unlike UIGraphicsBeginImageContext()
Combine with UIImageView for efficient offscreen rendering
Per https://nshipster.com/image-resizing/#performance-benchmarks, the new API runs even faster than the C version, probably due to more smart context reuses/management.
Changelog:
[iOS][Changed] - Adopt UIGraphicsImageRenderer API
Reviewed By: philIip
Differential Revision: D35699584
fbshipit-source-id: 7a1e2109d5e121fb396c1014f4ed0a892211b0cc
Summary:
This PR updates `RCTMountingTransactionObserving` protocol to accept full `MountingTransaction` object as an argument to its methods as opposed to just `MountingTransactionMetdata` which contained only some subset of information.
This change makes it possible for components implementing the protocol to analyze the list of mutations and hence only take action when certain mutations are about to happen.
One of the use cases for `RCTMountingTransactionObserving` protocol is to allow for Modal to take view snapshot before it is closed, such that an animated close transition can be performed over the snapshotted content. Note that when modal is removed from the view hierarchy its children are gone too and therefore the snapshot mechanism makes it possible for children to still be visible while the animated closing transition is ongoing. A similar use-case to that can be seen in react-native-screens library, where we use the same snapshot mechanism for views that are removed from navigation stack.
Before this change, we'd use `mountingTransactionDidMountWithMetadata` to take a snapshot. However, making a snapshot of relatively complex view hierarchy can be expensive, and we'd like to make sure that we only perform a snapshot when the given modal is about to be removed. Because the mentioned method does not provide an information about what changes are going to be performed in a given transaction, we'd make the snapshot for every single view transaction that happens while the modal is mounted.
In this PR we're updating `RCTMountingTransactionObserving` protocol's methods, in particular, we rename methods to no longer contain "Metadata" in them and to accept `MountingTransaction` as the only argument instead of `MountingTransactionMetadata` object. With this change we are also deleting `MountingTransactionMetadata` altogether as it has no uses outside the protocol. Finally, we update the two uses of the protocol in `RCTScrollViewComponentView` and `RCTModalHostViewComponentView`.
## Changelog
[iOS][Fabric] - Update RCTMountingTransactionObserving protocol to consume MountingTransaction objects
Pull Request resolved: https://github.com/facebook/react-native/pull/33510
Test Plan:
As there are not that many uses of `RCTMountingTransactionObserving` protocol during testing I focused on checking if the updated method is called and if the provided objects contains the proper data. Unfortunately, despite code for the modal protocol being present in OSS version it does seem like some parts of modal implementation are still missing and the component only renders an unimplemented view (checked this with rn-tester). I only managed to verify the use in `RCTScrollViewComponentView` with the following steps:
1. Build for iOS
2. Put a breakpoint in mountingTransactionDidMount method in `RCTScrollViewComponentView.mm`
3. Verify that the program stops on the breakpoint when a scrollview is rendered (use any screen on rn-tester app)
4. Inspect the provided object in the debugger (ensure the list of transactions is not empty)
Outside of that we verified the transactions can be processed in `mountingTransactionDidMount` after the changes from this PR are applied in FabricExample app in [react-native-screens](https://github.com/software-mansion/react-native-screens/tree/main/FabricExample) repo.
Reviewed By: cipolleschi
Differential Revision: D35214478
Pulled By: ShikaSD
fbshipit-source-id: f40afc512f2c8cfa6262d2fb82fb1ccb05aa734c
Summary:
`hotkeysEnabled` property is added to `RCTDevMenu` which allows enabling/disabling hotkeys that triggers developer menu popup
Changelog:
[iOS][Added] - `hotkeysEnabled` property is added to `RCTDevMenu` which allows enabling/disabling hotkeys that triggers developer menu popup
Reviewed By: arhelmus
Differential Revision: D35777883
fbshipit-source-id: a7435358701bedb54e33198724180eb1c27248b8
Summary:
We've seen a couple of `EXC_BAD_ACCESS` crashes in [`RCTParagraphComponentAccessibilityProvider.mm:L125`](https://github.com/facebook/react-native/blob/52d8a797e7a6be3fa472f323ceca4814a28ef596/React/Fabric/Mounting/ComponentViews/Text/RCTParagraphComponentAccessibilityProvider.mm#L125), most likely explained by [RCTLocalizationProvider RCTLocalizedString] returning nil, which will happen in the case that a language pack has no entry for the input string.
This is a small defensive change to fall back to the input if there's no better alternative.
Changelog:
[iOS][Fixed] - `RCTLocalizationProvider` Fall back to input when no localization is available
Reviewed By: luluonet
Differential Revision: D35583786
fbshipit-source-id: e8ae6ff61518e105301e7e51f5d8f43290fb20bf
Summary:
Changelog: [Internal][iOS] Add validation log to the only static method in RCTUIManager, JSResponder
When all surfaces of an app has been fully migrated to Fabric, we don't expect `[RCTUIManager JSResponder]` to be called, so I'm expecting this API to be broken on Fabric and Bridgeless.
Reviewed By: RSNara
Differential Revision: D35723794
fbshipit-source-id: ec786946a33fca98c89e8cad0e0467bf45dc1735
Summary:
Changelog: [internal]
we have an issue where the moduleRegistry that the TM uses is released, adding this log to check if it's bc the bridge was released
Reviewed By: RSNara
Differential Revision: D35420922
fbshipit-source-id: 93c206b5afefeac3121df148940d9658736cb9d2