Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53026
This change prevents users from opting out of the New Architecure.
The change is non breaking with respect to building an app: all the functions are still there, even if they are unreachable, in case users will still call them explicitly.
We hardcoded all the values to enable the New Architecture, so there is no way to disable it.
This is a behavioral breaking change, though.
## Changelog:
[iOS][Removed] - Removed the opt-out from the New Architecture.
Reviewed By: cortinico
Differential Revision: D79090048
fbshipit-source-id: 9779bfedf50748d7adbef5f7ef038f469e30efc2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52442
Changelog: [Internal]
The sample is from an outdated approach of enabling C++ Modules in RN which is not recommended anymore.
Prefer C++ Turbo Modules if you need to expose / access C or C++ APIs in RN apps:
https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules
It is not included in any RNTester app at this time
Reviewed By: cortinico
Differential Revision: D77771111
fbshipit-source-id: a4fe1d13fd0224babc46f54b921a036f7b237a48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50170
This is needed in D71470038 and later, where submodules of `jsinspector-modern` need to operate with CDP message payloads. We functionally split out these files as a library to avaoid a dependency cycle.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D71551561
fbshipit-source-id: 527479399d7563883c1b6599f884b7857e79bd77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49931
This change fixes the app startup in the Old Architecture by implementing the loadSourceForBridge:onProgress:onComplete method in the RCTDefaultReactNativeFactoryDelegate object.
The method was missing here, so the Bridge was never trying to load the JS bundle from Metro, resulting in an empty app.
## Changelog:
[iOS][Fixed] - Implement the loadSourceForBridge:onProgress:onComplete in the RCTDefaultReactNativeFactoryDelegate.
Reviewed By: cortinico
Differential Revision: D70898811
fbshipit-source-id: 3e5d519a1965e92ace91ca6d5b316a9069279448
Summary:
After this change: https://github.com/facebook/react-native/pull/49078 UIWindowSceneDelegate is no longer needed.
This wasn't removed in the original PR.
## Changelog:
[iOS] [Removed] - Remove no longer needed UISceneDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/49628
Test Plan: CI GREEN
Reviewed By: cortinico
Differential Revision: D70102384
Pulled By: cipolleschi
fbshipit-source-id: e33185a4becd949a9f0ec1eabeeb4fe85ef3ee79
Summary:
Recently, I've introduced `RCTReactNativeFactory` in this PR: https://github.com/facebook/react-native/issues/46298, which is a good successor for `RCTAppDelegate`.
### Why?
`RCTAppDelegate` introduced strong coupling between React Native and AppDelegate pattern. From iOS 13+ there is a newer equivalent (Scene Delegate) which is not possible to achieve with current architecture. The proposed solution involves migration to a `RCTReactNativeFactory` a class that encapsulates initialization logic of React Native.
This migration will make brownfield initialization easier by making it more flexible and simpler to integrate into already established apps.
### Deprecation plan
The plan I've discussed with cipolleschi involves:
- Deprecation of `RCTAppDelegate` in 0.79 (current main)
- Migration off `RCTAppDelegate` to SceneDelegate + `RCTReactNativeFactory` in 0.80
## Changelog:
[IOS] [DEPRECATED] - deprecate RCTAppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/49078
Test Plan: Not needed
Reviewed By: cortinico
Differential Revision: D69061022
Pulled By: cipolleschi
fbshipit-source-id: b02a0ff3f26be9320da749f38c9cf083804f9f30
Summary:
This PR implements ReactNativeFactory to encapsulate further the logic of creating an instance of React Native for iOS.
This will remove the strong coupling on the RCTAppDelegate and allow us to support Scene Delegate in the future.
The goal is to have a following API:
```objc
self.reactNativeFactory = [[RCTReactNativeFactory alloc] initWithDelegate:self];
UIView *rootView = [self.reactNativeFactory.rootViewFactory viewWithModuleName:self.moduleName
initialProperties:self.initialProps
launchOptions:launchOptions];
// Standard iOS stuff here
```
## Changelog:
[IOS] [ADDED] - implement ReactNativeFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/46298
Test Plan: Test out all the methods of AppDelegate
Reviewed By: huntie
Differential Revision: D67451403
Pulled By: cipolleschi
fbshipit-source-id: 9e73cd996ffc27ca1e3e058b45fc899b1637bdba
Summary:
https://github.com/facebook/react-native/issues/48376 removed `applicationDidEnterBackground` from `RCTAppDelegate` but RNTester called it, leads to crash. cc cipolleschi can you please help to review?
## Changelog:
[INTERNAL] [FIXED] - RNTester: Fixes crash when app back to background
Pull Request resolved: https://github.com/facebook/react-native/pull/48385
Test Plan: RNTester iOS back to background not crash.
Reviewed By: cipolleschi
Differential Revision: D67657449
Pulled By: philIip
fbshipit-source-id: e6d806b2677050fa2faa273a7468055d9d21c2a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47761
When breaking the last dependency, we created the `RCTApDependencyProvider` in the Codegen pod.
This is not an issue per sè. The problem comes in with the new template in Swift: ReactCodegen contains some headers with some C++ code that Swift can't really process.
That's why most libraries started failing in jobs like [this one](https://github.com/facebook/react-native/actions/runs/11906196751/job/33177904733): the template app was not able to load the `ReactCodegen` pod in the Swift app delegate.
Given that the app delegate only have to actually load the RCTAppDependencyProvider, I extracted that class in its own pod: ReactAppDependencyProvider.
The name of the pod does not follow the React-RCTXXX structure because that will create issues with the import statements and the `use_frameworks!` use case.
> [!NOTE]
> We need to update the template and change the `import ReactCodegen` to `import ReactAppDependencyProvider`
## Changelog:
[iOS][Added] - Extract RCTAppDependencyProvider in the ReactAppDependencyProvider pod
Reviewed By: blakef
Differential Revision: D66241941
fbshipit-source-id: 6b888109c65d9560fff322ec84a16da78fbcd64b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47651
## This Change:
This change uses in the App's AppDelegate the newly generated `RCTAppDependencyProvider`, passing it to the `RCTAppDelegate`.
This change needs to be applied also to the template, when this stack lands.
## Context
React Native has a last temporal dependency on Codegen in the React-RCTAppDelegate pod.
The RCTAppDelegate has the responsibility to provide various dependencies to react native, like third party components and various modules. ReactCodegen is generated when the user create the project, while React-RCTAppDelegate eists in React Native itself.
This dependency means that we cannot prepare prebuilt for iOS for React Native because when we would have to create prebuilds, we would need the React Codegen, but we can't create a React codegen package that will fit all the apps, because React Codegen can contains App Specific modules and components and apps might have different dependencies.
## Changelog:
[iOS][Added] - Pass the `RCTAppDependencyProvider` to the `RCTAppDelegate`
Reviewed By: dmytrorykun
Differential Revision: D66074475
fbshipit-source-id: 93bf500fe37f115352ebd49d3d56955cbaeeea72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47518
This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns.
1. We are generating it in the user space, not in the node_modules (fixes the circular dependency)
2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation
The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation.
The assumption is that components have a function in their `.mm` file with this shape:
```objc
Class<RCTComponentViewProtocol> <componentName>Cls(void)
{
return <ComponentViewClass>.class;
}
```
I verified on GH that all the libraries out there follow this pattern.
A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`.
We will implement that as the next step and we will support both for some versions for backward compatibility.
## Changelog
[iOS][Changed] - Change how components automatically register
Reviewed By: dmytrorykun
Differential Revision: D65614347
fbshipit-source-id: a378b8bc31c1ab3d49552f2f6a4c86c3b578746b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44895
Enables the new debugger stack (codename Fusebox) in RNTester.
This feature is experimental and is enabled for testing purposes only. This change **should not** be adopted as the default by React Native frameworks.
Changelog: [Internal]
Reviewed By: cortinico, rubennorte, NickGerleman
Differential Revision: D58366246
fbshipit-source-id: 809a1edb79ced4a7920457ed661cc3d863b35c7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44860
- Enables an opt-in to the Fusebox stack on iOS for both architectures in open source.
- Templates use of this opt-in in RNTester.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D58364053
fbshipit-source-id: c604b1589174bf7cfd0fe1bfb5624c4edd0a125d
Summary:
On React Native macOS (I am not sure with the current state of React Native), the Xcode Unit and Integration tests are a bit flaky. Rather than set "retry on failure up to 3 times" through the pipeline config (in our case, Azure Pipelines), I realized my earlier PR to use Xcode test plans (https://github.com/facebook/react-native/pull/36443) means we can have Xcode retry the test. This should be faster than retrying it on the pipeline, because it retries just the failing test, not the entire "test" step. I did this on React Native macOS, so I'm doing it upstream so we can remove a diff.
## Changelog:
[INTERNAL] [CHANGED] - Set `retryOnFailure` for Xcode Unit and Integration tests
Pull Request resolved: https://github.com/facebook/react-native/pull/44642
Test Plan: CI should pass (faster)
Reviewed By: cortinico
Differential Revision: D57662523
Pulled By: cipolleschi
fbshipit-source-id: 8de2ab0ea15ba4d38c3b5bf96108c0c7ff5e9f32
Summary:
This PR implements `RCTRootViewFactory` a utility class (suggested by cipolleschi) that returns proper RCTRootView based on the current environment state (new arch/old arch/bridgeless). This class aims to preserve background compatibility by implementing a configuration class forwarding necessary class to RCTAppDelegate.
### Brownfield use case
This PR leverages the `RCTRootViewFactory` in `RCTAppDelegate` for the default initialization of React Native (greenfield).
Here is an example of creating a Brownfield integration (without RCTAppDelegate) using this class (can be later added to docs):
1. Store reference to `rootViewFactory` and to `UIWindow`
`AppDelegate.h`:
```objc
interface AppDelegate : UIResponder <UIApplicationDelegate>
property(nonatomic, strong) UIWindow* window;
property(nonatomic, strong) RCTRootViewFactory* rootViewFactory;
end
```
2. Create an initial configuration using `RCTRootViewFactoryConfiguration` and initialize `RCTRootViewFactory` using it. Then you can use the factory to create a new `RCTRootView` without worrying about old arch/new arch/bridgeless.
`AppDelegate.mm`
```objc
implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary<UIApplicationLaunchOptionsKey,id> *)launchOptions {
// Create configuration
RCTRootViewFactoryConfiguration *configuration = [[RCTRootViewFactoryConfiguration alloc] initWithBundleURL:self.bundleURL
newArchEnabled:self.fabricEnabled
turboModuleEnabled:self.turboModuleEnabled
bridgelessEnabled:self.bridgelessEnabled];
// Initialize RCTRootViewFactory
self.rootViewFactory = [[RCTRootViewFactory alloc] initWithConfiguration:configuration];
// Create main root view
UIView *rootView = [self.rootViewFactory viewWithModuleName:@"RNTesterApp" initialProperties:@{} launchOptions:launchOptions];
// Set main window as you prefer for your Brownfield integration.
self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
UIViewController *rootViewController = [UIViewController new];
rootViewController.view = rootView;
self.window.rootViewController = rootViewController;
[self.window makeKeyAndVisible];
// Later in the codebase you can initialize more rootView's using rootViewFactory.
return YES;
}
end
```
bypass-github-export-checks
## Changelog:
[INTERNAL] [ADDED] - Implement RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/42263
Test Plan: Check if root view is properly created on app initialization
Reviewed By: dmytrorykun
Differential Revision: D53179625
Pulled By: cipolleschi
fbshipit-source-id: 9bc850965ba30d84ad3e67d91dd888f0547c2136
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43159
Changelog: [internal]
This modifies the default `RCTAppDelegate` for iOS apps in OSS to provide an implementation for the C++ native module for feature flags.
In a following diff I'll replace the `React-featureflagsnativemodule.podspec` file with one that includes all built-in C++ native modules.
Reviewed By: RSNara
Differential Revision: D54082349
fbshipit-source-id: 8c4ed7499c6fd35916ba105edcae0e2c85961e1c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42687
Changelog: [Internal]
adding an example for if you want to use `getInitialNotification`.
Reviewed By: ingridwang
Differential Revision: D52931618
fbshipit-source-id: 7552c358e5bc98228b7ae74ea1adf450f7b075e6
Summary:
For Bridgeless mode we set `fabric` and `concurrentRoot` property for newly initialized views. This example overwrites those properties. I think we should Instead copy previous dictionary and only overwrite `color` key.
This issue results in a warning: "Using Fabric without concurrent root is deprecated. Please enable concurrent root for this application."
Note: This Example crashes on Bridgeless but my other PR https://github.com/facebook/react-native/issues/42263 fixes it.
## Changelog:
[INTERNAL] [FIXED] - UpdatePropertiesExampleView to mutate existing `appProperties` instead of overwriting
Pull Request resolved: https://github.com/facebook/react-native/pull/42634
Test Plan:
1. Wait for this example to get fixed for Bridgeless
2. Click the button to update props
3. Check if there is no warning
Reviewed By: cortinico
Differential Revision: D53126953
Pulled By: cipolleschi
fbshipit-source-id: fa0e8bda50a47696467d279845616c2ba51fe310
Summary:
There seems to be a lot of `TARGET_OS_UIKITFORMAC` macro in React Native that don't need to be there. Let's remove them.
First off, what is `TARGET_OS_UIKITFORMAC` targeting? You might think it's [Mac Catalyst](https://developer.apple.com/mac-catalyst/), if you look at the [commit](https://github.com/facebook/react-native/commit/3724810d2168eb182db24acf9e741775df27ae13) introducing the ifdefs. However.. that doesn't seem right because `TARGET_OS_MACCATALYST` exists, and is used elsewhere in the codebase. In fact, if you look at this handy comment inside `TargetConditionals.h` (the file that defines all these conditionals), `TARGET_OS_UIKITFORMAC` is not even on there!
```
/*
* TARGET_OS_*
*
* These conditionals specify in which Operating System the generated code will
* run. Indention is used to show which conditionals are evolutionary subclasses.
*
* The MAC/WIN32/UNIX conditionals are mutually exclusive.
* The IOS/TV/WATCH/VISION conditionals are mutually exclusive.
*
* TARGET_OS_WIN32 - Generated code will run on WIN32 API
* TARGET_OS_WINDOWS - Generated code will run on Windows
* TARGET_OS_UNIX - Generated code will run on some Unix (not macOS)
* TARGET_OS_LINUX - Generated code will run on Linux
* TARGET_OS_MAC - Generated code will run on a variant of macOS
* TARGET_OS_OSX - Generated code will run on macOS
* TARGET_OS_IPHONE - Generated code will run on a variant of iOS (firmware, devices, simulator)
* TARGET_OS_IOS - Generated code will run on iOS
* TARGET_OS_MACCATALYST - Generated code will run on macOS
* TARGET_OS_TV - Generated code will run on tvOS
* TARGET_OS_WATCH - Generated code will run on watchOS
* TARGET_OS_VISION - Generated code will run on visionOS
* TARGET_OS_BRIDGE - Generated code will run on bridge devices
* TARGET_OS_SIMULATOR - Generated code will run on an iOS, tvOS, watchOS, or visionOS simulator
* TARGET_OS_DRIVERKIT - Generated code will run on macOS, iOS, tvOS, watchOS, or visionOS
*
* TARGET_OS_EMBEDDED - DEPRECATED: Use TARGET_OS_IPHONE and/or TARGET_OS_SIMULATOR instead
* TARGET_IPHONE_SIMULATOR - DEPRECATED: Same as TARGET_OS_SIMULATOR
* TARGET_OS_NANO - DEPRECATED: Same as TARGET_OS_WATCH
*
* +--------------------------------------------------------------------------------------+
* | TARGET_OS_MAC |
* | +-----+ +------------------------------------------------------------+ +-----------+ |
* | | | | TARGET_OS_IPHONE | | | |
* | | | | +-----------------+ +----+ +-------+ +--------+ +--------+ | | | |
* | | | | | IOS | | | | | | | | | | | | |
* | | OSX | | | +-------------+ | | TV | | WATCH | | BRIDGE | | VISION | | | DRIVERKIT | |
* | | | | | | MACCATALYST | | | | | | | | | | | | | |
* | | | | | +-------------+ | | | | | | | | | | | | |
* | | | | +-----------------+ +----+ +-------+ +--------+ +--------+ | | | |
* | +-----+ +------------------------------------------------------------+ +-----------+ |
* +--------------------------------------------------------------------------------------+
*/
```
Going even deeper into `TargetConditionals.h`, you will see `TARGET_OS_UIKITFORMAC` defined... and it's always 1 when `TARGET_OS_MACCATALYST` is 1, making it feel even more redundant. My current conclusion is it's either another variant of Mac Catalyst (the one where they just run unmodified UIKit maybe..), or it's an older macro back from when Catalyst was still experimental.
Either way, it's pretty obvious nobody is running or testing this codepath, and it adds bloat, especially to React Native macOS where we have extra ifdef blocks for macOS support (and eventually visionOS support). Let's remove it.
Another change I made while we're here:
I've seen this lingering TODO to replace setTargetRect:InView: / setMenuVisible:animated: (deprecated as of iOS 13, below our minimum OS requirement) with showMenuFromView (deprecated as of iOS 16, in line with the availability check). Let's just.... do that?
## Changelog:
[IOS] [REMOVED] - Remove TARGET_OS_UIKITFORMAC macros
Pull Request resolved: https://github.com/facebook/react-native/pull/42278
Test Plan:
RNTester with Mac Catalyst still compiles:
Reviewed By: cipolleschi
Differential Revision: D52780690
Pulled By: sammy-SC
fbshipit-source-id: df6a333e8e15f79de0ce6f538ebd73b92698dcb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42073
This moved various Meta-internal runtime setup off AppDelegate.mm to reduce the #if checks throughout the file.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52424748
fbshipit-source-id: b53799c8bb1544dbbb429cea811861ae52125641
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42071
Proxying background handling to set up Meta internal test infra.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D52420805
fbshipit-source-id: a68645b7b630f976dfd9e863b0c985c738c658ec
Summary:
Apple will require XCode 15 next year to ship to the app store, and it aligns with how we build and test React Native internally.
XCode 15 and 14.3 add support for a lot of [missing C++ 20 features](https://developer.apple.com/xcode/cpp/#c++20) from earlier versions as well.
Last I was aware, Riccardo was onboard with bumping min supported in 0.74 to XCode 15. This change does a slightly more conservative bump to min 14.3, and main of 15.0 (though we might want to move these before 0.74 comes out).
All of this will get migrated over to GHA soon enough as well, but... formalizing this is the only thing blocking usage of C++ 20 ranges today.
Changelog:
[ios][breaking] - Require XCode >= 14.3
Pull Request resolved: https://github.com/facebook/react-native/pull/41798
Test Plan:
1. CircleCI Passes
2. Can still boot RNTester from XCode with code signing related changes.
Reviewed By: cortinico
Differential Revision: D51840617
Pulled By: NickGerleman
fbshipit-source-id: 58f8951a436eb7c892a00432a8aad0ddd0a49da1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41589
This is a cleanup diffs that removes some of the usages of RCT_NEW_ARCH_ENABLED.
Now that we are shipping all the pods, there is no need to conditionally compile-out part of the codebase depending on whether the new architecture is running or not.
This change will not alter the behavior of the app.
## Changelog:
[iOS][Breaking] - Remove some usages of RCT_NEW_ARCH_ENABLED. The change should be transparent BUT some **Swift** libraries might get broken by this change.
Reviewed By: dmytrorykun
Differential Revision: D51498730
fbshipit-source-id: c83416480eea1f7bbc55f72c31e7b69ad0e9e01a
Summary:
When reverting the runtimescheduler fix, we forgot to remove some lines from the React-Fabric dependencies. This broke pod install and we have a red ci since then.
bypass-github-export-checks
## Changelog:
[iOS][Fixed] - fix React-Fabric dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/37652
Test Plan: CircleCI is green
Reviewed By: cipolleschi
Differential Revision: D46349504
Pulled By: sammy-SC
fbshipit-source-id: 8fc1bca7838a913adba702033d06dd02b93c31f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37572
Currently, RNTester was using a completely custom AppDelegate and not leveraging the RCTAppDelegate we use in the OSS. This resulted in a misalignment between the two setups and duplicated work to test stuff internally furst and then in the OSS, with some more time needed to understand why one setup was working and the other wasn't.
With this change, we are aligning the two, bringing RNTester closer to the OSS setup. There are still small differences, but we can iterate over those.
## Changelog:
[iOS][Changed] - Make RNTester use RCTAppDelegate
Reviewed By: cortinico
Differential Revision: D46182888
fbshipit-source-id: 7c55b06de1a317b1f2d4ad0d18a390dc4d3356a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37571
During the RC.0 of 0.72, we disabled the iOS integration tests because they were not working with Metro and the new Monorepo setup.
This change tries to re-enable them so we can be more protected in CI
## Changelog:
[internal] - Re-enable integration tests
Reviewed By: cortinico
Differential Revision: D46178840
fbshipit-source-id: a5239fa7067b8fb68d997dd0cc63b67fb54d2d7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37273
When using dynamic frameworks, we can't rely on Codegen to register all the components into the renderer. That's because, we would have to codegen a new target, which depends on ALL the 3rd party dependencies that expose a UI component.
The previous PR adds support for distributed automatic registration when components are loaded in memory.
However, not to slow down the adoption of the New Architecture, there could be apps that need to register a component that does not support the distributed approach yet. Thanks to this method, apps can register those components.
## Changelog:
[iOS][Added] - Added a mechanism to register components into the renderer from the user app.
Reviewed By: dmytrorykun
Differential Revision: D45605688
fbshipit-source-id: 3583913f2700be4d6cb33a862429486aca675acf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37104
The AppDelegate (and other similar classes) only need to construct the TurboModuleManager for intialization purposes, and should not retain it beyond that. TurboModuleManager retains each of the TurboModule instances and through the new binding mechanism, also JSI pointers, which are invalid beyond the lifetime of the JS context.
Changelog: [iOS] Changed AppDelegate template to avoid retaining TurboModuleManager.
Reviewed By: sammy-SC, cipolleschi
Differential Revision: D45310066
fbshipit-source-id: 4199c9973d832cc07fd32b94f2dcbaa72f4d3920
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36686
After the recent changes of Metro and Metro-Config, we need to update the path used to load the bundle in RNTester
## Changelog:
[General][Fixed] - Use the right path to load RNTester bundle
Reviewed By: cortinico
Differential Revision: D44465418
fbshipit-source-id: 96170194579792f9a5d8a141328d43e45a4db973
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36648
Changelog: [Internal]
Blocker for https://github.com/facebook/react-native/pull/36623. The `test-ios` job in CI was misconfigured following the monorepo migration — and this becomes load-bearing with the incoming version of React Native CLI.
- Update `objc-test.sh` to run in `packages/rn-tester`, and exclude tests under `/IntegrationTests` which are outside of a Metro project directory.
- **This is temporary** — a task has been created to move/split up/otherwise restore tests in `IntegrationTests`, which cipolleschi is following up (thanks!).
- Also fix `yarn start` script in `packages/rn-tester`.
Reviewed By: cipolleschi
Differential Revision: D44416533
fbshipit-source-id: 59c5b743d9d8fda206a12e37d94324ed9bfd703e
Riccardo Cipolleschi
Christoph Purrer
David Richey
Alex Hunt
Oskar Kwaśniewski
zhongwuzw
Saad Najmi
Rubén Norte
Phillip Pan
Ingrid Wang
Kevin Gozali
Nick Gerleman
Pieter De Baets
Kudo Chien
Lulu Wu
Riccardo Cipolleschi
Samuel Susla
Samuel Susla
Alex Hunt