[core][ios] Remove legacy view managers (#21760)

[core] Fix ios event listeners broken on remote debugging mode (#19211)

# Why

fix #19077

# How

the [RCTObjcExecutor generates the `__fbBatchedBridgeConfig` in very early stage](https://gith

[core] Fix ios event listeners broken on remote debugging mode (#19211)

# Why

fix #19077

# How

the [RCTObjcExecutor generates the `__fbBatchedBridgeConfig` in very early stage](https://github.com/facebook/react-native/blob/22940e4177c7244ac35a1903bb869a619336eaa5/React/CxxBridge/RCTObjcExecutor.mm#L35-L68). it is even earlier than [we registering `EXReactNativeEventEmitter` to bridge](https://github.com/expo/expo/blob/7ced82458b9d26e9543f18c29fae89d1ff43a827/packages/expo-modules-core/ios/NativeModulesProxy/EXNativeModulesProxy.mm#L359-L365). that would cause `EXReactNativeEventEmitter` not appearing in NativeModules.

the pr tries to register `EXReactNativeEventEmitter` in formal `RCT_EXPORT_MODULE` way and makes it available before `RCTObjcExecutor` creation.

# Test Plan

- ✅ bare-expo hermes + NCL clipboard listener (sweet module)
- ✅ bare-expo hermes + NCL screen capture listener (legacy module)
- ✅ bare-expo remote debugging + NCL clipboard listener (sweet module)
- ✅ bare-expo remote debugging + NCL screen capture listener (legacy module)
- ✅ expo go jsc + NCL clipboard listener (sweet module)
- ✅ expo go jsc + NCL screen capture listener (legacy module)
- ✅ expo go remote debugging + NCL clipboard listener (sweet module)
- ✅ expo go remote debugging + NCL screen capture listener (legacy module)

show more ...

[ios] Fix view recycling in Fabric (#19083)

[ios] Experimental Expo modules support for Fabric (#18500)

Co-authored-by: Kudo Chien <[email protected]>

[tools][ios] Remove version prefix from the view manager name (#18277)

[core][ios] Patch legacy modules unavailable in `onCreate` (#18160)

Co-authored-by: Tomasz Sapeta <[email protected]>

[e-m-c][ios] Expose `NativeModulesProxy` config as a JSI module (#17741)

- Created the `NativeProxyModule` - a Sweet expo-module which is a counterpart of the `NativeUnimoduleProxy` RN module (`EXNa

[e-m-c][ios] Expose `NativeModulesProxy` config as a JSI module (#17741)

- Created the `NativeProxyModule` - a Sweet expo-module which is a counterpart of the `NativeUnimoduleProxy` RN module (`EXNativeModulesProxy`)
- it is registered manually in `ExpoBridgeModule`, right after the creation of `AppContext`
- currently, it only exports constants - the same as the `EXNativeModulesProxy` module
- the constants creation logic is still written in Objective-C inside `EXNativeModulesProxy`. It will finally be migrated in the future, but there's no reason to move it in this PR.
- Refactored config creation in `EXNativeModulesProxy constantsToExport`
- created the `EXModulesProxyConfig` class - a store for the module proxy config + some convenience methods for dictionary management
- config for both legacy modules and new sweet expo-modules is now lazy-loaded and cached
- minimized Swift calls from Objective-C, as they were performance bottlenecks - now there is only one such call.
- Yet, both configs are loaded in `NativeModulesProxy.native.ts` - config constants are taken from the JSI module first (with fallback to legacy constants), but method calls are still handled by the legacy proxy module.
- We need to load both (or at least the legacy one) anyway, but this shouldn't be a big issue for now, because the config is created only once and cached.

show more ...

[ios][core] align the expo modules registration (#17563)

# Why

expo go still uses the legacy native modules registration (`EXModuleRegistryAdapter` in `extraModulesForBridge:`). this flow is diff

[ios][core] align the expo modules registration (#17563)

# Why

expo go still uses the legacy native modules registration (`EXModuleRegistryAdapter` in `extraModulesForBridge:`). this flow is different from a bare project.

react-native 0.69 has a different native modules setup flow that would breaks expo go's setup.
`- (void)setModuleRegistry:(EXModuleRegistry *)expoModuleRegistry` in EXAV.m would be called with RCTModuleRegistry but not EXModuleRegistry.

# How

add a `initWithCustomModuleRegistry:` in EXNativeModulesProxy designated initializer for expo go to pass its EXModuleRegistry. specifically, we need to use [the shared call flow](https://github.com/expo/expo/blob/19db64c8db1d6dd4c062426cd4fbe87eaa37d90e/packages/expo-modules-core/ios/NativeModulesProxy/EXNativeModulesProxy.mm#L228-L256)

# Test Plan

- unversioned expo go + NCL
- bare-expo
- unversioned expo go (based on react-native 0.69) + NCL

Co-authored-by: Tomasz Sapeta <[email protected]>

show more ...

[core][iOS] Register data component for the `EXViewManagerAdapter` (#17411)

[ios] Refactor Expo modules registration (#17225)

[ios] Fix event emitter not having access to the new module registry (#17064)

Co-authored-by: Tomasz Sapeta <[email protected]>

Fix JSI runtime being unexpectedly deallocated by shared pointer (#16828)

[ios] Revert TurboModule implementation of NativeModulesProxy (#16825)

[core] Fix ModulesProviderProtocol casting error in XCTest targets (#16733)

# Why

fix the `Fatal error: Expo modules provider must implement "ModulesProviderProtocol"` from XCTest targets and Swi

[core] Fix ModulesProviderProtocol casting error in XCTest targets (#16733)

# Why

fix the `Fatal error: Expo modules provider must implement "ModulesProviderProtocol"` from XCTest targets and SwiftUI preview builds.
fixes #16353

# How

it gets a little strange to me for the inconsistent behavior between normal targets and XCTest targets. the modulesProviders's `isa` pointer is generated `ExpoModulesProvider`, but it seems in the runtime ios cannot cast the instance back to swift.

my solution is to remove `ModulesProviderObjCProtocol`. since we can support objc <> swift interop right now, we can use `ModulesProvider` directly in objc.

# Test Plan

- bare-expo build and launch
- follow #16353 repro steps
- `npx react-native init` + `npx install-expo-modules` + test the XCTest target

show more ...

[core][ios] Evaluating JavaScript code from Swift (#16777)

[core] Stop relying on deprecated ViewPropTypes (#16207)

[android][ios] Fix versioning for expo go after react-native 0.67.2 upgrade (#16401)

# Why

for sdk45 and based on #16400

# How

- [tools] Fix versioning tools for react-native 0.67.2 upgrade

[android][ios] Fix versioning for expo go after react-native 0.67.2 upgrade (#16401)

# Why

for sdk45 and based on #16400

# How

- [tools] Fix versioning tools for react-native 0.67.2 upgrade
- [expo-modules-core][ios] Fix missing `EX` prefix to some objective-c files for versioning support
- [autolinking] Apply our cocoapods fix for `React-Core` swift support to versioned code
- [expo-updates] fix an incompatible `ReactInstanceManager` in UpdatesPackage where UpdateController is unversioned but UpdatePackage is versioned.
- [expo-file-system] okhttp/okio code for new versioned code build successfully. this is done in #16446

# Test Plan

- `et add-sdk -p android -s 45.0.0` and build/launch sdk 45 expo go with sdk 45 ncl
- `et add-sdk -p ios -s 45.0.0` and build/launch sdk 45 expo go with sdk 45 ncl

show more ...

[packages] Remove backward compatible workarounds and drop react-native 0.64 support (#16446)

# Why

basically because we cannot apply the okhttp/okio workaround to expo go versioned code. maintai

[packages] Remove backward compatible workarounds and drop react-native 0.64 support (#16446)

# Why

basically because we cannot apply the okhttp/okio workaround to expo go versioned code. maintaining these workarounds increase maintenance cost. since we are doing expo modules for next sdk based on react-native 0.67 or even 0.68, there's no reason we should keep backward compatible with 0.64.

# How

- okhttp/okio upgrade to the version as react-native 0.67.2 and migrate deprecated kotlin code.
- remove `EXComponentDataCompatibleWrapper` from expo-modules-core

# Test Plan

- ci pass
- bare-expo launch

show more ...

Upgrade to react-native 0.66 (#15914)

# Why

follow up https://github.com/expo/expo/pull/15817#discussion_r781366360
after we use the react-native from npm, the react-native version we used in ex

Upgrade to react-native 0.66 (#15914)

# Why

follow up https://github.com/expo/expo/pull/15817#discussion_r781366360
after we use the react-native from npm, the react-native version we used in expo-go is decoupled with other stuffs. that makes us upgrade react-native easier.

# How

1. update versions in package.json
2. sync changes from [react-native-upgrade-helper](https://react-native-community.github.io/upgrade-helper/?from=0.64.2&to=0.66.4)
3. `RCTComponentData` changed its designated initializer in react-native 0.65. to make it compatible with older version, i introduced the `EXComponentDataCompatibleWrapper` class to support different versions.
4. [react-native-lab] to fix expo-go build error, we should patch react-native to use the codegen library from its repo but not from node_modules: https://github.com/expo/react-native/pull/29.

# Test Plan

- CI passed
- bare-expo build & launch test
- unversioned expo-go build & launch test

show more ...

[ios][core] Make JSI host object for accessing the new modules (#15847)

[ios][core] Allow accessing RCTBridge from the modules (#15816)

[core][ios] Fix modules registration on iOS in bare-expo (#15752)

[core][ios] Add support for view prop callbacks (#15731)

[core] Introduce iOS ReactDelegate for React related instances creation (#15138)

# Why

original modularized AppDelegateWrapper isn't ideal for expo-updates. we had some bad side effect, e.g. doub

[core] Introduce iOS ReactDelegate for React related instances creation (#15138)

# Why

original modularized AppDelegateWrapper isn't ideal for expo-updates. we had some bad side effect, e.g. double bridge creation on startup.

close ENG-2299

# How

## For module authors

introduce `EXReactDelegate` dedicated for react related instances creation. so far we covered:

- RCTBridge
- RCTRootView
- RootViewController (for expo-screen-orientation)

if a module wants to handle these creation, there's 2 steps:

1. add `reactDelegateHandlers` in `expo-module.config.json`, e.g.

```
"ios": {
"reactDelegateHandlers": ["ScreenOrientationReactDelegateHandler"]
}
```

2. create `EXReactDelegateHandler` derived swift class, e.g.

```swift
// ScreenOrientationReactDelegateHandler.swift
public class ScreenOrientationReactDelegateHandler: ExpoReactDelegateHandler {
public override func createRootViewController(reactDelegate: ExpoReactDelegate) -> UIViewController? {
return EXScreenOrientationViewController()
}
}
```

since the order of whom to create the instance did matter, we also introduce `ModulePriorities.swift` similar to what we did on android.

## For app developers

the change to template is minimal, so codemod by `npx install-expo-modules` is also feasible.

```diff
- RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self launchOptions:launchOptions];
- RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge moduleName:@"main" initialProperties:nil];
+ RCTBridge *bridge = [self.reactDelegate createBridgeWithDelegate:self launchOptions:launchOptions];
+ RCTRootView *rootView = [self.reactDelegate createRootViewWithBridge:bridge moduleName:@"main" initialProperties:nil];

self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
- UIViewController *rootViewController = [UIViewController new];
+ UIViewController *rootViewController = [self.reactDelegate createRootViewController];
```

show more ...

[sweet][ios] Rename component "method" to "function"