Cannot update to v2.1.1 - Error with pods and SPM both

Client SDKs iOS SDK 📱⌚️💻
#1

I am using Cocoapods and was trying to update iOS SDK to 2.1.1 but kept getting error

[!] CocoaPods could not find compatible versions for pod “Parse”:
In Podfile:
Parse (~> 2.1.1)

None of your spec sources contain a spec satisfying the dependency: Parse (~> 2.1.1).

You have either:

  • mistyped the name or version.
  • not added the source repo that hosts the Podspec to your Podfile.

so i removed from podfil, ran update and tried using SPM but getting error 'Parse/Parse.h' file not found. in bridging header file

How to resolve?

#2

I realised Cocoapods support was removed. How to resolve error to use SPM?

#3

Where do you get the error?

#4

In Bridging-Header.h file.

I moved everything except few frameworks to SPM from cocoapods and removed use_frameworks from podfile.

#5

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?

#6

No. Test project added.Test Project

#7

So the issue only occurs in your custom project, but not in a fresh project?

#8

Yes that is what it seems.

#9

My bad!
No it is not working in fresh project also. I had not added import statements earlier.

Corrected Test Project

#10

@Manuel Any suggestion?

#11
  • Which modules did you select to install? Please send a screenshot.
  • Where do you see the error? Please send a screenshot.
  • Does the issue also occur if you select all module / only the ParseCore module?
#12

I selected FacebookUtilsiOS, ParseObjc, ParseUI

Some screenshots here

i tried selecting all modules but facebookUtilstvOS kept giving compiling error. i Added tvOS in destinations also.

facebook-ios-sdk/FBSDKTVOSKit.xcframework:1:1 While building for iOS, no library for this platform was found in

#13

@Manuel did you get chance to check?

#14

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 :frowning:

#15

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 :frowning:

#16

What is the reason you are using Cocoapods instead of SPM?

#17

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.

#18

…that said, I have my build working with SPM and pod file right now :slight_smile:

#19

Having mixed SPM and cocoapods works but it’s not ideal - specifically it feels fragile as per the links I sent.

Could you elaborate on that? What are the downsides to that?

#20

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 :man_shrugging:. 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 :frowning: (although the Readme.md on GH is correct)