[ios] Bump deployment target to 13.0 (#18873)

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

[ios] Bump deployment target to 12.0 (#14383)

* drop ios 11

* update bare-sandbox

* forgot some

* add PR link to changelogs

* Update packages/expo-cellular/CHANGELOG.md

Co-authored-by

[ios] Bump deployment target to 12.0 (#14383)

* drop ios 11

* update bare-sandbox

* forgot some

* add PR link to changelogs

* Update packages/expo-cellular/CHANGELOG.md

Co-authored-by: Expo CI <[email protected]>

* et pod-install after rebase

Co-authored-by: Expo CI <[email protected]>

show more ...

[ios] Migrate some packages to use expo-modules-core

[ios] Bump deployment target to iOS 11.0 (#11344)

[ios] Require CocoaPods >=1.10.0 to use prebuilt libraries
Before v1.10.0 binaries built for arm64 simulator were treated as the ones for the device and so the build fails at linking.

[ios] Make podspecs compatible with prebuilds (#11183)

[branch][image][media-library][random][splash-screen][updates][Expo][iOS] Change 'React' dependency to 'React-Core' (#11057)

Co-authored-by: Brent Vatne <[email protected]>

[expo-branch] Upgrade react-native-branch to 5.0.0 (#10204)

# Why

We want to remove IDFA code from iOS apps.

# How

Used `expotools`. On Android created a new `BranchIntentNotifier` which us

[expo-branch] Upgrade react-native-branch to 5.0.0 (#10204)

# Why

We want to remove IDFA code from iOS apps.

# How

Used `expotools`. On Android created a new `BranchIntentNotifier` which uses unimodules infrastructure to notify `RNBranchModule` of new Intents.

# Test Plan

Both Expo clients compiled.

show more ...

[react-native-branch] Upgrade to 5.0.0-rc.1 (#9625)

# Why

Cutoff approaches.

# How

- Used expotools
- Manually upgraded native dependencies
- [android] Removed `InstallReferer` reference

[react-native-branch] Upgrade to 5.0.0-rc.1 (#9625)

# Why

Cutoff approaches.

# How

- Used expotools
- Manually upgraded native dependencies
- [android] Removed `InstallReferer` reference
- [ios] Added compiler variable to `EXBranch` pod

# Test Plan

All (iOS, Android) x (Expo client, Bare Expo) compiled.

show more ...

Upgrade vendored modules (#6176)

# Why

As per the output of `gulp outdated-vendored-modules`:

Outdated native modules:
- DISMISS @expo/vector-icons: 10.0.0 bundled, latest on NPM is 10.0.6
-

Upgrade vendored modules (#6176)

# Why

As per the output of `gulp outdated-vendored-modules`:

Outdated native modules:
- DISMISS @expo/vector-icons: 10.0.0 bundled, latest on NPM is 10.0.6
- DONE @react-native-community/netinfo: 3.2.1 bundled, latest on NPM is 5.0.0-rc.1
- SWIFT-BLOCKED lottie-react-native: 2.6.1 bundled, latest on NPM is 3.2.1
- DONE react-native-branch: 3.1.1 bundled, latest on NPM is 4.2.1
- #6127 react-native-gesture-handler: 1.4.1 bundled, latest on NPM is 1.5.0
- DONE react-native-maps: 0.25.0 bundled, latest on NPM is 0.26.1
- DONE react-native-reanimated: 1.3.0 bundled, latest on NPM is 1.4.0
- WAIT-FOR-STABLE react-native-screens: 1.0.0-alpha.23 bundled, latest on NPM is 2.0.0-alpha.7
- DONE react-native-svg: 9.9.5 bundled, latest on NPM is 9.13.3
- DONE react-native-view-shot: 2.6.0 bundled, latest on NPM is 3.0.2
- DONE react-native-webview: 7.0.5 bundled, latest on NPM is 7.4.3
- #6162 react-native-appearance: 0.1.0 bundled, latest on NPM is 0.2.0-rc.0
- DONE react-native-safe-area-context: 0.5.0 bundled, latest on NPM is 0.6.0

BTW fixes https://github.com/expo/expo/issues/6165.

# How

Upgraded each module with an `expotools` command, checking after each one that the NCL tests pass.

# Test Plan

Manual NCL tests were ok.

show more ...

[ios][et][template-files] Make client's podfile static (#5783)

# Why

So far we've been generating client's podfile in `et ios-generate-dynamic-macros` and that file was git-ignored. This way was

[ios][et][template-files] Make client's podfile static (#5783)

# Why

So far we've been generating client's podfile in `et ios-generate-dynamic-macros` and that file was git-ignored. This way was causing a lot of issues with Podfile locks and Pods folder being out of sync after merging pull requests or rebasing branches.

# How

- Removed `/ios/Podfile` from `.gitignore`
- Replaced every template substitution in client's podfile template with the proper value and made it a static file. Most of those substitutions were already static or they differed only between SDK versions, but that's still fine.
- Two substitutions were more problematic - as they are being generated during versioning process. I decided to make a `PodfileHelpers.rb` script with some helpers that will be evaluating `ios/versioned-react-native/ABI*/{dependencies,postinstalls}.rb` scripts inside podfile. That way, we can still generate versioned parts of the podfile and automatically evaluate them when running `pod` commands.
- Removed `:inhibit_warnings => true` from all deps in podfile and used `inhibit_all_warnings!` at the top of the file with one small exception - unversioned unimodules will override that default setting with `:inhibit_warnings => false`. I also added a possibility to `r-n-u` to define custom pod flags: see https://github.com/unimodules/react-native-unimodules/commit/185a86a265d57f5e0f6b90401975ccf20b17aba3.
- `et ios-generate-dynamic-macros` no longer generates client's podfile.
- Updated `et add-sdk` & `et rm-sdk` to use `dependencies.rb` and `postinstalls.rb` scripts under `versioned-react-native/ABI*` folders instead of `template-files`. In fact, they are not templates now.
- Moved some dependencies and their version requirements from client's podfile to the unimodules that depend on them. For example, client doesn't really need to specify version requirement for `Amplitude` pod as it isn't used by the client directly, but by `expo-analytics-amplitude` unimodule. This also fixes some incompatibility issues that people might have had in bare workflow because unimodules were not specyfing dependencies' versions.

# Test Plan

- [x] Xcode builds the project.
- [x] `et add-sdk -p ios -s 36.0.0` generated correct `dependencies.rb` and `postinstalls.rb` scripts and they were correctly evaluated by `pod install`
- [x] `et rm-sdk -p ios -s 36.0.0` worked as well.
- [x] `client_ios` CI job is green

show more ...

[expo-branch] First 3rd party library unimodule wrapper! (#5165)

We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://github.co

[expo-branch] First 3rd party library unimodule wrapper! (#5165)

We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://github.com/expo/expo/issues/5132.

I added support for React Native-specific unimodules to React Native adapter. Right now it works like this:

- unimodule `expo-branch` depends on `react-native`, so it can use its API. It's no longer a uni-platform module, more an optinmodule (I guess the name won't stick)
- we copy `react-native-branch` vendored module directly to the unimodule. It will compile, since we added necessary dependencies to the unimodule
- `BranchPackage < org.unimodules.Package` implements `ReactPackage` interface too, forwarding all the calls to the vendored `RNBranchPackage`.
- when the module registry provider creates a module registry from a list of `Packages`, it can filter out `ReactPackages` — and so it does, putting them into a local internal module (`ReactPackagesProvider`) which only purpose is to carry those to `ModuleRegistryAdapter` which is responsible for creating a list of React Native modules out of a module registry. The adapter grabs the `ReactPackagesProvider` and adds React Native modules to the list.

I have confirmed that adding `BranchPackage` to a list of installed unimodules' packages creates `RNBranchModule` and exports to JS.

show more ...

[expo-branch] First 3rd party library unimodule wrapper! (#5165)

# Why

We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://

[expo-branch] First 3rd party library unimodule wrapper! (#5165)

# Why

We would like to provide a way to users to optionally include `react-native-branch` in their standalone apps. Fixes https://github.com/expo/expo/issues/5132.

# How

I added support for React Native-specific unimodules to React Native adapter. Right now it works like this:

- unimodule `expo-branch` depends on `react-native`, so it can use its API. It's no longer a uni-platform module, more an optinmodule (I guess the name won't stick)
- we copy `react-native-branch` vendored module directly to the unimodule. It will compile, since we added necessary dependencies to the unimodule
- `BranchPackage < org.unimodules.Package` implements `ReactPackage` interface too, forwarding all the calls to the vendored `RNBranchPackage`.
- when the module registry provider creates a module registry from a list of `Packages`, it can filter out `ReactPackages` — and so it does, putting them into a local internal module (`ReactPackagesProvider`) which only purpose is to carry those to `ModuleRegistryAdapter` which is responsible for creating a list of React Native modules out of a module registry. The adapter grabs the `ReactPackagesProvider` and adds React Native modules to the list.

# Test Plan

I have confirmed that adding `BranchPackage` to a list of installed unimodules' packages creates `RNBranchModule` and exports to JS.

show more ...