-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Binary dependencies are unavailable in XCFramework format #2672
Comments
This is what it looks like when multiple pods set
It’s only a warning, but that might be because both pods happen to specify interchangeable values. |
It’s a warning when integrating the pod into a real project, at least in Debug if not also Release. But when linting the podspec or pushing it to CocoaPods trunk, it results in an error: #2739. |
Now that MapboxAccounts v2.3.1 and MapboxNavigationNative v28.1.0 are available, it should be possible to remove the arm64 workaround from MapboxCoreNavigation.podspec and apply the mapbox-navigation-ios/MapboxCoreNavigation.podspec Lines 51 to 59 in 49e4bfb
mapbox-navigation-ios/MapboxNavigation.podspec Lines 54 to 58 in 49e4bfb
|
All of MapboxCoreNavigation’s binary dependencies are now available as XCFrameworks, so MapboxCoreNavigation can now be built for simulators on M1-based Macs. For CocoaPods users, #2770 (available in v1.2.0-beta.1) streamlined the MapboxCoreNavigation podspec to no longer override the MapboxNavigation additionally depends on the map SDK, which still isn’t available as an XCFramework: mapbox/mapbox-gl-native-ios#171. For CocoaPods users, the podspec still overrides the |
As of #2771, Carthage users who only need MapboxCoreNavigation can now use SPM instead of Carthage to install that library with support for Apple Silicon. Here are some instructions, but you’ll need to use |
As of #2808 and v2.0.0-alpha.1, both MapboxCoreNavigation and MapboxNavigation support SPM. SPM actually defaults to static linking, which is even better in some ways than XCFramework. #2810 tracks removing the Carthage workaround in favor of relying on Carthage’s built-in XCFramework support. Part of the arm64 workaround is still in one of the CocoaPods podspecs. Leaving this issue open to track removing that workaround, which is blocked by mapbox/mapbox-gl-native-ios#171 in the v1.x branch and mapbox/mapbox-maps-ios#48 in the v2.x branch. |
@1ec5 , is it for 1.3.0 or 2.0 now? |
Fixed in #2808 for v2.0.0-alpha.1. |
Update: This issue has been fixed as of v2.0.0-alpha.1, but there are no plans to fix it in v1.x. A workaround is in place that allows v1.x to build for devices and simulators on Intel-based Macs and to build for devices but not simulators on Apple Silicon–based Macs.
The linker error in #2665 (specific to CocoaPods and Xcode 12) forced us to implement a workaround in #2667 that sets the
EXCLUDED_ARCHS
build setting not only in the MapboxCoreNavigation and MapboxNavigation framework targets but also in the developer’s application target. That gets us past the immediate issue and allows us to release v1.0.0, but it sets us up for incompatibility down the line. If another pod employs the same workaround, an application would be unable to install both pods at the same time.The better fix is to rebuild all three binary dependencies with Xcode 12 and distribute them as XCFrameworks. Once that build is available, we can remove the workaround from the podspecs:
Migrating these dependencies to XCFrameworks will also allow developers to use Carthage directly without a workaround script once Carthage/Carthage#3019 is released.
/cc @mapbox/navigation-ios
The text was updated successfully, but these errors were encountered: