| #
8b02c6d0 |
| 20-Jul-2023 |
Tomasz Sapeta <[email protected]> |
[iOS] Refactor version manager in Expo Go (#23624)
|
| #
0b4ca253 |
| 20-Mar-2023 |
Tomasz Sapeta <[email protected]> |
[core][ios] Remove legacy view managers (#21760)
|
| #
9ad1395c |
| 27-Apr-2022 |
Tomasz Sapeta <[email protected]> |
[ios] Refactor Expo modules registration (#17225)
|
| #
5ec78750 |
| 30-Mar-2022 |
Kudo Chien <[email protected]> |
[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 ...
|
| #
e217f0cc |
| 29-Dec-2021 |
Tomasz Sapeta <[email protected]> |
[core][ios] Add support for view prop callbacks (#15731)
|
| #
1c02086c |
| 28-Oct-2021 |
Tomasz Sapeta <[email protected]> |
[ios][core] Make it easier to import Swift header in expo-modules-core (#14939)
|
| #
9886c0aa |
| 28-Sep-2021 |
Kudo Chien <[email protected]> |
[expo-modules][ios] Fix errors from use_frameworks in Podfile (#14523)
# Why
close [ENG-1772](https://linear.app/expo/issue/ENG-1772/regression-test-for-use-frameworks-in-podfile)
fixes #13920
[expo-modules][ios] Fix errors from use_frameworks in Podfile (#14523)
# Why
close [ENG-1772](https://linear.app/expo/issue/ENG-1772/regression-test-for-use-frameworks-in-podfile)
fixes #13920
# How
- error: `The 'App' target has transitive dependencies that include static binaries`
declare `static_framework = true` in podspec. since all expo-modules ship in either source code or static xcframework, it should make sense to add `static_framework` declaration and solve this kind of errors.
- error: generated swift runtime header not found
fix like this because in framework mode, generated headers are inside module.
```diff
+#if __has_include(<ExpoModulesCore/ExpoModulesCore-Swift.h>)
+// For cocoapods framework, the generated swift header will be inside ExpoModulesCore module
+#import <ExpoModulesCore/ExpoModulesCore-Swift.h>
+#else
#import "ExpoModulesCore-Swift.h"
+#endif
```
- error: [gl] `<cassert>` import not found
this is supported in c++, thus rename to objc++ .mm files.
- error: [gl] `BLOCK_SAFE_RUN` inconsistent left/right operands types
this is side effect after renaming expo-gl files as .mm. fixed by explicitly cast as void.
- error: [core] undefined symbols in linking time, e.g. `EXRegisterModule`
this is side effect after renaming expo-gl files as .mm. fixed by export symbols by `extern "C"`, otherwise c++ will have different name mangling between c.
- rename `expo-image` pod to `EXImage`
- error: `Include of non-modular header inside framework module`
adding `DEFINES_MODULES` for cocoapods to create modulemap file. for external dependency like firebase, ignore the error by adding `CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES`
- error: expo-constant's app.config and expo-updates' app.manifest not found
in use_frameworks mode, the path is the same with non framework mode. `/$UNLOCALIZED_RESOURCES_FOLDER_PATH` is unnecessary.
- error: [barcode-scanner] ZXingObjC podspec GCC_PREPROCESSOR_DEFINITIONS does not export to EXBarCodeScanner and cause headers not found
add these defines explicitly
- [templates] add missing `react_native_post_install` from react-native 0.64 upgrade
- error: `Cycle inside FBReactNativeSpec; building could produce unreliable results. This usually can be resolved by moving the shell script phase '[CP-User] Generate Specs' so that it runs before the build phase that depends on its outputs.`
workaround by moving `FBReactNativeSpec` build phase script order.
Co-authored-by: Tomasz Sapeta <[email protected]>
# Test Plan
## prebuilt xcframework test
```sh
expo init -t /path/to/expo/templates/expo-template-bare-minimum sdk43
cd sdk43
# add `s.static_framework = true` for each `node_modules/expo-*/ios/*.podspec`
cd ios
# add `use_frameworks!` to Podfile
rm -rf Pods && pod install
cd ..
expo run:ios
expo run:ios --configuration Release
```
## regression for all expo-modules
```sh
expo init -t /path/to/expo/templates/expo-template-bare-minimum sdk43
cd sdk43
yarn add file:/path/to/expo/packages/expo-* # add all expo-modules one-by-one
# test non framework mode
expo run:ios
expo run:ios --configuration Release
# test framework mode
cd ios
# add `use_frameworks!` to Podfile
rm -rf Pods && pod install
cd ..
expo run:ios
expo run:ios --configuration Release
```
show more ...
|
| #
eb2c86e3 |
| 17-Sep-2021 |
Charlie Cruzan <[email protected]> |
[ios] Fix versioning script and shell app workflows (#14436)
* fix iOS shell app workflow
* fix versioning for Stripe to account for new files
* update versioning scripts
* fix JKBigInteger
[ios] Fix versioning script and shell app workflows (#14436)
* fix iOS shell app workflow
* fix versioning for Stripe to account for new files
* update versioning scripts
* fix JKBigInteger imports
* fix imports in expo-modules-core
* remove JKBigInteger2
* add comment
* Update CHANGELOG.md
show more ...
|
| #
1627a7bb |
| 15-Sep-2021 |
Kudo Chien <[email protected]> |
[expo-modules-core] revert prebuilding xcframework
# Why
the generated expo-modules-core xcframework from #14350 will cause errors when building apps.
# How
`git revert cb6a36461bb0685f747
[expo-modules-core] revert prebuilding xcframework
# Why
the generated expo-modules-core xcframework from #14350 will cause errors when building apps.
# How
`git revert cb6a36461bb0685f747084e0548d1af1a3598efc`
show more ...
|
| #
cb6a3646 |
| 09-Sep-2021 |
Kudo Chien <[email protected]> |
[expo-modules-core] fix prebuilding error (#14350)
# Why
fix `et prebuild-packages expo-modules-core` error caused by react-native header dependencies.
# How
add custom modulemap and includ
[expo-modules-core] fix prebuilding error (#14350)
# Why
fix `et prebuild-packages expo-modules-core` error caused by react-native header dependencies.
# How
add custom modulemap and include React-Core header while building expo-modules-core.
i was once worried for the generated xcframework would be large and accidentally include react-native symbols. fortunately, it doesn't. the generated xcframework is 5.8MB, compared to UMCore it's larger where i think coming from swift runtime. verifying the symbols by `nm -C ExpoModulesCore.xcframework/ios-arm64/ExpoModulesCore.framework/ExpoModulesCore`
# Test Plan
`et prebuild-packages expo-modules-core` successfully to generate xcframework.
please note that there was a xcode 12.5 crash issue for building expo-modules-core xcframework. please test with xcode 13. related issue: https://bugs.swift.org/browse/SR-14541 (thanks @tsapeta for sharing this information)
show more ...
|
| #
4dda5226 |
| 23-Aug-2021 |
Tomasz Sapeta <[email protected]> |
[ios][core] Automatically register expo modules (#14132)
|
| #
1f61a046 |
| 22-Jul-2021 |
Tomasz Sapeta <[email protected]> |
[swift] Implement view managers with the new Swift API (#13704)
|
| #
1cc4cbfb |
| 08-Jul-2021 |
Tomasz Sapeta <[email protected]> |
[ios] Foundation of first-class support for native modules written in Swift (#13272)
|
| #
ea3f1d02 |
| 24-Jun-2021 |
Tomasz Sapeta <[email protected]> |
[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 ...
|