Do you get that error if you create a fresh new Xcode project and only add the SDK via SPM via the Xcode menu “Add packages…”? If yes; at which step exactly do you see the error?
I envountered this error yesterday when moving an old project from Cocoapads to SPM in order to get the latest Parse framework. It was in a normal header though, not the bridging header.
Why was cocoapods support removed? Maintenance can’t be a massive overhead
This SO question is relevant, but the Parse SPM definition looks to be exporting the correct folder. Looking at the Parse SPM file, it looks to be correctly declaring the path: path: "Parse/Parse", and making the correct folders public publicHeadersPath: "Source", from within that and Parse.h is there.
Similarly this discussion on the Swift forums is similar. Specifically:
The trick is to make sure the headers in the source directories are arranged the same way they eventually will be after CocoaPods copies them. Then the same relative paths can be used both when pointing at the source directory with SwiftPM and when pointing at the product directory with CocoaPods.
One quick thing to try is that Xcode doesn’t add a Swift package to every target when you initially add it. You need to add it explicitly to your targets from the build phases pane of the target browser. This didn’t work for me though
Because I have a project which relies on some other pods which aren’t available from SPM.
I would like to move to SPM for everything but I can’t - I expect others are in the same situation. Having mixed SPM and cocoapods works but it’s not ideal - specifically it feels fragile as per the links I sent. Given the overhead of maintains a profile is small, it doesn’t feel like Parse should just drop cocoapods support and force this hybrid approach.
See the linked issue on the SPM repo. The way Cocoapods copies header files means there are timing issues introduced to the build.
I also don’t really see why the pod file was removed at all (or Carthage). It’s not a massive overhead and it is still useful to a lot of people running long term projects on Parse.
Whatever, that’s just my opinion and my build works so . However, even assuming Cocoapods support doesn’t serve a purpose it needs to be deprecated properly. At the moment, the pod spec has been deleted from the Parse client library but not deprecated in the Cocoapods mainline. That means the current cocoa pod looks like it’s still working and doesn’t generate any warnings when you add it. But it leaves any projects stranded on an old version of the client lib. The podspec in the cocoa pods mainline needs a deprication adding to it. This is a simple change (add s.deprecated = true at the top level and then pod repo push Parse.podspec.json. Someone with write access to the Parse pod on trunk needs to make the PR.
However a worse error is that the iOS documentation still suggests installing the client library from Cocoapods (although the Readme.md on GH is correct)
. However, even assuming Cocoapods support doesn’t serve a purpose it needs to be deprecated properly. At the moment, the pod spec has