search

google / google-toolbox-for-mac

Google Toolbox for Mac
Apache License 2.0
1.14k stars 234 forks source link

Adding support for Swift Package Manager #258

Open karimhm opened 4 years ago

karimhm commented 4 years ago

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

thomasvl commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

thomasvl commented 4 years ago

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 commented 4 years ago

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

maxxfrazer commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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:

Screenshot 2022-05-18 at 22 46 19

^ 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: https://github.com/firebase/firebase-ios-sdk/issues/3136

arthurschiller commented 2 years ago

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 commented 5 months ago

News?

salvatoreboemia commented 2 months ago

News after 84 years?

Goole, WAKE UP, please!!!!