[Bug]: Invalid inclusion of Privacy Manifest resource in Cocoapods

[fabiog27]

Mapbox Navigation SDK version

2.18.0

Steps to reproduce

• Create React Native app with v0.74.1 (https://reactnative.dev/docs/getting-started-without-a-framework)
• Include dependency https://github.com/jls-digital/react-native-mapbox-navigation: yarn add @jls-digital/react-native-mapbox-navigation@https://github.com/jls-digital/react-native-mapbox-navigation.git#commit=972baf38e229669eadc1ab13496879372fe4fc79
• Create main app privacy manifest in xcode (if not created by react native)
• Attempt to build for iOS

I am not sure if this applies to purely native apps including Mapbox Navigation via Cocoapods as well. React native aggregates privacy manifests from all dependencies, but I think it might happen without React Native as well, as the issue stems from the Target Support Files created by Cocoapods itself.

Environment:

• xcode 15.3
• cocoapods 1.14.3

Expected behavior

The app builds and runs successfully.

Actual behavior

Xcode throws an error Multiple commands produce PrivacyInfo.xcprivacy

The fix is pretty simple, you just have to switch s.resources to s.resource_bundle in MapboxCoreNavigation.podspec (it's already correct in MapboxNavigation.podspec). I have implemented it here, but I haven't checked for any side effects:

https://github.com/jls-digital/mapbox-navigation-ios/commit/72130cbb5e60c51dc0f7e1f8e66c59cdfd34b7f4#diff-e08c0c41e5868fe7d9db0246d9ec0429ad1193e57ec79be8236a54f638ddfb3eL40

Note that the inclusion of MBXInfo.plist is only due to us having to use the dependency statically from our fork. I would submit a PR, but I'm not sure how, because I've based my branch on our fork on the v2.18.0 tag and not main.

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

repeatable

[azarovalex]

Thanks for the detailed report @fabiog27! I'm going to look deeper into this problem, while I understand why this is happening it's not yet clear to me if including PrivacyInfo.xcprivacy to the resource bundle is a right way in case the framework is linked dynamically. My understanding is that it should be placed in the root of the framework and not inside of a resource bundle, going to check how exactly Cocoapods handles this.

If you don't want to be waiting for a new patch release you can depend directly on your fork, one of the benifits of using an open-source SDK like ours. 😄

[fabiog27]

Thank you for your response, @azarovalex. I'm proceeding with our fork, and I'm looking forward to being able to integrate it normally again!