It's relatively easy to do with SPM in theory, but in practice it can be a little complicated and requires the project to be structured a certain way. I currently have a private repo to vend out 3rd party frameworks for our builds.

However, the best solution would be for RevenueCat and other library providers to vend a separate GitHub repo such as RevenueCat/purchases-ios-xcframework which then would provide a Package.swift which declares the binaryTarget() with correct checksums for each release you ship. Then in my project I can just do the following in my Package.swift:

let package = Package(
// ...
  dependencies: [
   // Build this dependency from source code.  Good for Xcode beta releases, or incompatible Swift versions.
   .package(url: "https://github.com/RevenueCat/purchases-ios.git", from: "4.15.0"),
   // Or, build the dependency from the latest binary xcframework instead (much faster).
   .package(url: "https://github.com/RevenueCat/purchases-ios-xcframework.git", from: "4.15.0"),
  ],
// ...
)

When you vend it this way, then you can also directly add the dependency in Xcode without having to use a Package.swift file. Then the developer can just decide which version to build, either the xcframework or from source by changing the source URL.

It is relatively easy to automate the generation of releases in the xcframework repo using some simple build scripts and GitHub workflow actions, etc. since it doesn't need to build the source code, just update a checksum and point to the latest URL in the main repo.

@scogeo Oh wow I just read the issue and I hadn't seen the PR yet, this is amazing! We need to verify that it still works correctly with Carthage after the change, and then it's ready to 🚢

We'll look into the separate repo approach, I didn't know about it!

We might want to consider vending this as a different .zip, as in RevenueCat_SPM.xcframework.zip, just in case developers out there are using the current one and relying on its current folder structure in some automation

We might want to consider vending this as a different .zip, as in RevenueCat_SPM.xcframework.zip

Actually I think that's a great idea. @scogeo would you be able to make that change?

We might want to consider vending this as a different .zip, as in RevenueCat_SPM.xcframework.zip

Actually I think that's a great idea. @scogeo would you be able to make that change?

@NachoSoto Yes, I can make that change.

However, I am a little wary as I'm not sure how Carthage downloads the xcframework.zip files. I moved to SPM for all projects a while ago and haven't looked back. :) But I do know from looking at other projects that build xcframeworks for carthage, that carthage does not care what the name of the file is. I think it is likely that if you have two .xcframework.zip file that carthage will attempt to download both and probably create new issues. Let me do a quick experiment or two with carthage in my forked repo and report back.

A final note, the change I am proposing is more consistent with how other 3rd party libraries structure their .xcframwork.zip file. It really just seems to be an artifact of the using fastlane to build. Most other 3rd party libraries are using carthage itself to build the xcframeworks.

I did a quick test of this PR with Carthage this evening. So good news is this PR as it currently stands does work with carthage as expected. Again, multiple 3rd party libraries ship their framework .zip files this way.

The proposed addition of adding another file in the release named RevenueCat_SPM.xcframework.zip does also work in carthage. However, I think it is a bit of a fluke. While only one version of RevenueCat.xcframework appears in the project's Carthage/Build directory, carthage appears to have downloaded both .zip files and copied them to the build directory. So the last one to write the directory is the one that remains. So it would result in potentially unreproducible build issues if there was every a discrepancy between the two zip files. I can tell this by looking at Carthage's cache directory and can see it downloaded both .zip files.

Here's the Cartfile I used for this experiment and ran it with a trivial app that links with an initialized RevenueCat with an empty app id.

# Main repo
#github "revenuecat/purchases-ios" ~> 4.15.0

# With single unified RevenueCat.xcframework.zip (current PR)
#github "scogeo/purchases-ios" ~> 14.15.0

# With both original RevenueCat.xcframework.zip and RevenueCat_SPM.xcframework.zip in Release
github "scogeo/purchases-ios" ~> 14.16.0

I created two releases with a different major release version in my forked repo to test with. I used different version numbers so I could inspect the carthage cache. this is what it contains after running all repo options.

gscott@ragnarok:~/.../org.carthage.CarthageKit/binaries/purchases-ios
➜ pwd
/Users/gscott/Library/Caches/org.carthage.CarthageKit/binaries/purchases-ios

gscott@ragnarok:~/.../org.carthage.CarthageKit/binaries/purchases-ios
➜ ls -lR
total 0
drwxr-xr-x  3 gscott  staff   96 Dec 16 18:30 14.15.4/
drwxr-xr-x  4 gscott  staff  128 Dec 16 18:35 14.16.4/
drwxr-xr-x  3 gscott  staff   96 Dec 16 18:51 4.15.4/

./14.15.4:
total 97944
-rw-------  1 gscott  staff  50143876 Dec 16 18:30 ID<Asset>(rawValue: 88534491)-RevenueCat.xcframework.zip

./14.16.4:
total 459424
-rw-------  1 gscott  staff  175098967 Dec 16 18:35 ID<Asset>(rawValue: 88535242)-RevenueCat.xcframework.zip
-rw-------  1 gscott  staff   50143876 Dec 16 18:35 ID<Asset>(rawValue: 88535312)-RevenueCat_SPM.xcframework.zip

./4.15.4:
total 341992
-rw-------  1 gscott  staff  175098967 Dec 16 17:40 ID<Asset>(rawValue: 88361149)-RevenueCat.xcframework.zip

So I wouldn't recommend adding multiple xcframework.zip files in the release.

Anyway, I'll leave it up to you on how to proceed with the PR. I think this provides maximum backward compatibility with carthage and forward compatibility with SPM binary targets.

Closing this as it has diverged from main quite a bit and I have an in-house solution to this as part of my build system.