Adding support for Swift Package Manager

[karimhm]

Is there plans to add Swift Package Manager to this project?

[thomasvl]

If someone wants to contribute support, we'd be happy to review it. The hard part is going to be we don't want to reshuffle the code layout since it would break anyone directly integrating sources for the things they need. Likewise, we wouldn't want each directory to become a giant library, it probably needs to be like the cocoapods support where there are small units so folks can only depend on the parts they need.

[karimhm]

The project DOES NOT use ARC, currently Swift Package Manager compile Objective-C code with ARC on by default and there is no way to turn it off.

This project will need to be migrated to use ARC first before adding Swift PM support to it, or wait until Swift PM start supporting non ARC code.

[karimhm]

@thomasvl Is it ok to migrate this project to ARC?

[thomasvl]

That's likely a breaking change for folks directly using sources in their projects.

And every class would need to be double checked to see if things would be impacted by moving to ARC. ARC being pedantic can actually make some code slower because of the extra memory management it inserts.

[karimhm]

What about conditionally enabling ARC with compiler flags and macros?, would be tricky though.

[maxxfrazer]

I'm surprised Swift Package Manager isn't being seriously considered for this repo yet.

Is the worry of a breaking change the only thing holding it back?

[thomasvl]

From what we've seen on other ObjC projects, we'd probably should do a layout change because of how SwiftPM exposes things (like Firebase, gtm-session-fetcher, etc. have done). So yes, all that is what's holding things back.

From some things I've seen, it seems like CocoaPods is generally used for more integrations, SwiftPM usage is on the rise (but still a ways behind).

We're doing some general cleanup/pruning in here now, it might be worth revisiting ARC & SwiftPM after that work completes.

[maxxfrazer]

Great to hear it's in the pipeline!
From what I'm seeing, the only way in which swiftpm is behind is projects not supporting it yet; from a developer experience point of view it seems like a no-brainer.
On all of those projects not yet supporting it, I'd bet there's at least one open issue asking for it to be supported.

For example a quick search of "swift package manager" shows many issues opened on projects:

^ that's not even ordered by date, but all opened within the last 3 weeks.

iOS devs everywhere are ready to exclusively use swift package manager and drop CocoaPods.

The iOS community was impatiently waiting for swiftpm support from firebase a couple of years ago. It's still the second-most commented on issue:
firebase/firebase-ios-sdk#3136

[arthurschiller]

Hi,

I'd also like to emphasise the point of @maxxfrazer
And personally I've observed quite the opposite – with SPM rapidly becoming the new default.
My company completely moved away from Cocoapods and there is no going back.
With support for binary targets in SPM would ARC even be that much of an issue here? I understand that this shouldn't become one huge library and rather small individually consumable chunks. Just stating that from a developer perspective it's quite frustrating to be hold back from using stuff like the new ARCore GeoSpatial API because it's all CocoaPods only.

[salvatoreboemia]

News?

[salvatoreboemia]

News after 84 years?

Goole, WAKE UP, please!!!!