[Bug]: RouteOptions conformance to NSCopying in extension breaks archiving with BUILD_LIBRARY_FOR_DISTRIBUTION=YES

[ynnadrules]

Mapbox Navigation SDK version

2.0.0-rc.5

Steps to reproduce

1. Create a library-type Swift package with mapbox-navigation-ios as a dependency
2. Try to build a binary framework out of it by archiving (I used fastlane's xcodebuild action):

set -o pipefail && xcodebuild archive -archivePath "build/archives/MyFramework.framework-iphoneos.xcarchive" -derivedDataPath "build/derived_data/" -scheme "MyFramework" -destination "generic/platform=iOS" -sdk "iphoneos" BUILD_LIBRARY_FOR_DISTRIBUTION=NO SKIP_INSTALL=NO | tee '/Users/user/Library/Logs/fastlane/xcbuild/2021-10-13/97816/xcodebuild.log' | xcpretty --color --simple

Expected behavior

I expect the archive to complete successfully.

Actual behavior

The archive fails with these errors:

❌  /<redacted path>/build/derived_data/SourcePackages/checkouts/mapbox-navigation-ios/Sources/MapboxCoreNavigation/RouteOptions.swift:33:15: '@objc' instance method in extension of subclass of 'RouteOptions' requires iOS 13.0.0

    open func copy(with zone: NSZone? = nil) -> Any {
        ^



❌  /<redacted path>/build/derived_data/SourcePackages/checkouts/mapbox-navigation-ios/Sources/MapboxCoreNavigation/RouteOptions.swift:33:15: non-'@objc' method 'copy(with:)' does not satisfy requirement of '@objc' protocol 'NSCopying'

    open func copy(with zone: NSZone? = nil) -> Any {

Is this a one-time issue or a repeatable issue?

repeatable

[1ec5]

This extension is used by RouteOptions.without(_:) and RouteProgress.reroutingOptions(with:). #3191 explains the backstory. Essentially, removing this NSCopying usage is blocked by mapbox/mapbox-directions-swift#564.

[S2Ler]

@ynnadrules Can you please share what you are trying to do with enabled library evolution? We don't currently support it formally, so, even if we fix the compilation error above, you won't be able to guarantee that next version will be runtime-compatible with the previous version, even if there are no API breaking changes.

[ynnadrules]

@S2Ler Ah I see. What I'm trying to do is produce a release build of a framework that uses the mapbox sdk, then distribute that binary as a Swift Package. This is my first real foray into distributing a framework this way so I've been fumbling my way through different approaches, but kept running into this compilation error when running xcodebuild and adding this BUILD_LIBRARY_FOR_DISTRIBUTION=YES.

Producing a release build seems to work fine w/o BUILD_LIBRARY_FOR_DISTRIBUTION=YES, so with the understanding that this framework will have to be recompiled to target new versions of Swift as they come, are there any other issues you forsee here in what I'm trying to do, or do you have any recommendations?

[1ec5]

This extension is used by RouteOptions.without(_:) and RouteProgress.reroutingOptions(with:). #3191 explains the backstory. Essentially, removing this NSCopying usage is blocked by mapbox/mapbox-directions-swift#564.

#3484 implements a targeted workaround to get rid of the need for NSCopying conformance.

[1ec5]

Producing a release build seems to work fine w/o BUILD_LIBRARY_FOR_DISTRIBUTION=YES, so with the understanding that this framework will have to be recompiled to target new versions of Swift as they come, are there any other issues you forsee here in what I'm trying to do, or do you have any recommendations?

We haven’t audited our enumerations for freezability and may add new cases to some enumerations in the future. If I remember correctly, that can cause problems for binary compatibility even when we’re able to avoid breaking source compatibility.

Can you elaborate on why you need to redistribute the SDK as a binary package specifically, as opposed to allowing your package’s users to build it from source?

[ynnadrules]

@1ec5 My client has an SDK (currently a single framework) that they would like distribute as binary (an xcframework). This SDK offers some features that rely on mapbox, such as maps, navigation, directions. The idea was then to use SPM to distribute this binary as a Swift Package with binary target dependency.

Since the Mapbox SDKs don't support library evolution yet, it doesn't seem worth the effort to try to distribute my client's SDK as a closed source binary. On top of that, my client's SDK has swift package dependencies and according to this WWDC talk this type of setup isn't supported.