Changes in EXBranch.podspec

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

Wed, 14 Sep 2022 07:55:46 +0000

[ios] Bump deployment target to 13.0 (#18873) List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

9886c0aa - [expo-modules][ios] Fix errors from use_frameworks in Podfile (#14523)

Tue, 28 Sep 2021 08:37:25 +0000

[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() +// For cocoapods framework, the generated swift header will be inside ExpoModulesCore module +#import +#else #import "ExpoModulesCore-Swift.h" +#endif ``` - error: [gl] `` 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 # 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 ``` List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Mon, 13 Sep 2021 14:40:05 +0000

[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 <34669131+expo-ci@users.noreply.github.com> * et pod-install after rebase Co-authored-by: Expo CI <34669131+expo-ci@users.noreply.github.com> List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Sat, 24 Jul 2021 09:19:55 +0000

[ios] Migrate some packages to use expo-modules-core List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Tue, 15 Dec 2020 11:05:35 +0000

[ios] Bump deployment target to iOS 11.0 (#11344) List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

52a1f6d0 - [ios] Require CocoaPods >=1.10.0 to use prebuilt libraries

Fri, 04 Dec 2020 14:25:11 +0000

[ios] Require CocoaPods >=1.10.0 to use prebuilt librariesBefore v1.10.0 binaries built for arm64 simulator were treated as the ones for the device and so the build fails at linking. List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Wed, 02 Dec 2020 13:18:06 +0000

[ios] Make podspecs compatible with prebuilds (#11183) List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Tue, 17 Nov 2020 04:22:34 +0000

[branch][image][media-library][random][splash-screen][updates][Expo][iOS] Change 'React' dependency to 'React-Core' (#11057)Co-authored-by: Brent Vatne List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Wed, 16 Sep 2020 18:19:22 +0000

[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. List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Thu, 13 Aug 2020 16:58:32 +0000

[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. List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

000da56b - Upgrade vendored modules (#6176)

Wed, 06 Nov 2019 08:28:36 +0000

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. List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Thu, 03 Oct 2019 07:44:52 +0000

[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 List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Tue, 06 Aug 2019 13:17:13 +0000

[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. List of files: /expo/packages/expo-branch/ios/EXBranch.podspec

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

Tue, 06 Aug 2019 13:17:13 +0000

[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. List of files: /expo/packages/expo-branch/ios/EXBranch.podspec