![]() Adding remote dependenciesīesides facilitating the creation of packages, one of the Swift Package Manager’s core use cases is enabling remote dependencies - such as third party libraries - to be added to a project. can be overridden by passing additional parameters to the APIs used above. That behavior, along with other defaults - such as build settings, target platforms, etc. The swift-tools-version comment at the top of the file isn’t just a comment, it also tells the Swift Package Manager what version of the Swift toolchain to use when building our package.īy default, the Swift Package Manager will match the names of the targets defined within our manifest file with corresponding folders on disk in order to determine what Swift files that belong to each target. Our package contains two targets, one for our library library that has the same name as the package itself: The external product of our package is an importable In Xcode 11, we can also perform the above setup using the File > New > Swift Package menu command.īy doing the above, the Swift Package Manager will now have created an initial structure for our new package - which includes a Package.swift manifest file that looks something like this: // swift-tools-version:5.1 import PackageDescription To get started, we’ll create a new folder (with a name that matches what we want our package to be called), and we’ll then run swift package init within it to create our package: $ mkdir TodoKit Rather than using a data format, like JSON or XML, Swift package manifest files are written using actual Swift code - with a Package instance representing the declaration of the package.Īs an example, let’s say that we’re working on a todo list app, and that we want to create a TodoKit package for all of our core logic that’s shared across the app - including things like our database layer, our model code, and so on. The contents of a package is declared using a Package.swift manifest file, which is placed in the root directory of each package. Packages can either be public libraries that are shared using services like GitHub, or internal tools and frameworks that are only shared within a small number of projects. The anatomy of a Swift packageĪ Swift Package is essentially a group of Swift source files that are compiled together to form a Module - which can then be shared and imported into other projects as one unit. However, while the server-side Swift community quickly embraced the Swift Package Manager as the go-to tool for managing dependencies when building server applications, it’s taken quite a while for it to become fully integrated into the rest of Apple’s developer toolchains.īut now, starting with Xcode 11, the Swift Package Manager is finally becoming a true first class citizen within Apple’s suite of developer tools - so this week, let’s take a look at how it can be used to manage a project’s various dependencies - both internal and external ones. ![]() While it wasn’t the first dependency manager for Swift projects, it was the first that was officially provided and supported by Apple, which many developers saw as really good news. ![]() When Swift was open sourced at the end of 2015, one of the most surprising and interesting new projects that was introduced along with it, was the Swift Package Manager.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |