Summary:
This PR implements a C API to switch JS Engines that can be used from Swift.
Here is an example:
```swift
import React
import React_RCTAppDelegate
import ReactAppDependencyProvider
import UIKit
import RCTRuntime
class ReactNativeDelegate: RCTDefaultReactNativeFactoryDelegate {
override func sourceURL(for bridge: RCTBridge) -> URL? {
self.bundleURL()
}
override func bundleURL() -> URL? {
#if DEBUG
RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
#else
Bundle.main.url(forResource: "main", withExtension: "jsbundle")
#endif
}
override func createJSRuntimeFactory() -> JSRuntimeFactory {
jsrt_create_jsc_factory() // Easily switch engines here
}
}
```
## Changelog:
[IOS] [ADDED] - js runtime C API for Swift
Pull Request resolved: https://github.com/facebook/react-native/pull/49489
Test Plan: CI Green
Reviewed By: huntie
Differential Revision: D69976988
Pulled By: cipolleschi
fbshipit-source-id: 9333ec62ca99a28c3121f558bbff1ce0457779e3
Summary:
an effort of lean core for jsc: https://github.com/Kudo/discussions-and-proposals/blob/%40kudo/lean-core-jsc/proposals/0836-lean-core-jsc.md. this pr tries to decouple all jsc code when `USE_THIRD_PARTY_JSC=1` on ios
this pr includes these changes:
- exclude `React-jsc` pod and pod dependency when `USE_THIRD_PARTY_JSC=1`
- in objcpp code, remove `JSCExecutorFactory` / `RCTJscInstance` references when `USE_THIRD_PARTY_JSC=1`. it throws c++ errors like `No JSRuntimeFactory specified.` when no engine is specified (USE_HERMES=0 && USE_THIRD_PARTY_JSC=1). people need to override delegate methods to specify a JSRuntimeFactory.
## Changelog:
[IOS] [CHANGED] - Decouple JSC when `USE_THIRD_PARTY_JSC=1`
Pull Request resolved: https://github.com/facebook/react-native/pull/49371
Test Plan:
- ci passed
- rn-tester build success for `RCT_NEW_ARCH_ENABLED=1 USE_THIRD_PARTY_JSC=1 USE_HERMES=0 USE_FRAMEWORKS=dynamic bundle exec pod install`
- rn-tester build success for `RCT_NEW_ARCH_ENABLED=0 USE_THIRD_PARTY_JSC=1 USE_HERMES=0 USE_FRAMEWORKS=dynamic bundle exec pod install`
- rn-tester build success for `RCT_NEW_ARCH_ENABLED=0 USE_THIRD_PARTY_JSC=1 USE_HERMES=0 bundle exec pod install`
Reviewed By: cortinico
Differential Revision: D69662457
Pulled By: cipolleschi
fbshipit-source-id: b272f46dde896d0981cfca75c9bfcf6775507307
Summary:
> [!NOTE]
> This PR is part of JavaScriptCore Extraction to this repository: https://github.com/react-native-community/javascriptcore
This PR centralizes the setup of js engine dependencies which need to be defined when building with dynamic frameworks. This will allow us to change linked framework if using a third party one in the future
## Changelog:
[INTERNAL] [CHANGED] - centralize JS engine dependency configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/49297
Test Plan: CI Green (Build needs to go properly)
Reviewed By: javache
Differential Revision: D69396641
Pulled By: cipolleschi
fbshipit-source-id: deedd12084f563f73f12f8617fdca0a6d680bf5a
Summary:
Originally with https://github.com/facebook/react-native/commit/5cf8f43ab182781ea82e88077df425c3efbfc21f , we added a call to a new Apple API `JSGlobalContextSetInspectable` to ensure that our Javascript running with JSC is debuggable. That change was guarded with a `__builtin_available(macOS 13.3, iOS 16.4, tvOS 16.4, *)` check to make sure it only ran on OS'es where to function existed. Later, in https://github.com/facebook/react-native/commit/3eeee11d7ac4075d0917233d3be4a9469f802d35 we did an extra guard in the way of a macro to check we were compiling against a new enough version of Xcode (so that Xcode knows about the symbol).
Between the runtime check and the compile time check, we should be good right? Wrong! As it turns out, this bit of code still caused crashes on iOS 15 devices (See this [Apple Forum Thread](https://forums.developer.apple.com/forums/thread/749534)). To address this, https://github.com/facebook/react-native/pull/44185 was added which added a new compiler guard (`__OSX_AVAILABLE_STARTING(MAC_NA, IPHONE_16_4)` was added. Unfortunately, this guard is incorrect: It is basically checking if our minimum iOS deployment target is 16.4 (It's not, as of writing it is iOS 13.4), which effectively means this code is never compiled and one can never direct debug with JSC on iOS 16.4+ 😨!
So what went wrong, and why were the first two guards not good enough? Three main reasons..
Firstly, this is a device only crash, and not reproducible on simulator. This is probably why the crash was not caught earlier. Secondly, It's because system frameworks (like JavascriptCore) are _dynamically_ linked: the linker doesn't look for the symbol till runtime (and crashes when doing so). Thirdly, It's because we are _strongly_ linking the framework, so every symbol must be present and the macros / guard Apple provides with `AvailabilityMacros.h` don't work.
What we want to do is link JavascriptCore as a `weak_framework`, more info here: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
From that link:
> One challenge faced by developers is that of taking advantage of new features introduced in new versions of OS X while still supporting older versions of the system. Normally, if an application uses a new feature in a framework, it is unable to run on earlier versions of the framework that do not support that feature. Such applications would either fail to launch or crash when an attempt to use the feature was made. Apple has solved this problem by adding support for weakly-linked symbols.
>When a symbol in a framework is defined as weakly linked, the symbol does not have to be present at runtime for a process to continue running. The static linker identifies a weakly linked symbol as such in any code module that references the symbol. The dynamic linker uses this same information at runtime to determine whether a process can continue running. If a weakly linked symbol is not present in the framework, the code module can continue to run as long as it does not reference the symbol. However, if the symbol is present, the code can use it normally.
This seems to be exactly what we want, and the Apple provided method for using new APIs in system frameworks!
Let's update our podspecs so we link JavascriptCore weakly. As a bonus (and admittedly, the original purpose of this PR) let's add macOS support to the `JSC_HAS_INSPECTABLE` macro (This file `JSCRuntime.cpp` used to have more explicit macOS support in it's macros, but I had removed it with https://github.com/facebook/react-native/commit/fb30fcaa2f526cc1f7c2d4189ec9c57f9cf9b3c5).
## Changelog:
[IOS] [FIXED] - Fix Direct Debugging with JSC
Pull Request resolved: https://github.com/facebook/react-native/pull/39549
Test Plan:
Tested that RNTester doesn't crash on boot running on an iPad Air 2 running iOS 15.8., and that an iOS 17.2 simulator is debuggable.
Built RN-Tester and RN-Tester-macOS and verified both show up in Safari Web Inspectors' debug menu:
<img width="1316" alt="Screenshot 2023-09-19 at 10 48 43 PM" src="https://github.com/facebook/react-native/assets/6722175/c642e6e0-36af-4c9f-845a-7e491489f419">
macOS screenshot small bc I got some internal stuff I gotta crop 😅
<img width="347" alt="Screenshot 2023-09-19 at 10 53 46 PM" src="https://github.com/facebook/react-native/assets/6722175/1e802c88-02b8-49e1-8fd2-d91726ca1e93">
Reviewed By: huntie
Differential Revision: D67338150
Pulled By: cipolleschi
fbshipit-source-id: 620c3b3cc1e37e54de7fa4dc9956a02c8f3c09f8
Summary:
This PR does some further cleanup on the flags passed to cocoapods.
I've moved `boost_compiler_flags` and `folly_dep_name` to `helpers.rb` file.
## Changelog:
[INTERNAL] [FIXED] - move boost compiler flags and folly dep name to centralized config
Pull Request resolved: https://github.com/facebook/react-native/pull/46513
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D62846105
Pulled By: cipolleschi
fbshipit-source-id: dff07ddb49f1f4b559125f2ed8508b32f08d4975
Summary:
This PR bumps Socket Rocket to 0.7.1, this release brings some new improvements and visionOS support. I've also moved the version to a constant.
## Changelog:
[INTERNAL] [CHANGED] - Bump SocketRocket to 0.7.1
Pull Request resolved: https://github.com/facebook/react-native/pull/46300
Test Plan: CI Green
Reviewed By: cortinico, cipolleschi
Differential Revision: D62294833
Pulled By: blakef
fbshipit-source-id: 0e45c7de041710fb1f500b0ac23898b68a8a8936
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45374
This change factors out the language standard in a separate constant so we can easily control it from a single place.
There are only 2 exception to this:
1. hermes-engine: the podspec is used in CI and it has no access to the rct_cxx_language_standard variable
2. Yoga: it can be used as a separate pod, outside of React Native, so it makes sense to leave it alone.
This change also fixes a problem where, in some setup, the language was set to C++14
## Changelog
[Internal] - Refactor Cxx language standard in a single constant
Reviewed By: dmytrorykun, blakef
Differential Revision: D59629061
fbshipit-source-id: 41eac64e47c14e239d8ee78bd88ea30af244d695
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
reasons:
- C617.1 (RCTJavaScriptLoader)
- CA92.1 (RCTI18nUtil, RCTBundleURLProvider, RCTSettingsManager)
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: sammy-SC
Differential Revision: D55622471
fbshipit-source-id: f6ab864f51d4fa6e20f5de4fd56d8126d55dea8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42636
Changelog: [Internal]
Models the Native instance lifecycle in the modern CDP backend, by:
1. Registering the instance, once created, with `PageTarget`.
2. While an instance is registered, delegating messages from `PageAgent` to an internal `InstanceAgent`.
3. Unregistering the instance once it is invalidated and about to be destroyed.
We use this infrastructure to implement two simple behaviours that will be superseded in future diffs (mainly by delegating work to the JSVM), but that are useful as stubs for testing:
* Sending [`Runtime.executionContextDestroyed`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextDestroyed), [`Runtime.executionContextsCleared`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextsCleared), and [`Runtime.executionContextCreated`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextCreated) events to the frontend when reloading the instance.
* Implementing a toy version of [`Runtime.getHeapUsage`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#method-getHeapUsage) (that always reports zero memory usage) to exercise the Page→Instance message dispatching logic.
iOS Bridge/Bridgeless and `PageTargetTest` are the only integrations that exist as of this diff, and are all updated here; Android will follow later.
## Object lifetimes
* PageTarget owns an InstanceTarget that it creates (in `registerInstance`) and destroys (in `unregisterInstance`).
* `registerInstance` returns a raw `InstanceTarget&` reference, which becomes invalid upon calling `unregisterInstance`. It's the caller's responsibility to stop using the reference at the point of calling `unregisterInstance`.
* InstanceTarget holds a raw `InstanceTargetDelegate&` reference. It's the caller's responsibility to keep this reference valid at least until `unregisterInstance` returns.
## Thread safety
* As with PageTarget's constructor and destructor, It's the caller's responsibility to invoke `registerInstance` and `unregisterInstance` on the main thread (or using appropriate synchronisation).
* `InstanceAgent` handles messages on the same thread as `PageAgent` (typically the platform-specific main thread) and receives a copy of the same thread-safe `FrontendChannel` for sending messages back.
Reviewed By: huntie
Differential Revision: D51214056
fbshipit-source-id: 2dc2ff30d2dda6887871831a818aa117ca3e6e91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42678
Changelog: [internal]
This is a re-application of https://github.com/facebook/react-native/pull/42430, which had to be reverted because of crashes in optimized builds on Android:
```
Abort Reason: terminating due to uncaught exception of type facebook::jni::JniException: java.lang.ClassNotFoundException: com.facebook.react.internal.featureflags.ReactNativeFeatureFlagsProvider
```
The root cause of that was that that class was removed because it wasn't statically referenced from Kotlin/Java, but it was dynamically referenced from C++ (in `ReactNativeFeatureFlagsProviderHolder.cpp`).
This applies the same changes + adds `DoNotStrip` annotations for the affected class and all its methods.
Reviewed By: huntie
Differential Revision: D53122992
fbshipit-source-id: efc4d5636a3f2d39b86e9c098bff408b6688b80b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42430
This PR creates a new internal feature flags system for React Native. This is only meant to be used internally within the framework, but we might expose it externally in some form in the future to allow customizing specific feature flags in frameworks and applications.
Features:
* 2 types of flags:
* Common: can be overridden from native and are accessible from all layers of the stack (Objective-C/Swift, Java/Kotlin, C++ and JavaScript).
* JS-only: flags that can only be defined and accessed from JS (to allow things like hot reloading without a native build).
* 1 source of truth for each flag.
* Feature flags are application/process scoped (using C++ singletons).
See the `README.md` file in this PR for additional information.
This also adds modifies `run-ci-javascript-tests` to run a new check to make sure that the generate files are in sync with the JSON file that contains the definitions.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52806730
fbshipit-source-id: 0ba95803f61ec2f05266ee535921321bf6d3dc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42394
Changelog: [Internal][iOS] - Enable stub modern CDP backend in Bridge behind a feature flag
Minimally integrates the stub native CDP backend implementation (D50936932) into iOS Bridge.
This integration registers itself as a "Modern" target (D50967794, D50967795) to instruct `inspector-proxy` to disable its CDP hacks related to source map fetching, reloads, etc. This gives us a mostly-clean slate on which to develop and test native CDP functionality.
Reviewed By: huntie
Differential Revision: D50951138
fbshipit-source-id: 8c5ad9207e73265595884380c91e38f8d0ead84d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42037
Creates an Objective-C wrapper around the C++ version of `InspectorPackagerConnection` (introduced in D52134592), and uses it in React Native iOS apps (behind an internal flag that is off by default).
In future work, the flag will be turned on by default, then deleted, and eventually the legacy `RCTInspectorPackagerConnection` code will be deleted from React Native.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D52225495
fbshipit-source-id: f1b9657ef0d665cf7892c15c34c5104e2777ec43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42153
This non functional change unifies Folly version and compiler flag in a single function, so that it would be easier to update it in the future.
## Changelog:
[Internal] - Unify folly version and compiler flags
Reviewed By: cortinico
Differential Revision: D52564771
fbshipit-source-id: 9b4b50560ddee05ce50465b6854666572148cb25
Summary:
Bump folly version to 2024.01.01.00. Actually we need a version newer than v2023.08.14.00 with the https://github.com/facebook/folly/commit/c52d4490bf1e0cf117a71342b427984f9ffc316e fix. That will fix build error on Android:
```
In file included from /Users/kudo/expo/expo/node_modules/react-native-reanimated/android/src/main/cpp/NativeProxy.cpp:3:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/jsi/include/jsi/JSIDynamic.h:10:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic.h:1310:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic-inl.h:22:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Conv.h:124:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Demangle.h:19:
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1721:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::equal;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1723:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::less;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1725:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::greater;
~~~~~^
3 errors generated.
```
## Changelog:
[GENERAL] [CHANGED] - Bump folly version to 2024.01.01.00
Pull Request resolved: https://github.com/facebook/react-native/pull/42145
Test Plan: ci passed
Reviewed By: cortinico, cipolleschi
Differential Revision: D52546945
Pulled By: NickGerleman
fbshipit-source-id: 64aacb1d310062dddf987c7b95f10a477e293693
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41625
To tell React Native whether we are building with hermes or not on iOS, we were using 2 different build time flags:
- USE_HERMES
- RCT_USE_HERMES
The first was widely used by the OSS use case, while the latter was set internally.
Worse than that, their default values were the opposite and we were never setting the RCT_USE_HERMES explicitly with Cocoapods, while there was some piece of code that was trying to "smartly" detect whether Hermes was included or not.
This change unifies the behavior, removing the "smartness" in favor od a declarative approach.
## Changelog:
[Internal] - Unify the USE_HERMES flags
Reviewed By: christophpurrer
Differential Revision: D51549284
fbshipit-source-id: 829ad361e185d5b4fa227605523af3a8e590e95c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41416
Changelog: [Internal]
cocoapods boilerplate to integrate the first RCTFoundation library. decided to split this up so we can reference it easily in the future when adding new libs
Reviewed By: cipolleschi
Differential Revision: D51184321
fbshipit-source-id: 28696f0a8e43e0bcd24a37956823fb544ecd84be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41356
React-Core does not depends on any bit of ReactCommon, React-RCTFabric or React-NativeModuleApple, so I'm cleaning that up.
## 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: D51030115
fbshipit-source-id: f87dbfe99e90d52cf8c07057be22cd024e38db42
Summary:
We've been using SocketRocket 0.7.0 (to pick up a few bug fixes) without issue in React Native macOS. Might as well bump it upstream before 0.73 if we can.
## Changelog:
[IOS] [CHANGED] - Update SocketRocket to 0.7.0
Pull Request resolved: https://github.com/facebook/react-native/pull/39571
Test Plan: CI should pass
Reviewed By: cortinico
Differential Revision: D50411361
Pulled By: cipolleschi
fbshipit-source-id: 93ab571dcfd23e699f1c066bf7aaf737e1f2d18b
Summary:
The SocketRocket version was upgraded to 0.6.1 on the 0.72-stable branch but for some reason it was not updated in main, causing a downgrade when running `pod install` with 0.73.0 RC1
Original commit bumping SocketRocket -> https://github.com/facebook/react-native/commit/8ce471e2fa802cc50ff2d6ab346627cb5f6d79b4
## Changelog:
[IOS] [CHANGED] - Bump SocketRocket to 0.6.1
Pull Request resolved: https://github.com/facebook/react-native/pull/40774
Test Plan: Run rntester locally
Reviewed By: cipolleschi
Differential Revision: D50137261
Pulled By: arushikesarwani94
fbshipit-source-id: dfc2760f5d5611881126ad114d8f6ada23630a29
Summary:
This bumps folly, to absorb https://github.com/facebook/folly/commit/45fffa629d6bf7321391222d40613d75e8e067d7 which fixes warnings in XCode 15, and NDK 26 (treated as error bc we have better hygiene there). We then bump a little bit further to get past a new warning added, then fixed later.
Need to manually set `FOLLY_HAVE_GETTIME` on Apple because of the silliness described in https://github.com/facebook/folly/issues/1470#issuecomment-1746035194
There is not a combination of Folly, and Android libc++, that has fixes for warnings, but doesn't require the new libc++ in NDK 26. It is expected then that this commit will fail the build, but the next should succeed, and the two must be landed at the same time.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/39798
Reviewed By: fkgozali
Differential Revision: D49897681
Pulled By: NickGerleman
fbshipit-source-id: 52b97ed5b302abf9e27f38dc655207827852dcc3
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:
## Summary:
One of the most common diffs we have in React Native macOS is simply extending the `platforms` key Inside every pod spec to include macOS. React Native tvOS does the same to add tvOS. In the future, React Native may support visionOS, at which point we do the same thing again. Let's define a `min_supported_versions` hash that can be overridden at one place that is extensible to more platforms, instead of just specifying `min_ios_version_supported`.
Note: In doing this change, I have set it that `React-Hermes.podspec` doesn't build for macOS anymore. I think this is safe, since anyone using Hermes on macOS was probably using React Native macOS where we already have a diff to add macOS back?
## Changelog:
[IOS] [CHANGED] - Add min_supported_versions helper to cocoa pods scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/39310
Test Plan: CI should pass.
Reviewed By: NickGerleman
Differential Revision: D49014109
Pulled By: dmytrorykun
fbshipit-source-id: d44fc7b750c70cc263a2c89502c022a0db9a4771
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39262
The use_hermes condition in React core was imprecise as using hermes is the default now. So, if USE_HERMES is not defined, then we are using hermes.
## Changelog:
[iOS][Fixed] - Use the right condition in React-Core for USE_HERMES.
Reviewed By: dmytrorykun
Differential Revision: D48907854
fbshipit-source-id: daeaa1782f23e0ab3992240e70f49ff0b2fd75de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37659
changelog: [internal]
To better align with how BUCK is setup internally, let's make React utils its own pod.
Reviewed By: dmytrorykun
Differential Revision: D46358021
fbshipit-source-id: c2a48a18e9839a508a87d54685115883975f3979
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37678
## Stack
React Native on iOS adds strings to Voiceover interactions to supply more information to users . Internally, and out-of-the-box externally, these are today always announced in English instead of being localized.
This stack adds a limited new internal API, `RCTLocalizedString(string, description)` to allow auto-translated strings which are consumed by both Meta and OSS.
Reviewed By: cipolleschi
Differential Revision: D46414630
fbshipit-source-id: 1137182dbbd89d959b3d143ce534229968bdb8f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36795
This change bump the min iOS version for React Native to 13.4, to align with company guidelines.
## Changelog:
[iOS][Changed] - Moved the min iOS version to 13.4
Reviewed By: cortinico
Differential Revision: D44634663
fbshipit-source-id: 035e8fcbb395f7394f8253e3ec485ad9937531c2
Oskar Kwaśniewski
Kudo Chien
Saad Najmi
Alan Lee
Riccardo Cipolleschi
Phillip Pan
Moti Zilberman
Rubén Norte
David Vacca
Gabriel Donadel
Nick Gerleman
Nick Gerleman
Saad Najmi
Lulu Wu
Samuel Susla
Samuel Susla
Ruslan Lesiutin