A dependency manager driven by SwiftPM that works for iOS/tvOS/watchOS/macOS projects.

Overview

Build Status Codebeat Badge Version: 0.6.6 Swift: 5.0 Platforms: macOS License: MIT

InstallationUsageSupporting AccioContributingLicense

⚠️ Deprecation Notice ⚠️

With the release of Xcode 12 which includes Swift 5.3, we feel like there is no gap left to fill by Accio on the move to SwiftPM anymore, thus we are deprecating support for Accio in those versions, instead please use the built-in SwiftPM feature in Xcode. Namely, these features were added to SwiftPM recently:

Accio

A dependency manager driven by SwiftPM that works for iOS/tvOS/watchOS/macOS projects.

Pronunciation

Since this question comes up pretty often, here's the official way to pronounce the name of this library: "AH-kee-oh"

Rationale: While different opinions seem to exist, the official movies (like in this video), this Harry Potter Wiki article and many latin advocates seem to support the above pronunciation.

Requirements

  • Xcode 10.0-11.7 and Swift 5.0-5.2
  • Xcode Command Line Tools (see here for installation instructions)
  • Carthage 0.32+ (install from here)

Installation

Via Homebrew:

To install Accio the first time, run these commands:

brew tap JamitLabs/Accio https://github.com/JamitLabs/Accio.git
brew install accio

To update it to the latest version, run this instead:

brew upgrade accio

Via Mint:

To install Accio or update to the latest version, run this command:

mint install JamitLabs/Accio

Why should I use this?

TL;DR: It offers many improvements over Carthage and is targeted towards SwiftPM's integration into Xcode.

To learn more about the motivation, rationale & design of Accio, read this blog post.

Alternatively, read the following expandable summary:

Summary of the Motivation & Advantages

For developers on Apple platforms there are already well established dependency managers, namely CocoaPods & Carthage. If you like how CocoaPods deals with things, you probably won't ever need to use Accio. It doesn't do anything that CocoaPods doesn't.

But if you are like the many developers who prefer to use Carthage because it's written in Swift (not Ruby) and it doesn't create an Xcode workspace but is rather unintrusive, you might find that Accio solves some of the problems you might have come across with Carthage.

Accios main advantages over Carthage as of now are:

  1. Allows to specify which schemes should be built and skips all others.
    (#1227, #1990, #1616)
  2. Automates the linkage & cleanup of your specified frameworks within your Xcode project.
    (#1131, #2605, #145, #2477, replaces Carting)
  3. Automatically uses a device-local cache to prevent rebuilding the same commit of a framework for a different project.
    (#2400, #2716)
  4. Has an option to use a shared cache path (instead of the device-local cache) within a team so only a single person ever needs to build a specific commit of a dependency and all others in the team can reuse that cached build cutting off build times of the team considerably.
    (Replaces Rome)

Accio was designed as the all-in-one tool for any improvements you might need for managing dependencies using Carthage. It's explicitly open for new features from the community as long as they improve aspects of dependency management for the Apple developer community.

Additionally, the core of Accio was designed to use SwiftPM as much as possible because we think it will at some point replace the need for an extra dependency manager completely. Until that time, making an open source project "Accio compliant" basically means adding a manifest file that exactly matches that of SwiftPM. This way Accio is trying to fill the gap between now and the time when Xcode properly supports SwiftPM for Apple platform projects (which we guess to be at WWDC 2020) and most Accio compatible projects might already be compatible out of the box when the time comes.

Usage

Getting Started

This section describes on how to get started with Accio.

Deintegrating Carthage (optional)

If you want to migrate your Carthage-driven project to Accio, here are the steps to deintegrate Carthage:

  1. Remove any linked dependency frameworks in the project hierarchy (this will automatically unlink from any targets)
  2. Delete the Carthage copy build phase
  3. Delete any files beginning with Cartfile
  4. Remove the Carthage directory entirely
  5. Remove Carthage entries like $(PROJECT_DIR)/Carthage/Build/iOS from the FRAMEWORK_SEARCH_PATHS within the build settings

Initialization

To configure Accio in a new project, simply run the init command and provide both the name of the Xcode project file (without extension) and your App target(s) (separate multiple targets by a comma). For example:

accio init -p "XcodeProjectName" -t "AppTargetName"

This step will create a template Package.swift file and set some .gitignore entries to keep your repository clean. Please note that if your source code files aren't placed within directories named after the targets, you will need to explicitly set the path parameters within the targets in the Package.swift file to the correct paths. Also note that the specified path must be a directory recursively containing at least one Swift file – but mixing with other languages like (Objective-)C(++) is not supported, so they shouldn't be within the specified directory. The files in there will not be built, they just need to exist in order for SwiftPM to work properly, so you could point this anywhere Swift-only code.

Run accio init help to get a list of all available options.

Adding Dependencies

Accio uses the official SwiftPM manifest format for specifying dependencies. So in order to add a dependency, you will need to do two things:

  1. Add a .package entry to the dependencies array of your Package
  2. Add all scheme/library names you want to build to the dependencies section of the appropriate target(s)

Here's an example Package.swift file with multiple dependencies specified:

// swift-tools-version:5.0
import PackageDescription

let package = Package(
    name: "XcodeProjectName",
    products: [],
    dependencies: [
        .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/JamitLabs/MungoHealer.git", .upToNextMajor(from: "0.3.2")),
        .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")),
    ],
    targets: [
        .target(
            name: "AppTargetName",
            dependencies: [
                "HandySwift",
                "HandyUIKit",
                "MungoHealer",
                "SwiftyBeaver",
                "SwiftyUserDefaults",
            ],
            path: "AppTargetName"
        ),
    ]
)

Installing Dependencies

To install the dependencies, you can use either the install or update command. The only difference is, that install won't update any dependency versions if they were already previously resolved. update will always update to the latest version within the specified range. For example:

accio install

When running this the first time in a project, the following steps will be taken:

  1. Checkout all dependencies (using SwiftPM) & build them (using Carthage)
  2. Cache all build products to a local cache directory for future reuse in other projects
  3. Create a folder named Dependencies with the build products
  4. Create a group in Xcode named Dependencies with the build products correctly linked to the appropriate targets
  5. Add a copy build script phase named Accio to the configured targets & update the input paths appropriately

On future runs, both install and update will make sure all these created directories & build scripts are kept up-to-date so you don't ever need to change them manually. Actually, you shouldn't change their contents, reordering is fine though.

Please note that before running any of the install commands, you should close your project if you have it open in Xcode. Otherwise some unexpected problems could occur when Accio rewrites the project file.

Additionally, for both install commands you can provide a path to a shared cache to copy the build products to instead of the local cache. For example:

accio install -c '/Volumes/GoogleDrive/Team Share/AccioSharedCache'

Specifying this can drastically cut your teams total dependencies building time since each commit of a dependency will be built only once by only one person in the team.

Please note that a global cache is planned to be added as an opt-in option in the near future for those who trust our CI setup regarding security. Details will follow.

Run accio install help or accio update help to get a list of all available options.

Configuring Accio's default behavior

You can configure Accio to always automatically use a shared cache path without the need to specify it as an option by writing it into the Accio config file like so:

accio set-shared-cache /Volumes/GoogleDrive/TeamShare/AccioCache

Note that the config file is saved to /Users/<Name>/Library/Application Support/Accio/config.json. Simply delete it to reset all configuration options.

Clearing local Cache

Since Accio automatically caches any build products locally on your machine, this can result in the cache taking up quite some space after a while. So you might want to clear up the local cache from time to time by running the clear-cache command:

accio clear-cache

This will remove all build products from the cache and tell you how much file size was freed up. Please note that there's currently no way of clearing a shared cache to prevent any accidental deletes by a single team member. Please do this manually if your shared space gets too filled up.

Note: There is also a clean command which this should not be confused with. The clean command will only remove the files within the .accio build path leading to all dependencies being freshly checked out on next install. Also it deletes any temporary leftover files from failed or cancelled runs of Accio.

Adding support for Accio

Most libraries that are compatible with SwiftPM should automatically work with Accio. There's also a Demo project with integration tests on the CI to ensure most Swift frameworks on GitHub with at least 1,000 stars support Accio. Libraries that are compatible with Carthage can be easily made compatible with Accio by simply adding a Package.swift file similar to this:

// swift-tools-version:4.2
import PackageDescription

let package = Package(
    name: "LibraryName",
    // platforms: [.iOS("8.0"), .macOS("10.10"), .tvOS("9.0"), .watchOS("2.0")],
    products: [
        .library(name: "LibraryName", targets: ["LibraryName"])
    ],
    targets: [
        .target(
            name: "LibraryName",
            path: "LibraryName"
        )
    ]
)

Please note that the commented platforms parameter line can be uncommented if the library only supports Swift 5 or up (it was added to Swift Package Manager via proposal SE-0236). But it is currently recommended to keep the line commented out for Swift 4.2 compatibility – Accio will take care of specifying the target versions manually if the line is commented out.

If the library has subdependencies, link the projects within the dependencies array of the target and the library names in the dependencies array of the targets. For example:

// swift-tools-version:4.2
import PackageDescription

let package = Package(
    name: "LibraryName",
    // platforms: [.iOS("8.0"), .macOS("10.10"), .tvOS("9.0"), .watchOS("2.0")],
    products: [
        .library(name: "LibraryName", targets: ["LibraryName"])
    ],
    dependencies: [
        .package(url: "https://github.com/Alamofire/Alamofire.git", .upToNextMajor(from: "4.1.0")),
        .package(url: "https://github.com/antitypical/Result.git", .upToNextMajor(from: "4.0.0")),
    ],
    targets: [
        .target(
            name: "LibraryName",
            dependencies: ["Alamofire", "Result"],
            path: "LibraryName"
        )
    ]
)

Refer to the official Package manifest documentation for details on how it can be configured, for example the other options for the version range specification of dependencies.

If you come across any issues with a dependency that you expect to work with Accio, please open an issue on GitHub.

Official Badge

Accio supported

To hint that your project supports installation via Accio, add the following to the top of your README.md:

[![Accio supported](https://img.shields.io/badge/Accio-supported-0A7CF5.svg?style=flat)](https://github.com/JamitLabs/Accio)

Contributing

See the file CONTRIBUTING.md.

License

This library is released under the MIT License. See LICENSE for details.

Logo Design by Dogan Duran.

Comments
  • accio fails to install dependencies

    accio fails to install dependencies

    I thought I give accio a try for a macOS project. I've created a simple Package.swift file:

    // swift-tools-version:5.0
    import PackageDescription
    
    let package = Package(
        name: "Demo",
        products: [],
        dependencies: [
            .package(url: "https://github.com/filom/ASN1Decoder.git", .upToNextMajor(from: "1.3.1"))
        ],
        targets: [
            .target(
                name: "Demo",
                dependencies: [
                    "ASN1Decoder",
                ],
                path: "Demo"
            ),
        ]
    )
    
    

    When trying to build the dependency

    $ accio update
    ...
    ✨  Building library ASN1Decoder with Carthage ...
    *** xcodebuild output can be found in /var/folders/pf/7vhqx5bn41qddypw08w9jc4w0000gn/T/carthage-xcodebuild.TzqLBH.log
    *** Skipped building ASN1Decoder due to the error:
    Dependency "ASN1Decoder" has no shared framework schemes for any of the platforms: Mac
    cp: /Users/tcurdt/Desktop/StoreKitExample/.accio/checkouts/ASN1Decoder/Carthage/Build/Mac/ASN1Decoder.framework: No such file or directory
    Error: The operation couldn’t be completed. (SwiftShell.CommandError error 0.)
    

    Running xcodebuild myself it builds just fine.

    $ xcodebuild
    ...
    CreateUniversalBinary /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework/ASN1Decoder normal armv7\ arm64 (in target: ASN1Decoder)
        cd /Users/tcurdt/Downloads/ASN1Decoder-1.3.1
        /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo -create /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/ASN1Decoder.build/Release-iphoneos/ASN1Decoder.build/Objects-normal/armv7/ASN1Decoder /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/ASN1Decoder.build/Release-iphoneos/ASN1Decoder.build/Objects-normal/arm64/ASN1Decoder -output /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework/ASN1Decoder
    
    CpHeader /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/ASN1Decoder/ASN1Decoder.h /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework/Headers/ASN1Decoder.h (in target: ASN1Decoder)
        cd /Users/tcurdt/Downloads/ASN1Decoder-1.3.1
        builtin-copy -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -exclude .hg -resolve-src-symlinks /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/ASN1Decoder/ASN1Decoder.h /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework/Headers
    
    GenerateDSYMFile /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework.dSYM /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework/ASN1Decoder (in target: ASN1Decoder)
        cd /Users/tcurdt/Downloads/ASN1Decoder-1.3.1
        /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework/ASN1Decoder -o /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework.dSYM
    
    Touch /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework (in target: ASN1Decoder)
        cd /Users/tcurdt/Downloads/ASN1Decoder-1.3.1
        /usr/bin/touch -c /Users/tcurdt/Downloads/ASN1Decoder-1.3.1/build/Release-iphoneos/ASN1Decoder.framework
    
    ** BUILD SUCCEEDED **
    

    Now I am wondering how to track this down. Is this a Carthage issue? Any pointers?

    I am using:

    $ accio version
    Version: 0.6.3
    $ carthage version
    0.33.0
    $ sw_vers
    ProductName:	Mac OS X
    ProductVersion:	10.14.6
    BuildVersion:	18G87
    
    opened by tcurdt 23
  • Pass options to Accio as comments in the Package.swift file

    Pass options to Accio as comments in the Package.swift file

    This is a working and tested implementation that solves https://github.com/JamitLabs/Accio/issues/54.

    It is using comments in the Package.swift file to pass additional configuration to Accio. I added the following keys for now:

    • product-type: default, static-framework or dynamic-framework.
    • integration-type: default (binary), source (similar to https://github.com/Carthage/Carthage#using-submodules-for-dependencies) or cocoapods.

    This PR includes parsing those options and adding them to the Framework object. It does not include the implementation for building static frameworks, neither the implementation of the source or cocoapods integration options.

    Example:

    // swift-tools-version:5.0
    import PackageDescription
    
    let package = Package(
        name: "XcodeProjectName",
        products: [],
        dependencies: [
            .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.0")),
            .package(url: "https://github.com/Flinesoft/Imperio.git", .upToNextMajor(from: "3.0.0")),
            .package(url: "https://github.com/JamitLabs/MungoHealer.git", .upToNextMajor(from: "0.3.0")),
            .package(url: "https://github.com/SwiftyBeaver/SwiftyBeaver.git", .upToNextMajor(from: "1.6.2")),
        ],
        targets: [
            .target(
                name: "AppTargetName",
                dependencies: [
                  // accio product-type:static-framework
                  "HandySwift",
                  "HandyUIKit",
                  // accio integration-type:cocoapods
                  "Imperio",
                  // accio integration-type:default
                  "MungoHealer",
                  "SwiftyBeaver",
                ],
                path: "TestProject-iOS"
            ),
        ]
    )
    

    For more information about how this works, have a look at the README.md file, or at the testValidComments() function in the ManifestCommentsHandlerServiceTests.swift file.

    opened by acecilia 11
  • Support prebuilt binaries

    Support prebuilt binaries

    There should be support to include prebuilt binaries. While the actual implementation will probably be quite straightforward, it is unclear how those binaries should best be specified in the Package.swift.

    enhancement 
    opened by fredpi 11
  • [WIP] Allow Accio dependencies to be integrated in a CocoaPods setup

    [WIP] Allow Accio dependencies to be integrated in a CocoaPods setup

    Please see the readme changes, which explains this PR.

    This is WIP. Todo: ☐ Get feedback about the concept and the implementation. ☐ Add tests.

    PD: thanks for Accio! During the past 4 months I have been dreaming about a package manager that can integrate binaries automatically in my Xcode project, doing proper version resolution. After working in the codebase for the last 3 days I can say it is exactly that :) I am very excited about the potential it has, I hope adoption happens fast!

    opened by acecilia 10
  • Pick a less generic name than `Dependencies` for your folder

    Pick a less generic name than `Dependencies` for your folder

    We've spent some time figuring out why my teammates didn't get the files that were in my Dependencies folder. Apparently the default .gitignore here on GitHub now has a specific entry for Accio which prevents anyone else from using a folder named Dependencies anywhere since it's now ignored. I am probably not the first person running into this.

    As I'm not even a user of your tool I was totally not expecting this, other tools have unique names for the folders that could/should go into .gitignore like Pods, Carthage etcetera. I would like to propose that you rename the default folder name to something unique like Accio.

    enhancement 
    opened by LucasVanDongen 9
  • Expect `Info.plist` in correct location

    Expect `Info.plist` in correct location

    According to https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html the correct location for the Info.plist is FRAMEWORK.framework/Resources/Info.plist. Yet the verification code was expecting it at FRAMEWORK.framework/Info.plist and failed the integration into the Xcode project.

    The PR adjusts the location and swift test passes. It also works in my test project. This should fix #73 and #76

    opened by tcurdt 9
  • Build error: 'Type' is only available on iOS 10.0 or newer

    Build error: 'Type' is only available on iOS 10.0 or newer

    when trying to do an install/update I am running into an error which comes up in the build logs.

    ```error: 'StringMeasurement' is only available on iOS 10.0 or newer`` the Project was set to 10.0 as minimum and even if I set it to 11 it still fails with these errors in the log file.

    help wanted question 
    opened by khoogheem 9
  • Is it possible to choose if the generated framework for a dependency is static or dynamic?

    Is it possible to choose if the generated framework for a dependency is static or dynamic?

    Hi :)

    Just discovered Accio, sounds very promising. My question is: is it possible to choose which kind of framework to generate for a dependency, dynamic or static?

    Let me add some context to the question. Recently, there is an ongoing conversation in the community about which are better: dynamic or static frameworks (see for example https://github.com/ReactiveX/RxSwift/pull/1960). Seems like static frameworks allow for faster launch times and smaller app bundles (as static linking allows to remove unused symbols). At the moment, when using Carthage, the author of the dependency is the one configuring the Xcode project and selecting how the framework is going to be generated: dynamic or static. Consumers of the dependencies have to rely on hacks in order to generate a static framework.

    As mentioned here:

    Consumer should decide how they want to consume the library not the library authors. Library authors should decide on the API and code only.

    Is this possible with Accio?

    Thanks, Andres

    enhancement 
    opened by acecilia 8
  • Re-download checkout if failing to reset

    Re-download checkout if failing to reset

    Fixes #27 using a pragmatic approach.

    As Accio currently fails to build (maybe only on my machine?) due to a build error in xcodeproj, this is not tested yet.

    opened by fredpi 8
  • Deprecate Accio in favor of SwiftPM starting with Xcode 12?

    Deprecate Accio in favor of SwiftPM starting with Xcode 12?

    With the recent developments on Swift-Evolution, I feel like there will be no gap left to fill by Accio on the move to SwiftPM anymore starting with the release of Xcode 12 which will include Swift 5.3 where all of the changes are already implemented. Namely, these things will be added:

    Therefore I would suggest that we add an info box at the top of the README.md file which points to those four proposals and mentions that we invite everyone to ask any dependencies they have included in their projects via Accio until now to open an issue for SwiftPM support starting with Swift 5.3 instead.

    We should also note that Accio will continue to work for everyone who can't move to Swift 5.3 immediately for the time being, but that we will only fix bugs for those and not add any more features as it's no longer needed.

    I'm really happy all the changes have been done so fast in the end, I was afraid that they wouldn't all be added that quickly initially, but Swift is going into the right direction in general with these changes and with their focus on more platforms, the ecosystem & more flexibility with things like an improved concurrency model. I'm really looking forward to that bright future! Let's do our part.

    Or do you guys see any ground that's not covered by SwiftPM yet which Accio could fill? CC: @fredpi @mrylmz

    question 
    opened by Jeehut 7
  • Trouble adding XcodeProj to macOS app

    Trouble adding XcodeProj to macOS app

    I'm having trouble adding XcodeProj to a new project built with Accio. The problem seems to be with PathKit.

    ✨  Building library PathKit with Carthage ...
    ⚠️  No shared scheme(s) found matching library name 'PathKit' – can't remove potentially unnecessary shared schemes, keeping all
    *** xcodebuild output can be found in /var/folders/3g/s__pcjg96s7ghq56p393hc140000gn/T/carthage-xcodebuild.7dLiEd.log
    *** Skipped building PathKit due to the error:
    Dependency "PathKit" has no shared framework schemes for any of the platforms: Mac
    cp: /Code/Limerick/Demo/.accio/checkouts/PathKit/Carthage/Build/Mac/PathKit.framework: No such file or directory
    An error occurred: Command '/bin/bash -c "cp -R '/Code/Limerick/Demo/.accio/checkouts/PathKit/Carthage/Build/Mac/PathKit.framework' '/var/folders/3g/s__pcjg96s7ghq56p393hc140000gn/T/Accio/BuildProducts/macOS/PathKit.framework'"' returned with error code 1.
    
    bug 
    opened by samisuteria 7
Releases(0.6.6)
  • 0.6.6(Oct 22, 2020)

  • 0.6.5(Sep 11, 2019)

  • 0.6.4(Sep 1, 2019)

  • 0.6.3(Jul 12, 2019)

  • 0.6.2(Jun 20, 2019)

    Fixed

    Source code(tar.gz)
    Source code(zip)
  • 0.6.1(Apr 26, 2019)

    Added

    • Adds several popular GitHub projects for official integration support testing to the Demo project.
      PR: #10 | Author: Cihat Gündüz

    Fixed

    • Fixes an issue where two or more targets for the same platform would cause project linking issues.
      Issue: #29 | PR: #34 | Author: Murat Yilmaz
    • Fixes an issue where temporary changes to SwiftPM-only frameworks would be reset before building.
      Issue: #35 | PR: #36 | Author: Cihat Gündüz
    Source code(tar.gz)
    Source code(zip)
  • 0.6.0(Apr 19, 2019)

    Added

    • Correctly recognizes App Extensions and doesn't add build phases for them. Fixes #25.
    • Points to detailed information about conflicting name issues with SwiftPM. Fixes #26.
    • The init command now properly detects test targets and lists them as such in the created manifest file. Fixes #23.

    Changed

    • Improves reading of supported deployment targets.
    • Improves init command by treating empty manifest files like non-existing ones. Fixes #24.

    Fixed

    • Fixes an issue where Accio commands were failing when Git resets failed.
    • Fixes an issue where Accio didn't reset changed files untracked by Git.
    Source code(tar.gz)
    Source code(zip)
  • 0.5.6(Apr 9, 2019)

    Added

    • Adds support for automatically finding schemes named like 'MBProgressHUD Framework tvOS'.

    Changed

    • Some improvements that make the output information on the console more precise.

    Fixed

    • Fixes the broken cleanup command of temporary frameworks after completing install.
    • Fixes an issue with multiple targets linking a single framework with schemes named after their platforms.
    • Fixes an issue with different platform specifiers used in scheme names.
    Source code(tar.gz)
    Source code(zip)
  • 0.5.5(Apr 5, 2019)

    Changed

    • The framework copy build phase now optimizes "dirty" build timing by specifying the output files. #13

    Fixed

    • Fixes an issue where broken previous install attempt leftovers cause errors on subsequent installs. #12
    Source code(tar.gz)
    Source code(zip)
  • 0.5.4(Apr 3, 2019)

  • 0.5.3(Apr 3, 2019)

  • 0.5.2(Mar 31, 2019)

  • 0.5.1(Mar 31, 2019)

    Changed

    • Check if shared cache path is available, else add new build products to local cache.

    Fixed

    • Fixed an issue with copying unzipped cache build products back to project.
    Source code(tar.gz)
    Source code(zip)
  • 0.5.0(Mar 30, 2019)

    Added

    • Demo project for integration testing with popular Swift frameworks.

    Changed

    • Compress cached build products in a .zip file. Old style cached build products can be deleted.

    Fixed

    • Multiple issues with paths, names, symbolic links & more.
    Source code(tar.gz)
    Source code(zip)
  • 0.4.0(Mar 29, 2019)

    Added

    • Add support for test targets.
    • Sort Dependencies group alphabetically.

    Changed

    • Change structure of Dependencies folder.
    • Delete unneeded groups & references from Dependencies group.
    • Delete unneeded files & folders from Dependencies folder.
    • Only link frameworks when not already linked.
    • Unlink frameworks that are no longer included.
    • Don't save build products to local cache if shared cache is available.
    • Cleanup Accio run script phase when target gets removed.

    Fixed

    • Fix typo in local cache logging.
    • Fix missing use of Constants.xcodeDependenciesGroup & Constants.dependenciesPath.
    Source code(tar.gz)
    Source code(zip)
  • 0.3.0(Mar 26, 2019)

    Added

    • None.

    Changed

    • Add support for Swift 5 and Xcode 10.2.
    • Separate cached frameworks by Swift tools version.

    Deprecated

    • None.

    Removed

    • Drop support for Swift 4.2 and Xcode <=10.1.

    Fixed

    • None.

    Security

    • None.
    Source code(tar.gz)
    Source code(zip)
Owner
Jamit Labs
Software development team with focus on iOS, Android & Ruby on Rails
Jamit Labs
A simple, decentralized dependency manager for Cocoa

Carthage Carthage is intended to be the simplest way to add frameworks to your Cocoa application. Carthage builds your dependencies and provides you w

Carthage 14.7k Jan 7, 2023
The Cocoa Dependency Manager.

CocoaPods: The Cocoa dependency manager CocoaPods manages dependencies for your Xcode projects. You specify the dependencies for your project in a sim

null 13.9k Jan 8, 2023
🚀 Create XCFrameworks with ease! A Command Line Tool to create XCFramework for multiple platforms at one shot! The better way to deal with XCFrameworks for iOS, Mac Catalyst, tvOS, macOS, and watchOS.

Surmagic ?? Create XCFramework with ease! A Command Line Tool to create XCFramework for multiple platforms at one shot! The better way to deal with XC

Muhammed Gurhan Yerlikaya 260 Dec 28, 2022
Go Flashcards for iOS and WatchOS - Official repository

Go Flashcards for iOS and WatchOS Go Flashcards for iOS and WatchOS is an application that allows users to create stacks of flashcards and review them

Roy 60 Dec 8, 2022
🙏 Support your favourite open source projects

'Spasibo' means 'thank you' in Russian. Spasibo is a simple command-line tool to supporting open-source frameworks. Features Based on Github Sponsors

Artem Novichkov 77 Dec 8, 2022
A package manager that installs and runs executable Swift packages

Mint ?? A package manager that installs and runs Swift command line tool packages. $ mint run realm/[email protected] This would install and run SwiftL

Yonas Kolb 2k Jan 7, 2023
The Package Manager for the Swift Programming Language

Swift Package Manager Project The Swift Package Manager is a tool for managing distribution of source code, aimed at making it easy to share your code

Apple 9.1k Dec 29, 2022
Swift Modules, a swift module (or package) manager

Swift Modules The Swift Modules manager similar to the JavaScript world's npm and bower

Jan Kuča 60 Jun 3, 2021
Awesome-ios-app - Suitable for beginners iOS development small app

awesome-ios-app Suitable for beginners iOS development small app. Table of Conte

Ryan 1 Feb 11, 2022
A template for new Swift iOS / macOS / tvOS / watchOS Framework project ready with travis-ci, cocoapods, Carthage, SwiftPM and a Readme file

Swift Framework Template A template for new Swift Framework. What's in the template? Deployment Targets - iOS 9.0 / Mac OS X 10.10 / tvOS 9.0 / watchO

Rahul Katariya 529 Jun 27, 2022
A set of libraries used for parsing representations of Swift Packages similar to how SwiftPM itself works

A set of libraries used for parsing representations of Swift Packages similar to how SwiftPM itself works, but also supporting Xcode specific features (such as Swift Playground Apps).

Liam Nichols 0 Jan 8, 2022
Simple Swift wrapper for Keychain that works on iOS, watchOS, tvOS and macOS.

KeychainAccess KeychainAccess is a simple Swift wrapper for Keychain that works on iOS and OS X. Makes using Keychain APIs extremely easy and much mor

Kishikawa Katsumi 7.2k Dec 30, 2022
Simple Swift wrapper for Keychain that works on iOS, watchOS, tvOS and macOS.

KeychainAccess KeychainAccess is a simple Swift wrapper for Keychain that works on iOS and OS X. Makes using Keychain APIs extremely easy and much mor

Kishikawa Katsumi 7.2k Jan 5, 2023
🌏 A zero-dependency networking solution for building modern and secure iOS, watchOS, macOS and tvOS applications.

A zero-dependency networking solution for building modern and secure iOS, watchOS, macOS and tvOS applications. ?? TermiNetwork was tested in a produc

Bill Panagiotopoulos 90 Dec 17, 2022
gradle plugin for building Xcode Projects for iOS, watchOS, macOS or tvOS

gradle-xcodePlugin The gradle xcode plugin (gxp) makes it easier to build Xcode projects by specifying the build settings in a single configuration fi

null 444 Dec 5, 2022
A simple - no dependency Swift script that chases your mouse on MacOS (works for Monterey)

tom A simple - no dependency Swift script that chases your mouse on MacOS (works for Monterey) What it does? Keep the display on and move your mouse u

Viet Hung Nguyen 1 Jun 7, 2022
Socket framework for Swift using the Swift Package Manager. Works on iOS, macOS, and Linux.

BlueSocket Socket framework for Swift using the Swift Package Manager. Works on iOS, macOS, and Linux. Prerequisites Swift Swift Open Source swift-4.0

Kitura 1.3k Jan 3, 2023
RSA public/private key encryption, private key signing and public key verification in Swift using the Swift Package Manager. Works on iOS, macOS, and Linux (work in progress).

BlueRSA Swift cross-platform RSA wrapper library for RSA encryption and signing. Works on supported Apple platforms (using Security framework). Linux

Kitura 122 Dec 16, 2022
RSA public/private key encryption, private key signing and public key verification in Swift using the Swift Package Manager. Works on iOS, macOS, and Linux (work in progress).

BlueRSA Swift cross-platform RSA wrapper library for RSA encryption and signing. Works on supported Apple platforms (using Security framework). Linux

Kitura 122 Dec 16, 2022
Socket framework for Swift using the Swift Package Manager. Works on iOS, macOS, and Linux.

BlueSocket Socket framework for Swift using the Swift Package Manager. Works on iOS, macOS, and Linux. Prerequisites Swift Swift Open Source swift-5.1

Kitura 1.3k Dec 26, 2022