[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)
[modules][ios] Group together some common exceptions (#18732)
[ios] Experimental Expo modules support for Fabric (#18500)Co-authored-by: Kudo Chien <[email protected]>
[modules][ios] Use JSI to call native methods on legacy modules (#18438)
[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.
[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]>
[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
[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
[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
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
[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)
12