Build error(s) - Undefined symbols when used as a transitive dependency

[maddapper]

Description

When I have a main project that depends on SwiftUI Navigation and an internal framework that also depends on SwiftUI Navigation, the build fails with this error:

Undefined symbol: CasePaths.AnyCasePath.init(embed: (B) -> A, extract: (A) -> B?) -> CasePaths.AnyCasePath<A, B> Undefined symbol: nominal type descriptor for CasePaths.AnyCasePath Undefined symbol: protocol descriptor for CasePaths.CasePathable

Interestingly, when I try the same configuration with just CasePaths, my project was able to build successfully. I'm assuming SPM builds these dependencies as dynamic frameworks since they are transitively referenced. I know it's not a versioning issue, since I use exact versions. I think this is a bug in SwiftUI Navigation. Thank you!

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

When including SwiftUI Navigation in both the main project and internal framework, I expect the build to be successful.

Actual behavior

Build fails with this error:
Undefined symbol: CasePaths.AnyCasePath.init(embed: (B) -> A, extract: (A) -> B?) -> CasePaths.AnyCasePath<A, B> Undefined symbol: nominal type descriptor for CasePaths.AnyCasePath Undefined symbol: protocol descriptor for CasePaths.CasePathable

Steps to reproduce

1. create a main project
2. add SwiftUI Navigation via SPM
3. create an internal framework project
4. add SwiftUI Navigation via SPM
5. build

SwiftUI Navigation version information

1.2.1

Destination operating system

iOS 17

Xcode version information

Version 15.3 (15E204a)

Swift Compiler version information

swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
Target: arm64-apple-macosx14.0

[mbrandonw]

Hi @maddapper, can you please provide a project path demonstrates the behavior?

[maddapper]

@mbrandonw it might be a build setting that is causing this behavior, so I'm trying to see what differences there are in my build settings.

[mbrandonw]

Yes, I highly doubt it is an issue with this library. It's a pretty simple SPM package.

I am going to convert this to a discussion and please feel free to continue the conversation over there.

[maddapper]

@mbrandonw if this is a build settings issue, which settings is causing this only in a transitive dependency environment? If i remove SwiftUI Navigation from the internal framework, the project builds and behaves as expected.

[mbrandonw]

First thing is that you don't need to explicitly depend on SwiftUINavigationCore. That is a library that only exists to give other libraries access to some basic types without needing to depend on all of SwiftUINavigation.

And second, I believe you can let InternalFramework depend on SwiftUINavigation, and then SwiftUINavigationSampleApp will depend on only InternalFramework. It doesn't need to also depend on SwiftUINavigation because it gets that transitively from InternalFramework.

[maddapper]

ok thanks that makes sense, i'm just wondering where the error comes from, since it doesn't happen in the case of CasePaths or any other dynamic framework that gets loaded.

[mbrandonw]

I'm really not sure. Perhaps ask on Apple's forums.

[maddapper]

interesting, this almost sounds like a bug in Apple's package resolver or something, but thanks for the quick response. either way, my issue is resolved and your work on CasePaths and SwiftUI Navigation is much appreciated. Maybe, one day, Apple will adopt CasePaths into the standard Swift library.