The Package Manager for the Swift Programming Language

Overview

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 and reuse others’ code. The tool directly addresses the challenges of compiling and linking Swift packages, managing dependencies, versioning, and supporting flexible distribution and collaboration models.

We’ve designed the system to make it easy to share packages on services like GitHub, but packages are also great for private personal development, sharing code within a team, or at any other granularity.

Swift Package Manager includes a build system that can build for macOS and Linux. Starting with Xcode 11, Xcode integrates with libSwiftPM to provide support for iOS, watchOS, and tvOS platforms.

The SourceKit-LSP project leverages libSwiftPM and provides Language Server Protocol implementation for editors that support LSP.


Table of Contents


Getting Started

Please use this guide for learning package manager basics.


Documentation

For Quick Help use the swift package --help command.

For extensive documentation on using Swift Package Manager, creating packages, and more, see Documentation.

For additional documentation on developing the Swift Package Manager itself, see Documentation/Contributing.

For detailed documentation on the package manifest API, see PackageDescription API.

For release notes with information about changes between versions, see Release Notes.


System Requirements

The package manager’s system requirements are the same as those for Swift with the caveat that the package manager requires Git at runtime as well as build-time.


Installation

The Swift Package Manager is included in Xcode 8.0 and all subsequent releases.

The package manager is also available for other platforms as part of all Snapshots available at swift.org, including snapshots for the latest versions built from master. For installation instructions for downloaded snapshots, please see the Getting Started section of swift.org.

You can verify your installation by typing swift package --version in a terminal:

$ swift package --version
Apple Swift Package Manager - ...

Managing Swift Environments

On macOS /usr/bin/swift is just a stub that forwards invocations to the active toolchain. Thus when you call swift build it will use the swift defined by your TOOLCHAINS environment variable. This can be used to easily switch between the default tools, and a development snapshot:

$ xcrun --find swift
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift
$ swift --version
Apple Swift version 3.0
$ export TOOLCHAINS=swift
$ xcrun --find swift
/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin/swift
$ swift --version
Swift version 3.0-dev

To use a specific toolchain you can set TOOLCHAINS to the CFBundleIdentifier in an .xctoolchain’s Info.plist.

Choosing a Swift Version

The SWIFT_EXEC environment variable specifies the swiftc executable path used by swift package. If it is not set, the package manager will try to locate it:

  1. In swift-package's parent directory.
  2. On macOS, by calling xcrun --find swiftc.
  3. By searching the PATH.

Support

If you have any trouble with the package manager, help is available. We recommend:

When adding a bug to the tracker you should follow the bug reporting guidelines, they can be found in Resources.md.

If you’re not comfortable sharing your question with the list, contact details for the code owners can be found in CODEOWNERS; however, the mailing list is usually the best place to go for help.


Contributions

There are several ways to contribute to Swift Package Manager. To learn about the policies, best practices that govern contributions to the Swift project and instructions for setting up the development environment please read the Contributor Guide.

The Swift package manager uses llbuild as the underlying build system for compiling source files. It is also open source and part of the Swift project.


License

Copyright 2015 - 2020 Apple Inc. and the Swift project authors. Licensed under Apache License v2.0 with Runtime Library Exception.

See https://swift.org/LICENSE.txt for license information.

See https://swift.org/CONTRIBUTORS.txt for Swift project authors.

Comments
  • Improve `Destination.sdkPlatformFrameworkPaths()`

    Improve `Destination.sdkPlatformFrameworkPaths()`

    We should not ignore errors or an empty SDK platform path since that means XCTest imports and test execution might silently fail on macOS with no indication to what the problem is.

    opened by neonichu 124
  • [SE-0301] Package Editor Commands Implementation

    [SE-0301] Package Editor Commands Implementation

    This PR:

    • Updates the SPMPackageEditor library so it compiles against ToT SwiftSyntax
    • Removes spm-manifest-tool, instead conditionally compiling package editor functionality into the Commands module
    • Refactors the library a bit to fix some bugs and make it more extensible
    • adds support for adding products

    Possible future directions (not in this PR):

    • deleting products/targets/dependencies
    • a swift package upgrade command that could update requirement specs
    • Use the PackageSyntax infra to emit manifest-related diagnostics with source locations
    opened by owenv 74
  • [PackageLoading] Improve flexibility in formatting Package manifests and correctness in parsing Swift tools version specifications

    [PackageLoading] Improve flexibility in formatting Package manifests and correctness in parsing Swift tools version specifications

    ORIGINAL DESCRIPTION

    SR-13566

    This pull request changes the regex pattern on line 181 of swift-package-manager/Sources/PackageLoading/ToolsVersionLoader.swift to allow any combination of horizontal whitespace characters between "//" and "swift-tools-version" in the swift tools version specification in Package.swift

    The old regex pattern is ^// swift-tools-version:(.*?)(?:;.*|$)

    The new regex pattern is ^//\h*?swift-tools-version:(.*?)(?:;.*|$)


    NEW DESCRIPTION (2020-11-04)

    This PR proposes the following changes to the parsing of the Package manifest and its Swift tools version specification, starting from Swift Next (assumed to be Swift 5.4):

    • Allow leading (any combination of all) whitespace characters in the Package manifest, instead of just line feed characters (U+000A).

      Rationale: This allows SwiftPM to skip all initial whitespace-only lines (if any) when looking for the Swift tools version specification, eliminating a common source of bug for Swift packages. Additionally, this allows SwiftPM to recognise all Unicode line terminators, because all of them are whitespace characters.

    • Allow any combination of all horizontal whitespace characters¹ immediately after the comment marker (//) in the Swift tools version specification, instead of just a single space (U+0020).

      Rationale: Sometimes a user may prefer to follow the comment marker with a character tabulation (U+0009) or 2 space characters, or some other horizontal whitespace characters, in order to line up developer (//) and documentation (///) comments throughout the source files. For example:

      //  This is a demonstration of how comments may be lined up.
      /// A struct that represents nothing.
      struct Foo {}
      
    • Allow any combination of all horizontal whitespace characters immediately before the version specifier in the Swift tools version specification.

      Rationale: This mirrors the most common style of type declaration in Swift sources. For example,

      let foo: Foo
      
    • Recognise all Unicode line terminators instead of just line feed (U+000A) in the Package manifest up to the line terminator that immediately follows the Swift tools version specification line².

      Rationale: With Swift becoming supported on more and more platforms (many of them Unix-unlike or POSIX-incompliant), SwiftPM will see more and more Package manifests that use line terminators other than line feed. Further, even though many systems are not yet supported, Swift source files can still be edited on them, and many IDEs/editors silently changes the line terminators to the platforms' native ones when saving the edited files. SwiftPM needs to recognise all possible line terminators³ before it becomes a problem

    • End the silent fallback to using Swift 3.1 as the lowest supported version. This used to happen when the Swift tools version specification is malformed AND SwiftPM couldn't find either swift-tool or tool-version in the specification.

      Rationale: It is actively harmful to hide this behaviour from the user. It is also actively harmful to decide on a Swift version without user consent. With source breaks from past Swift releases accumulated, this could result in unexpected behaviour in Swift packages. This behaviour was originally intended to peacefully accept Swift packages created before the Swift tools version specification was required. However, this purpose has become outdated.

    Additional user-facing changes as the result of implementing the changes above:

    • If the manifest has a formatting error, SwiftPM now identifies more accurately where the error is, and provides to the user a more detailed description/explanation and a suggestion tailored for each error.

    • SwiftPM now throws an error if the manifest is not properly encoded in UTF-8.

    Additional SwiftPM client-facing changes as the result of implementing the changes above:

    • ToolsVersionLoader.Error.malformedToolsVersion(specifier: String, currentToolsVersion: ToolsVersion) is replaced by more granular error cases.

    • ToolsVersionLoader.split(_ bytes: ByteString) -> (versionSpecifier: String?, rest: [UInt8]) and ToolsVersionLoader.regex are replaced by the Substring-oriented ToolsVersionLoader.split(_ manifest: String) -> ManifestComponents.

    ¹ Whitespace characters consists of horizontal and vertical whitespace characters. No whitespace character can be both horizontal and vertical. All vertical whitespace characters are line terminators, and vice versa. In the PR's implementation, horizontal whitespace characters are not identified directly, but through the process of elimination: All line terminators are "stripped" from the manifest first, then the horizontal whitespace characters are identified by being whitespace characters.

    ² Everything after the Swift tools version specification, such as the initilisation of the Package instance, is handled by the Swift compiler's lexer. It's beyond the power of ToolsVersionLoader and SwiftPM's manifest-loading in general.

    ³ Only Unicode line terminators are recognised, so line terminators in some other encodings such as EBCDIC are not recognised. This is fine because if a Package manifest isn't encoded in UTF-8, then it's already entirely unreadable by SwiftPM.

    opened by WowbaggersLiquidLunch 63
  • Initial implementation of Command Plugins

    Initial implementation of Command Plugins

    Initial implementation of https://forums.swift.org/t/pitch-package-manager-command-plugins/53172.

    This feature is experimental until approved, so it requires a tools version of 999.0 in the package that declares the command plugin, and requires SWIFTPM_ENABLE_COMMAND_PLUGINS to be set to 1 in the environment when invoked.

    This implementation temporarily uses a swift package plugin <verb> form for invoking command plugins. Per the pitch and proposal, plugin-defined commands are intended to be invocable using the shortcut swift package <verb> when the feature is complete (there is discussion of even supporting swift <verb> but that is not part of the current proposal).

    Motivation:

    Implementation of a new feature being pitched, kept under a feature flag until the proposal is accepted.

    Staging:

    This feature is being developed incrementally across this PR and follow-on PRs. This PR it is in a state where it could be merged to get most of the functionality into the mainline (behind the feature flag), including all the planned changes to PackageDescription and PackagePlugin. Remaining items of the full feature would then be landed in future PRs. The SWIFTPM_ENABLE_COMMAND_PLUGINS guard flag will only be removed once the evolution proposal has been approved and the feature has been fully implemented including any amendments.

    Modifications:

    • add the new enum cases for the command plugin capability to PackageDescription
    • add serialization of those cases in PackageDescriptionSerializer
    • deserialize them in the ManifestJSONLoader and add to the package model
    • add manifest source generation for the command capability
    • add ability to describe packages that have command plugins
    • add a unit test to check loading a manifest with a command capability
    • add protocol declarations for command plugin entry point in the plugin API
    • ability to invoke the command plugin in libSwiftPM and unit tests
    • add a unit test to check round trip calling into the plugin
    • add ability to invoke the command plugin from CLI
    • made the host-to-plugin communication be bidirectional and interactive
    • ability for plugin to call back into SwiftPM for services
    • ability to create symbol graphs for a target when a plugin requests it
    • ability to run a build when the plugin requests it

    Remaining in upcoming PRs:

    • request approval to run command plugins that need special permissions
    • implement the option to list the available command plugins
    • support qualifiers for ambiguous plugin commands
    • ability to run a test when the plugin requests it
    • build any executables needed by command plugins before invoking the plugin
    • provide access to toolchain executables in the map sent to plugins
    • add async to all the plugin APIs (in separate PR, depends on back deployment)
    opened by abertelrud 50
  • [SR-12851] System-wide cache of SwiftPM dependencies

    [SR-12851] System-wide cache of SwiftPM dependencies

    I reworked my approach from PR #2835 to not only operate on GitRepository but on any kind of repository from within Repository Manager.

    SR-12851

    This PR requires the Lock Improvements in swift-tools-support-core to be merged.

    opened by tgymnich 47
  • Bootstrap script needs to build PackageDescription and PackagePlugin universal

    Bootstrap script needs to build PackageDescription and PackagePlugin universal

    The bootstrap script needs to build the PackageDescription and PackagePlugin runtime support libraries universal when cross-compiling. This PR builds on https://github.com/apple/swift-package-manager/pull/3464, so it will be easier to review that PR first.

    Motivation

    Even when invoking the bootstrap script with flags to build universal for macOS x86_64 and arm64, the PackageDescription and PackagePlugin libraries ended up single-architecture. This is because the bootstrap script copied them from the CMake-built artifacts instead of the swiftpm-built artifacts.

    PR https://github.com/apple/swift-package-manager/pull/3464 resolves the complication of PackageDescription having both a 4.0 and a 4.2 variant.

    Modifications:

    • in the bootstrap script, build SwiftPM so that Swift interface files are emitted
    • consolidate some of the bootstrap script logic for installing dynamic libraries and their companion modules

    rdar://75186958

    opened by abertelrud 45
  • Android: add cross-compilation configuration file flag

    Android: add cross-compilation configuration file flag

    Motivation:

    This enables cross-compiling SPM for other hosts, such as Android.

    Modifications:

    In addition to --cross-compile-hosts, add a new bootstrap flag, --cross-compile-config, that will pass in a JSON file with the destination cross-compilation flags.

    Result:

    SPM can be cross-compiled for another OS, with Android as the first example.

    opened by buttaface 45
  • Verify that only targets that are manifest dependencies can be imported.

    Verify that only targets that are manifest dependencies can be imported.

    This change introduces a build verification step that attempts to detect scenarios where a target contains an import of another target in the package without declaring the imported target as a dependency in the manifest. This is done via SwiftDriver's import-prescan capability which relies on libSwiftScan to quickly parse a target's sources and identify all imported modules.

    opened by artemcm 44
  • Package version data

    Package version data

    Work in Progress This is initial commit for SR-473

    We need to generate version data for every package on build. Now it creates a new folder versionData inside .build dir and creates a swift file for every package.

    Could you please provide any feedback for the initial implementation.

    • Should these files be inside .build dir or somewhere else?
    • Should we generate a new .swift file for every Package or place all data in 1 file?
    • Any other suggestion?

    ToDo:

    • [x] Add unit test
    • [x] Add better error handling
    • [x] Merge PR #225
    • [x] add additional information to Root package (local changes)
    opened by kostiakoval 43
  • [SR-40] Port Swift to Linux on Raspberry Pi

    [SR-40] Port Swift to Linux on Raspberry Pi

    | | | |------------------|-----------------| |Previous ID | SR-40 | |Radar | None | |Original Reporter | @gribozavr | |Type | New Feature | |Status | Resolved | |Resolution | Done |

    Attachment: Download

    Additional Detail from JIRA

    | | | |------------------|-----------------| |Votes | 24 | |Component/s | Compiler, Foundation, Package Manager, Standard Library, XCTest | |Labels | New Feature, NewPortRequest, arm | |Assignee | @hpux735 | |Priority | Medium |

    md5: 7062026e0685ad58b94ffcbb4be1f47b

    Sub-Tasks:

    • SR-387 Undef. symbols when linking SwiftPM
    • SR-359 Undef. symbols when linking to Foundation (ARM)

    Issue Description:

    It would be good to get Swift compiler running on Raspberry Pi, as well as having a cross-compiler from x86 to Raspberry Pi.

    enhancement 
    opened by gribozavr 42
  • Finish SE‐0226 (Ignore Unused Products)

    Finish SE‐0226 (Ignore Unused Products)

    This pull request should complete the implementation of SE‐0226: Package Manager Target Based Dependency Resolution. @hartbit already taught the resolver to only care about products in #2424. This takes that work further so that the resolver only cares about products that are actually used.

    This pull request is sizeable, so I’ll elaborate the main points here.

    The changes broadly fall into four groups:

    1. The manifest is now able to compute the downward‐facing products required for any upward‐facing product set. This is mostly housed in PackageModel/Manifest.swift, and boils down to turning @hartbit’s allRequiredDependencies into dependenciesRequired(for:), along with the input type ProductFilter.

    2. The resolver now operates on abstract nodes. See DependencyResolutionNode for the nitty‐gritty details. Essentially, it resolves individual products instead of whole packages. The new node type has simply been slotted in to replace the PackageReferences that were in use before. None of @kiliankoe’s Pubgrub decision making processes has been changed in any way. The diagnostics have also been left alone except for the inclusion of the specific product alongside the package name where relevant.

    3. Dozens of new method parameters and instance properties have been added to various types and methods in order to pass the new information along from where it originates to where it is needed. Unfortunately, this affects a whole swath of things across the PackageModel, PackageLoading, PackageGraph, Workspace, Commands and SPMTestSupport modules, but all of these changes are straightforward.

    4. Many tests required fixing. Most of them merely needed to provide the new parameters required in order to satisfy the new API. Several were expecting failures that were no longer reachable, and needed dependencies to be made explicit so that the resolver would even enter the code branch in question. All but three are straightforward. (See below.)


    While I was working through the tests, three things came up which need a closer look. They are tests that expected behaviour at least partially at odds with SE‐0226.

    1. The test suite expected unreachable executable products to be available. swift run dependency‐executable is apparently supposed to work, even if no dependency is declared on that product. I can see how that could be useful, and it wouldn’t surprise me if users are taking advantage of it in their workflows. But SE‐0226 says this:

      Another example of packages requiring additional dependencies is for sample code targets. A library package may want to create an executable target which demonstrates some functionality of the library. This executable may require other dependencies such as a command-line argument parser.

      So including such executables would undermine one of the motivating use cases for SE‐0226. As such, what I have implemented right now does not resolve such executables by default.

      However, as a compromise to maintain backwards compatibility, I have channeled the argument provided to any swift run invocation through to the resolver, so that if you explicitly ask to run an executable of an immediate dependency, you will still be able to. Since it has some minor drawbacks, I consider this an interim solution. This implementation will suffice for now, but a separate evolution proposal should probably be made to design something better if we want to continue supporting this long‐term. See the Fix‐Me in the initializer for PackageGraphRoot for more details.

    2. The test suite expected unreachable targets to be available to a swift build --target dependency‐target invocation. Since there is no infrastructure in the resolver to handle targets, there is no easy way to locate or load such a target. Since it seems backwards to SE‐0226 and has no practical use I can think of, I simply removed the test.

    3. The test suite expected legacy system packages to work without an explicit target dependency declaration. Such packages have been triggering a deprecation warning since Swift 4.2. Continuing to support them implicitly is problematic, because there is no way to know if that’s what a package is until after fetching and loading it, so it would defeat the whole of SE‐0226.

      As a compromise to maintain as much backwards compatibility as possible, I have taught the manifest loader to internally convert such a package into a modern‐style one with a system target and product, which inherit the package’s name and details. This allows the current toolchain to still use such dependencies by referencing the synthesized product. However, if the client package wants to support both old and new toolchains at once (such as 5.1 and 5.4), it will have to make use of #if compiler, because the old toolchain will be unable to locate the declared product, whereas the new toolchain will not resolve an undeclared product.

    opened by SDGGiesbrecht 40
  • build: bring CMake build up to date

    build: bring CMake build up to date

    Add CMake based build support for the missing components as the Windows build depends on this still. This allows us to work towards enabling the swift package collection and registry functionality.

    opened by compnerd 2
  • Enable target with headers but no sources as `ClangTarget`

    Enable target with headers but no sources as `ClangTarget`

    This PR change allows the generation of targets containing only header files.

    Motivation:

    Closes https://github.com/apple/swift-package-manager/issues/4806 . Currently, if we attempt to create a target that does not contain source files, the Swift Package Manager returns an error and prompts us to put the source files. Therefore, it is not possible to create a CLangTarget that only contains header files.

    Modifications:

    Changed so that if a header file exists, the Target generation process continues even if no source file exists.

    Result:

    With the changes in this PR, a target that does not contain source files but does contain headers is a CLangTarget.

    opened by k-kohey 1
  • XcodeTarget dependencies is always an empty list

    XcodeTarget dependencies is always an empty list

    Description

    Make a tool aan print the xcodetarget dependencies. This is always an empty list.

    Expected behavior

    To list the dependencies as the doc describes

    Actual behavior

    empty list

    Steps to reproduce

    see description

    Swift Package Manager version/commit hash

    with xcode 14

    Swift & OS version (output of swift --version && uname -a)

    swift-driver version: 1.62.15 Apple Swift version 5.7.1 (swiftlang-5.7.1.135.3 clang-1400.0.29.51) Target: arm64-apple-macosx13.0 Darwin MacBook-Pro-3.lan 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000 arm64

    bug 
    opened by doozMen 1
  • Binary target that does not support linux still builds

    Binary target that does not support linux still builds

    Description

    This relates to discussion about AirbnbSwift Where it was confirmed that the swift package index does not detect incompatible libraries because they build per platform, but as described the build does not fail.

    The workaround for now seams to be to add an error the Package.swift, which seams not the way to go :).

    Expected behavior

    Do not build of binary target does not build for the platform you are building for. This can easily be derived from the json of the binary.

    Actual behavior

    It just builds but crashes when run before an executable actually starts.

    Steps to reproduce

    See discussion https://github.com/airbnb/swift/discussions/197 & https://github.com/SwiftPackageIndex/SwiftPackageIndex-Server/issues/2116

    Swift Package Manager version/commit hash

    the one that ships with xcode 14 and above

    Swift & OS version (output of swift --version && uname -a)

    swift-driver version: 1.62.15 Apple Swift version 5.7.1 (swiftlang-5.7.1.135.3 clang-1400.0.29.51) Target: arm64-apple-macosx13.0 Darwin MacBook-Pro-3.lan 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000 arm64

    enhancement 
    opened by doozMen 1
Releases(0.6.0)
Owner
Apple
Apple
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
A dependency manager driven by SwiftPM that works for iOS/tvOS/watchOS/macOS projects.

Installation • Usage • Supporting Accio • Contributing • License ⚠️ Deprecation Notice ⚠️ With the release of Xcode 12 which includes Swift 5.3, we fe

Jamit Labs 647 Dec 25, 2022
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
JKUI - a package included in this project that provides UIComponents

JKUI JKUI is a package included in this project that provides UIComponents. Befo

Juan Vasquez 2 Feb 11, 2022
Gradle plugin for managing Swift by enhancing Carthage with Maven repository

Works presents Athena Preface As a mobile application engineer that develops iOS and Android applications, I found that in Android, dependencies can b

Yunarta Kartawahyudi 1 Nov 3, 2020
NFCMate - A NFC Companion built using Swift with CoreNFC Framework

NFCMate NFCMate NFCMate is a NFC app written in Swift for iOS devices. Moreover,

Navemics 7 Nov 21, 2022
Helping you find inner peace when comparing version numbers in Swift

Helping you find inner peace when comparing version numbers in Swift. Comparing with the current applications version couldn't be easier. // App.versi

Christoffer Winterkvist 207 Jun 29, 2022
A framework for writing terminal applications in Swift.

Ashen A framework for writing terminal applications in Swift. Based on The Elm Architecture. As a tutorial of Ashen, let's consider an application tha

Colin T.A. Gray 79 Dec 5, 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
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 Jan 5, 2023
A repository for showcasing my knowledge of the Swift programming language, and continuing to learn the language.

Learning Swift (programming language) I know very little about programming in the Swift programming language. This document will go over all my knowle

Sean P. Myrick V19.1.7.2 2 Nov 8, 2022
A repository for showcasing my knowledge of the Objective-C++ programming language, and continuing to learn the language.

Learning Objective-C-Plus-Plus I hardly know anything about the Objective-C++ programming language. This document will go over all of my knowledge of

Sean P. Myrick V19.1.7.2 3 Nov 8, 2022
A repository for showcasing my knowledge of the Objective-C programming language, and continuing to learn the language.

Learning Objective-C I hardly know anything about the Objective-C programming language. This document will go over all of my knowledge of the Objectiv

Sean P. Myrick V19.1.7.2 3 Nov 8, 2022
Swift-extensions - Swift package extending the Swift programming language.

swift-extensions A package containing extensions for the Swift programming language. Contribution Reporting a bug If you find a bug, please open a bug

Alexandre H. Saad 2 Jun 12, 2022
Numerals is a package containing additional numeric types for the Swift programming language.

swift-numerals Numerals is a package containing additional numeric types for the Swift programming language. Contents The package currently provides t

Alexandre H. Saad 0 Jul 28, 2022
Swift Package Manager plugin which runs ActionBuilder to create a Github Actions workflow for a swift package.

ActionBuilderPlugin A Swift Package Manager command which builds a Github Actions workflow for the current package. By default the workflow file will

Elegant Chaos 4 Jul 20, 2022
Explanations and samples about the Swift programming language

About Swift Contents Explanations and samples about: Swift Programming Language Swift Standard Library Target audience Developers familiar with object

Nicola Lancellotti - About 74 Dec 29, 2022
Emacs support for Apple's Swift programming language.

swift-mode Major-mode for Apple's Swift programming language. Installation Install swift-mode package from MELPA. To install without MELPA, download l

null 347 Dec 17, 2022
Tiny http server engine written in Swift programming language.

What is Swifter? Tiny http server engine written in Swift programming language. Branches * stable - lands on CocoaPods and others. Supports the latest

null 3.6k Jan 3, 2023