Improve determination whether a pod supports Swift Package Manager (SPM)

[MattLewin]

I originally submitted this issue against https://github.com/CocoaPods/cocoapods.org, but I realize this is probably the more appropriate repo. I'll close it over there. Sorry for any confusion.

When preparing my new pod for submission to the master spec repo, I wanted to support the SPM if possible. My pod is for iOS and uses UIKit. Last I had checked, the SPM did not support packages for anything but host platforms. (i.e., macOS and Linux) (SO post)

To my surprise, I found T-Pham/UILocalNotification-RemotePayload, which, according to its quality page, supports the SPM.

Given that UILocalNotification-RemotePayload relies upon UIKit, I was super-excited that the SPM might now support iOS packages. I spent the next hour confirming (repeatedly) that it still does not.

What does this mean?

Well, my conclusion is that the author of UILocalNotification-RemotePayload dropped a "Package.swift" file into his repo so that he could get an extra 10 "quality points."

While I won't comment on his gaming the system, I will point out that this kind of activity undermines the effectiveness of the Cocoapods quality metrics.

In addition -- and more important, in my mind -- this kind of thing leads to confusion for people discovering the repo. As was the case when I discovered this repo with its Package.swift, it can easily lead to someone thinking the SPM now supports iOS. That can, in turn, trigger a wild goose chase trying to determine why your own package doesn't seem to work with the SPM.

I propose we improve the quality metrics code to withhold the 10 points granted for supporting the SPM for projects that cannot possibly support it. As of today (2017-02-10), this means any projects that target iOS, watchOS, and tvOS. I think it may also mean any Cocoa apps, too, but I haven't tried that.

[orta]

Personally I'd rather be encouraging best practices (which SwiftPM support is and will be more important in the future) even if it's being abused occasionally.

Once SwiftPM becomes more usable, I'm happy for someone to improve CocoaDocs to actually run swiftpm on the project like we do for Carthage support.

[kylef]

I do believe it would be possible to use Swift PM in conjunction with iOS. It's not 100% straightforward and I have been planning to write a blog post about it after exploring it further. You should be able to use the generated Xcode project from Swift PM to integrate the framework as a sub project. I've been successful with a initial POC.

[orta]

👍 it's looking pretty soon that product-types like iOS apps will be built into SwiftPM too, swiftlang/swift-package-manager#953

[MattLewin]

Kyle- I've fiddled with this approach myself but had no success with the SPM for code importing UIKit. (Unsurprisingly.) For modules/frameworks reliant upon Foundation, the hoops to jump through are not a huge deal. I'd love to see your blog post: the more of this type of info that's out there, the better. Thanks.

…

-Matt

On Feb 14, 2017, at 4:11 AM, Kyle Fuller ***@***.***> wrote: I do believe it would be possible to use Swift PM in conjunction with iOS. It's not 100% straightforward and I have been planning to write a blog post about it after exploring it further. You should be able to use the generated Xcode project from Swift PM to integrate the framework as a sub project. I've been successful with a initial POC. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[MattLewin]

Well, this is awesome. 👏

…

On Feb 14, 2017, at 4:13 AM, Orta ***@***.***> wrote: 👍 it's looking pretty soon that product-types like iOS apps will be built into SwiftPM too, swiftlang/swift-package-manager#953 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.