Add new "Xcode 11 Supplement" mode & Version 1.0.0

[Jeehut]

Since Apple has introduced SwiftPM as part of Xcode 11 even for iOS projects, which was always what we wanted and Accio was only introduced to fill the gap, we should embrace that. From the next major version of Accio onwards, we should treat using the built-in SwiftPM features in Xcode as a first class citizen and continue to use Accio for filling the gaps that are still apparent, like the missing support for Resources in libraries.

This also means that we can drop any features or ideas where we planned to improve the integration into Xcode or further embrace SwiftPM instead of Carthage. Instead, we should focus on the fact that many libraries still can't be integrated into projects via Package.swift because of one of the following:

1. The library simply has not added support for SwiftPM yet and it is not trivial.
2. The features the library provides can't currently be handled by SwiftPM (like resources).
3. The library is closed-source and can only be integrated as a pre-compiled binary.

The main goal of Accio 1.0.0 should be to ensure most of the iOS community finally get get rid of Podfiles and Cartfiles and use the Package.swift file as their single source of truth for all dependencies. The above three things are what I believe to be the most common issues.

The approach I suggest to take in order to embrace Xcode 11's built-in support for SwiftPM is to introduce a new "Xcode 11 Supplement" mode (which should probably be the default in version 1.0.0) where we don't handle any of the regular contents of the Package.swift file. Instead, we use a section that SwiftPM will ignore by default within the Package.swift file and handle only the contents there. The easiest approach to this could be to use comments:

// swift-tools-version:5.0
import PackageDescription

let package = Package(
    name: "XcodeProjectName",
    products: [],
    dependencies: [ // regular dependencies which have proper support for SwiftPM, handled by Xcode 11
        .package(url: "https://github.com/Flinesoft/HandySwift.git", .upToNextMajor(from: "2.8.0")),
        .package(url: "https://github.com/Flinesoft/HandyUIKit.git", .upToNextMajor(from: "1.9.1")),
        .package(url: "https://github.com/SwiftyBeaver/SwiftyBeaver.git", from: "1.6.2"),
        .package(url: "https://github.com/radex/SwiftyUserDefaults.git", .upToNextMajor(from: "4.0.0")),
        // accio: .package(url: "https://github.com/AccioSupport/Eureka.git", .branch("master"),
    ],
    targets: [
        .target(
            name: "AppTargetName",
            dependencies: [
                "HandySwift",
                "HandyUIKit",
                "MungoHealer",
                "SwiftyBeaver",
                "SwiftyUserDefaults",
                // accio: "Eureka",
            ],
            path: "AppTargetName"
        ),
    ]
)

In the above example, the // accio: is used to annotate a single line to be handled by Accio. All other dependencies except for Eureka in the example would be integrated by Xcode 11's built-in SwiftPM support. Eureka though, we would handle and integrate by building it with Carthage (for example).

Note that this will only work with the default structure in Package.swift files like in the example above, but that should fit most users. Other than a single line comment, we could also introduce a separate section for multi-line purposes like this:

// swift-tools-version:5.0
import PackageDescription

let package = Package(
    name: "XcodeProjectName",
    products: [],
    dependencies: [ // regular dependencies which have proper support for SwiftPM, handled by Xcode 11
        .package(url: "https://github.com/Flinesoft/HandySwift.git", .upToNextMajor(from: "2.8.0")),
        .package(url: "https://github.com/Flinesoft/HandyUIKit.git", .upToNextMajor(from: "1.9.1")),
        .package(url: "https://github.com/SwiftyBeaver/SwiftyBeaver.git", from: "1.6.2"),
        .package(url: "https://github.com/radex/SwiftyUserDefaults.git", .upToNextMajor(from: "4.0.0")),
        // accio: - dependencies not supporting SwiftPM for different reasons
        // .package(url: "https://github.com/AccioSupport/Eureka.git", .branch("master"),
    ],
    targets: [
        .target(
            name: "AppTargetName",
            dependencies: [
                "HandySwift",
                "HandyUIKit",
                "MungoHealer",
                "SwiftyBeaver",
                "SwiftyUserDefaults",
                // accio: - dependencies not supporting SwiftPM for different reasons
                // "Eureka",
            ],
            path: "AppTargetName"
        ),
    ]
)

We could even try to introduce a different top-level variable besides the existing let package = Package(...) which we could name something like let accio = Package(...), but I'm not sure if SwiftPM will ignore that gracefully. If it does, that might be even more elegant than comments.

What do you think, everybody? Especially our contributors, e.g. @mrylmz @fredpi @JensK611 @acecilia?

[fredpi]

@Dschee I like the idea!

Regarding the 3 issues you mentioned:

1. The library simply has not added support for SwiftPM yet and it is not trivial.

This is also a problem with the current version of Accio, as we use the Package.swift for parsing dependencies, but build using Carthage... This causes issues with libraries like Realm that build fine with Swift PM and Carthage, but not via Accio. If we can specify what is included via Accio and what is included via SwiftPM, that would solve this issue.

I'd prefer to have a syntax like let accio = Package(...) for such a specification, but didn't test whether that works.

2. The features the library provides can't currently be handled by SwiftPM (like resources).

This may change in Xcode 12 / 13, but until then, remains an issue...

3. The library is closed-source and can only be integrated as a pre-compiled binary.

This will probably never change or at least not very soon, so having this feature would definitely be great! There's already an issue regarding that: #5.

---

Overall, I'm in favor of adding such a mode and would start by examining what syntax it may be based on (Comment-based or using a dedicated Package instance).

[fredpi]

Closing this, as Accio is now deprecated.