CocoaPods lint failure — could not find module 'MapboxNavigation' for target 'arm64-apple-ios-simulator' — v1.1.0 not available on CocoaPods trunk

[1ec5]

I’m unable to push v1.1.0 to CocoaPods trunk because of the following linting error:

    /var/folders/cl/8cgpg37n5cl78pjkbpgml94w0000gn/T/CocoaPods-Lint-20201112-87858-1cn1qqt-MapboxNavigation/App/main.swift:1:8: error: could not find module 'MapboxNavigation' for target 'arm64-apple-ios-simulator'; found: i386, x86_64-apple-ios-simulator, x86_64, i386-apple-ios-simulator
    import MapboxNavigation
           ^
    
    Ld /Users/mxn/Library/Developer/Xcode/DerivedData/App-folfjejeyqdekkgzlqcapuxagvpj/Build/Intermediates.noindex/App.build/Release-iphonesimulator/App.build/Objects-normal/i386/Binary/App normal i386 (in target 'App' from project 'App')

The CocoaPods integration test didn’t catch this error on CI for some reason.

/ref #2674
/cc @mapbox/navigation-ios @frederoni

[zugaldia]

What has changed compared to the RC that could be impacting our ability to publish to Cocoapods?

[1ec5]

I’m concerned that this may be fallout from mapbox/mapbox-gl-native-ios#482, which implemented a slightly different workaround for CocoaPods/CocoaPods#10065 CocoaPods/CocoaPods#10104 than #2667. The two settings can conflict, which is why we were hoping to replace the workaround in #2667 with XCFrameworks (with or without proper Apple Silicon support): #2672. mapbox/mapbox-gl-native-ios#482 went into map SDK v6.3.0, which was released two days ago, after navigation SDK v1.1.0-rc.1.

The other reason we didn’t encounter this issue the other day is that we haven’t been pushing prereleases to CocoaPods trunk. Apparently pod trunk push performs more stringent checks than pod spec lint, which is what we normally run on CI. We have considered pushing prereleases to CocoaPods trunk, but it comes with the downside that developers can easily get stuck on old prereleases.

/cc @ZiZasaurus

[1ec5]

mapbox/mapbox-gl-native-ios#482 doesn’t appear to be the culprit: pod spec lint is even failing if I pin the Mapbox-iOS-SDK dependency to = 6.2.2. I wonder if the workaround is even working at all in Xcode 12.1.

[1ec5]

v6.2.1 is unaffected by the linker error, but v6.2.2 and v6.3.0-alpha.1 are both affected. The only relevant changes in mapbox/mapbox-gl-native-ios@0d7e8a7...c76f3e5 are mapbox/mapbox-gl-native-ios#482 and the upgrade of MapboxMobileEvents from ~> 0.10.4 (which currently resolves to v0.10.5) to ~> 0.10.5-beta.2. But mapbox/mapbox-gl-native-ios@ios-v6.2.1...ios-v6.2.2 doesn’t seem to have incorporated either change.

I’m using Xcode 12.1 (12A7403) and CocoaPods 1.10.0.

[1ec5]

The podspec for map SDK v6.2.2 doesn’t contain the problematic EXCLUDED_ARCHS build setting from mapbox/mapbox-gl-native-ios#482:

https://github.com/mapbox/mapbox-gl-native-ios/blob/ios-v6.2.2/platform/ios/Mapbox-iOS-SDK.podspec

But it’s in the v6.2.2 podspec on CocoaPods trunk:

https://github.com/CocoaPods/Specs/blob/6c5b50f2141de20aa09ef1d7fb2c7eea92715edd/Specs/a/5/9/Mapbox-iOS-SDK/6.2.2/Mapbox-iOS-SDK.podspec.json#L33-L38

The Pods/Mapbox-iOS-SDK/Mapbox-iOS-SDK.{debug,release}.xcconfig that pod spec lint generates ends up with this setting:

EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64 arm64e

I wonder if mapbox/mapbox-gl-native-ios#482 had been applied manually without being committed anywhere. https://github.com/mapbox/mapbox-gl-native-ios/tree/release-z doesn’t have anything after mapbox/mapbox-gl-native-ios#509.

[1ec5]

The only immediate workaround I know of is to constrain the Mapbox-iOS-SDK dependency to exclude v6.2.2 and above:

Index: /Users/mxn/hub/mapbox-navigation-ios/MapboxNavigation.podspec
index a9421d5f..416ffba4 100644
--- a/MapboxNavigation.podspec
+++ b/MapboxNavigation.podspec
@@ -44,7 +44,8 @@ Pod::Spec.new do |s|
   s.module_name = "MapboxNavigation"
 
   s.dependency "MapboxCoreNavigation", "#{s.version.to_s}"
-  s.dependency "Mapbox-iOS-SDK", "~> 6.0"
+  s.dependency "Mapbox-iOS-SDK", ">= 6.0.0"
+  s.dependency "Mapbox-iOS-SDK", "< 6.2.2"
   s.dependency "Solar", "~> 2.1"
   s.dependency "MapboxSpeech", "~> 1.0"
   s.dependency "MapboxMobileEvents", "~> 0.10.2" # Always specify a patch release if pre-v1.0

However, v6.2.2 contains important fixes like mapbox/mapbox-gl-native-ios#501 and mapbox/mapbox-gl-native-ios#483 that very noticeably impact the navigation SDK. I don’t think we’d be willing to put out a v1.1.0 that effectively regresses #2658.

(This double dependency does lint successfully, demonstrating that CocoaPods allows a dependency to be constrained to avoid a future semver violation without pinning to a specific patch version. However, only CocoaPods and SPM allow this kind of range dependency, not Carthage.)

[1ec5]

mapbox/mapbox-gl-native-ios#549 would align the map SDK’s workaround build settings to those of MapboxCoreNavigation, theoretically ensuring compatibility with MapboxNavigation. I pushed the patched podspec under a throwaway pod at CocoaPods/Specs@a1b0a72, as well as a podspec that requires it at CocoaPods/Specs@c641e30. Unfortunately, in a test project that requires both the test Mapbox-iOS-SDK and test MapboxNavigation pods, iPhone 8 simulator builds in Release configuration fail to build because the MapboxNavigation module can’t be found:

/path/to/ViewController.swift:3:8: No such module 'MapboxNavigation'

The same error arises when importing MapboxCoreNavigation. It’s unclear to me whether this error is due to the punctuated test pod name or whether it’s a fundamental limitation of the workaround. I’ll have to try again with a more conventional pod name.