[Request] Implement Swift Package Manager Support

[bdrelling]

Mirroring this issue in your other repository: https://github.com/Appboy/appboy-segment-ios/issues/29

Specifically because when we need to rely on specs in this repo that pull in SDWebImage, Braze is now forcing us to downgrade from using SDWebImage via SPM.

I understand there is a dependency on Swift 5.3 which is just around the corner and we (and I'm sure any others) really need to see support for SPM as soon as possible.

[Frizlab]

SPM support is a no brainer and should have been done long ago IMHO.

EDIT: It seems you need support for binary dependencies. We’ll get those in Swift 5.3! I hope you’ll be SPM-compatible then 🙃

[Bucimis]

Thanks all for being understanding around the 5.3 dependency. @bdrelling thoughts on workarounds to help you use SDWebImage from SPM? In theory you could use our framework binary (which doesn't care where SDWebImage comes from as long as it's there) but in some ways that's probably more cumbersome than just using Cocoapods...

[bdrelling]

@Bucimis Yeah, I’m not sure what an appropriate workaround would be at this time. For some of our own frameworks, we tend to keep functionality like this protocol-based and provide a submodule/subspec with the implementation from a preferred provider, but allow a client to opt out of the submodule/subspec and inject their own.

For example, abstracting the SDWebImage functionality you use into protocols that you then make SDWebImage conform to in a submodule that makes it easy for consumers to pull in if they want a quick solution, but would allow us to inject SDWebImage, Kingfisher, AlamofireImage, or anything of the sort.

Might not be as easy as a workaround, but depending on how much functionality you use from the library, this could be a relatively quick implementation.

[BryanNorden]

Any update on this?

[Bucimis]

Hi @BryanNorden, we're working on this internally but don't have a particular timeline to share now. When we have a beta version available to test, we'll ping this channel

[Bucimis]

Hey everyone, a few updates to share

1. We’ve been building towards SPM support as a fast-follow to the iOS 14/XCode 12 release. Our internal work supporting SPM is more or less complete.
2. Our plan is to release SPM support as part of a larger jump to v4.0 that includes a Cocoapods build that is backed by a static core XCFramework - static in order to allow people to import files the same way they did with our existing static lib. After doing that, all of our pre-compiled code would be distributed in XCFrameworks (for both SPM and Cocoapods, Carthage TBD)
3. Our Cocoapods release is blocked by Cocoapods 1.10.0, which is now in rc (https://github.com/CocoaPods/CocoaPods/releases/tag/1.10.0.rc.1) and which members of our team contributed to (to fix certain things around static XCFrameworks).
4. Our plan is to release our initial support for SPM+Cocoapods XCFrameworks in beta in appx 1-1.5 weeks. We were hoping to release just after Cocoapods released 1.10.0 but we may need to leave them behind just to get this into the hands of folks.

Let us know your thoughts around the plan/timeline here (particularly on our goal of coupling Cocoapods/SPM+XCFrameworks together)!

[borut-t]

@Bucimis great, but could you release SPM support separately from Cocoapods? I think those two are not related. Ones who will opt-in to SPM will not use cocoapods 🤷‍♂️

[Bucimis]

@borut-t appreciate the callout. We wanted to initially work "all things XCFramework" into a single release, but as you mention, SPM folks don't need the Cocoapods support and would prefer to get support faster rather than wait for us to finish Cocoapods.

We've updated our plan to reflect that reality and are now planning to release SPM first. In terms of SPM support, we're working through the last few QA issues and are day to day in terms of being able to release with a working best guess of early next week.

[Bucimis]

Thanks everyone for your continued patience and input! We've just released initial SPM support in 3.29.0 (https://github.com/Appboy/appboy-ios-sdk/blob/master/CHANGELOG.md#3290). Let us know how it goes!

[borut-t]

Thank you @Bucimis for SPM support. I've successfully replaced cocoapods version with spm one 👍 Here are some thoughts:

1. What do we need Post-actions run script for? It seems to be working without 🤔
2. Can you also update the documentation?
3. Imports are changed now. You need to replace import Appboy_iOS_SDK with import AppboyUI. That could also be part of the documentation update.

[tbelote]

Thank you @Bucimis for SPM support. I've successfully replaced cocoapods version with spm one 👍 Here are some thoughts:

1. What do we need Post-actions run script for? It seems to be working without 🤔
2. Can you also update the documentation?
3. Imports are changed now. You need to replace import Appboy_iOS_SDK with import AppboyUI. That could also be part of the documentation update.

Hi @borut-t , Thanks very much for the feedback!

1. Apple earlier had an issue where dynamically linked libraries weren't copied in to the built app, and they appear to have fixed it by always copying all libraries. Since the AppboyKitLibrary is statically linked, it doesn't need to be copied. The post-action run script will reduce the file size of the IPA and app archive, and it will also prevent you from getting an error when submitting your app to the App Store.
2. Yes, this is on our todo list.
3. Good point, we will be sure to call that change out in documentation.

[borut-t]

Thanks 👍

[tbelote]

Thanks 👍

@borut-t One more thing my colleague reminded me of, if you don't use the post action script, Apple will actually reject the IPA when submitting to the App Store.

[borut-t]

Interesting. Thanks for the heads up.