Support for Swift Package Manager

[mickael-menu-mantano]

Xcode 11 finally brought native support for SPM, including iOS!

As the official package manager for iOS development, this should be the default choice used in Readium projects.

I think this could also simplify the build settings of the test app, that are right now split between Carthage and submodules. We could maybe use only SPM, setup either with a direct path to the submodules or with the URLs to the Git repositories.

[mickael-menu-mantano]

It might still be too early unfortunately... There's still no support for packaging resources, but a proposal is under discussion.

Readium relies on resources, for example localized strings in LCP and the navigator, and scripts in the navigator.

[mickael-menu]

Looks like resources in SPM are finally supported in Swift 5.3:

• Package Manager Resources proposal
• Package Manager Localized Resources proposal

We might be able to deprecate CocoaPods and Carthage 🕺

[jccr]

@mickael-menu I've been patiently awaiting resource bundle equivalents in SPM. This is great news.

[Truck3r]

Any progress on support for SPM? 🤞

[mickael-menu]

@Truck3r Nope, personally I didn't have time to start with SPM. If you would like to help, I think we need to tackle these things:

1. Go over all the dependencies of R2 modules and list the ones that are SPM-ready and the ones that aren't.
2. Find a solution for the ones that aren't: forking is a possibility, or looking for an alternative that works with SPM.
3. Integrate the SPM-ready dependencies and set up a Package.swift for each R2 module.

[Truck3r]

@mickael-menu I'd love to work on this, but being on a tight schedule I don't think I'll be able to put much time into it until Q3 this year.

[stevenzeck]

I went through the Cartfiles in all of the Swift modules and the results are below. Everything that is checked has a Package.swift file and supports iOS 10.0+, and the link goes directly to said Package.swift file.

There are two packages that are not SPM ready: edrlab/GCDWebServer and dexman/Minizip. For the latter, https://github.com/marmelroy/Zip might be a good option as it's also built on top of minizip

testapp

• onevcat/Kingfisher
• weichsel/ZIPFoundation
• jdg/MBProgressHUD
• stephencelis/SQLite.swift
• edrlab/GCDWebServer
• krzyzanowskim/CryptoSwift
• cezheng/Fuzi
• dexman/Minizip
• scinfu/SwiftSoup

navigator

• scinfu/SwiftSoup

shared

• dexman/Minizip
• cezheng/Fuzi

streamer

• dexman/Minizip
• cezheng/Fuzi
• krzyzanowskim/CryptoSwift
• edrlab/GCDWebServer

opds

• cezheng/Fuzi

lcp

• stephencelis/SQLite.swift
• krzyzanowskim/CryptoSwift
• weichsel/ZIPFoundation

[mickael-menu]

@stevenzeck Outstanding, thanks!

GCDWebServer is already a fork under the EDRLab umbrella so we could make it SPM ready. There is this PR to get rid of the HTTP server but it requires iOS 11+. However, we could let apps needing to support iOS 10 manage the HTTP server themselves.

For marmelroy/Zip, that's a good lead. It doesn't expose the advanced functions we need in its Swift API, but if we can access the bundled minizip, we could reuse our own MinizipArchive.

There is also the private R2LCPClient.framework, but it's non-blocking for R2 modules since r2-lcp-swift doesn't depend on it anymore.

[mickael-menu]

The original GCDWebServer repo is currently working on SPM.

[stevenzeck]

I added marmelroy/Zip as a Swift package in place of dexman/Minizip, it worked without having to change a thing.

That just leaves edrlab/GCDWebServer. As @mickael-menu mentioned there is a PR in the original repository to support SPM that could be used. Another option is replacing it with something like https://github.com/apple/swift-nio.

[mickael-menu]

I added marmelroy/Zip as a Swift package in place of dexman/Minizip, it worked without having to change a thing.

Nice, great news!

That just leaves edrlab/GCDWebServer. As @mickael-menu mentioned there is a PR in the original repository to support SPM that could be used. Another option is replacing it with something like https://github.com/apple/swift-nio.

The GCDWebServer PR is small enough to be worth backporting into our fork to settle this quickly. Although down the line I think it would be interesting to replace it with swift-nio for iOS 10, since it's maintained by Apple AND written in Swift (GCDWebServer uses Objective-C).