[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 ...

[ios] Refactor Expo modules registration (#17225)

[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 ...

[ios] New ExpoAppDelegate independent of singleton modules (#14867)

[ios] TurboModule implementation of expo modules proxy (#14626)

[ios][core] Automatically register expo modules (#14132)

[swift] Implement view managers with the new Swift API (#13704)

[ios] Foundation of first-class support for native modules written in Swift (#13272)

[ios] Merge unimodules core and adapter into expo-modules-core (#13353)

# Why

Part of Expo modules re-architecture

# How

- Copied iOS sources from `@unimodules/core` and `@unimodules/react-

[ios] Merge unimodules core and adapter into expo-modules-core (#13353)

# Why

Part of Expo modules re-architecture

# How

- Copied iOS sources from `@unimodules/core` and `@unimodules/react-native-adapter` to `expo-modules-core`
- In these copied files replaced `UM` prefix with `EX`
- Swift names for classes used by the users (`AppDelegateWrapper`, `ModuleRegistry`, `ModuleRegistryAdapter`, `ModuleRegistryProvider`) won't have any prefix — we would drop these prefixes anyway, in the future when we rewrite them to Swift
- Old `UM*` names are still supported and most of them are marked as deprecated, however I couldn't get it to work for Swift (but seems like no one uses it for app delegates?) and protocols
- `ExpoModulesCore` provides `EXUnimodulesCompat.h` header that expands old `UM_*` macros to `EX_*`
- Previously `ExpoModulesCore` depended upon `UMCore`, now it's the other way around — `UMReactNativeAdapter` and `UMCore` depend on `ExpoModulesCore` to import `EXUnimodulesCompat` header
- Fixed `EXTrackingTransparency` to depend on `ExpoModulesCore` directly
- _There are no changes in the logic or architecture of unimodules/expo modules, I'll do this separately_

# Test Plan

- CI jobs are passing
- Tested locally, apps seem to work as before

show more ...