MAmaguszin·Oct 15, 2025Submission
1 points · Open discussionswiftlang
swift-package-manager
Swift2015–2025
swiftlang / swift-package-manager
swift-package-manager
The Package Manager for the Swift Programming Language
17Distinct people
19Mentions
0Explicit recommenders
10.3KGitHub stars
What to know before exploring
What it is
The Package Manager for the Swift Programming Language
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year19 dated mentions
Observed mentions: 2015-12-03 16:50:44 UTC to 2025-10-15 22:43:32 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 9 | 4 | 5 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
19 sourcesYou can install a Swift toolchain on macOS without Xcode, but Xcode is the “blessed” route and listed first on the swift.org getting started instructions.
https://www.swift.org/install/macos
However, it can be a bumpy ride. For example: “swift test” (via the CLI) doesn’t work if Xcode is not installed.
https://github.com/swiftlang/swift-package-manager/issues/43...
I would just emphasise that the OP was about _convenience_ and Swift-without-Xcode on macOS is not smooth sailing.
In Swift is a more convenient RustAccording to their changelog[0], Clock was added to the standard library with Swift 5.7, which shipped in 2022, at the same time as iOS 16. It looks like static linking by default was approved[1] but development stalled[2].
I expect that it's as simple as that: It's supported on iOS 16+ because it's dynamically linked by default, against a system-wide version of the standard library. You can probably try to statically link newer versions on old OS versions, or maybe ship a newer version of the standard library and dynamically link against that, but I have no idea how well those paths are supported.
0. https://github.com/apple/swift/blob/main/CHANGELOG.md
1. https://github.com/apple/swift-evolution/blob/main/proposals...
2. https://github.com/apple/swift-package-manager/pull/3905
In Swift's native Clocks are inefficient> It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax.
I just want to point out that the Swift package management situation is currently bad. SPM (https://github.com/apple/swift-package-manager) can't be used within Xcode, and is basically not used for anything outside of server-side swift / Linux.
It also doesn't look like SPM will be integrated with Xcode this WWDC, so you're stuck with CocoaPods or Carthage.
I'm really jealous of cargo. And RLS (Swift LSP doesn't really work well because it doesn't know about your dependencies - back to the package manager issue).
In Four Years of RustWell, he did join and then leave Apple. If there's ever a Quora answer about that, I'll gladly read it :)
https://github.com/apple/swift-package-manager/commits/2e8db...
(Huge Homebrew fan here! Good API design is such an underappreciated skill.)
In Max Howell, author of Homebrew, on being rejected for a job at Google> Developers: less dependencies is better, especially when they're so simple!
No! The opposite of that. Lots of little µframeworks, defining composable and generic types, is much better than a giant monolith.
The Swift Package Manager is taking this approach, and I think it's great: https://github.com/apple/swift-package-manager#modules
The caret character doesn't appear anywhere in the semver spec, so whatever that does, it's non-standard: http://semver.org/
If your modules are small and well-defined, they probably won't need many versions anyways - they might just stay on 1.0.x forever. If you want to do something different, it might make more sense to just write another module.
In I've Just Liberated My ModulesIt's probably worth pointing out here that Apple is currently working on a package manager (https://github.com/apple/swift-package-manager).
In CocoaPods downloads max out five GitHub server CPUsCocoaPods exists because developers want to learn how to "build apps" but lack the resources to intelligently include and link to 3rd party code in their projects. CocoaPods doesn't enable anything not otherwise configurable via git submodules and Xcode project hierarchies / build settings.
Therefore, it's not Apple's problem. In fact, I've talked to a non-trivial amount of engineers (both in Cupertino and long time Cocoa devs) that disapprove of the shortcuts that Cocoapods takes all over, software architecture be damned. Reasonable parties can agree to disagree, but I do include 3rd party framework inclusion without a dependency manager as an interview screen for prospective iOS hires.
Since you mention developer relations, I'll assume you're not actually arguing that this is Apple's technical responsibility, but that they should throw
Read the rest
around some $ to grease the wheels to make dependency inclusion better. As a platform vendor, funding hosting costs for some project that you don't agree with just to "support the community" is a bad idea. Better idea is to allocate resources to setup a structure that can fix the issue in a technically agreeable way while also benefitting from the independence a FOSS project provides. In doing so, you are correct that it'd be preferable for Apple to fund/use well-known FOSS standards, such as Github.
In conclusion, Apple should setup a FOSS project to address the current inconveniences associated with third party package inclusion and should involve and pay Github somehow.
Oh wait...https://github.com/apple/swift-package-manager
Swift Package Manager will also have a centralised package index in the future, here's a quote from their [package manager proposal][1]:
> We would like to provide a package index in the future, and are investigating possible solutions.
[1]: https://github.com/apple/swift-package-manager/blob/master/D...
In CocoaPods downloads max out five GitHub server CPUsAnd https://github.com/apple/swift-package-manager once it's ready, which is similar to Carthage in structure (decentralized!).
In CocoaPods downloads max out five GitHub server CPUsAttempting to get a job at 1 of the Google/Apple/Facebook/Amazon/Microsoft quintet of big companies that pay well, though, is quite doable, in spite of the noisiness of the process. mxcl got a job at Apple (working on Swift's package manager, no less[0]) a short while later.
[0]: https://github.com/apple/swift-package-manager/graphs/contri...
In Big Company vs. Startup Work and CompensationI was really excited to see Mattt Thompson (AFNetworking & NSHipster) have quite a few commits in the repository. I followed him religiously when he would write for NSHipster and then he just kind of disappeared for a while (or I have no clue where to look). Regardless, great to see Apple looked to him for advice on this project seeing he has produced some of the most popular open source software for iOS and OS X that I know of.
https://github.com/apple/swift-package-manager/commits/maste...
In Swift package managerIt should be possible to link to GUI libraries implemented in C, like Gtk+.
https://github.com/apple/swift-package-manager/blob/master/D...
In Swift is Open SourceShowing the 15 most recent of 19 sources. Enable JavaScript to search and browse every indexed mention.