Live data from Hacker News

Swift Package Index joins Apple

swiftpackageindex.com

41–50 of 85 posts

Re: Swift Package Index joins Apple

#41
post #39
post #25

Earlier quoted context omitted.

Swift on Linux has changed since a few years ago. A lot. I prefer Swift over rust as it has the same memory-safety guarantees with a much more approachable syntax, and is generally easier to work with.

Isn’t there a performance cost though with runtime binding of functions? (I’ve not looked too closely at Swift since the first couple of years when Objective C compatibility was essential, so maybe that’s less of a default than it was in the early days).

Runtime binding only occurs for Objective-C interop.

Swift functions are bound at compile time when statically known. Dynamic dispatch is done through vtables for native Swift classes, and through witness tables for protocol existentials.

Re: Swift Package Index joins Apple

#42

Earlier quoted context omitted.

They did not want that and discouraged it.

This is a genuinely interesting topic, and as we say in the blog post: > Together, we’re building a comprehensive package registry to serve the Swift community’s evolving needs. The great thing about a registry is that it doesn't care where the original source is hosted. We will be moving away from that model completely as we work towards this.

That is good to hear :-)

Re: Swift Package Index joins Apple

#43
post #14

Earlier quoted context omitted.

It's a reference to Sherlock (and later Spotlight) being added to macOS, rendering the previous third-party search-launcher tools obsolete.

Thank you, I learned it today. On the other side, some users replaced Sherlock (Spotlight) with Alfred.

And somewhere in there Quicksilver was pretty popular. And now in 2026 the main competition is Raycast. An evergreen space really.

Re: Swift Package Index joins Apple

#44
Glad to see it.

I like the SPM, but it definitely has its "rough edges."

Having an index like this, is great.

However, I guarantee that there will be some caterwaulin', if Apple decides to regulate which packages get indexed (which I think should happen, as it's now an official Apple brand).

Re: Swift Package Index joins Apple

#45
post #33

Earlier quoted context omitted.

The same condition is still true as the first time I was told "Swift on Linux" is somehow a first class experience: > Documentation for the standard library is presently hosted on the Apple Developer website. Sure enough, by Apple policy, the documentation pretends no non-Apple platforms exist. What happens for an API which could be different if your system isn't fruit-flavoured? They don't care and won't talk about…

> Is the feature I need available for this Linux device? If it’s in Foundation, yes. Swift 6 on Apple OSes now (since a while ago actually) uses the same open-source foundation as Linux. If it’s a proprietary framework (e.g. TabularData), no. It’s simple. For the rest, almost all Swift packages developed by Apple are fully compatible with Linux, and the documentation of said packages is usually explicit wrt. platform…

What a mess. A standard library and then apparently on top of that a Core and that's where they put a Foundation, you can imagine Apple architects arguing with the elevator contractors, "No, no, the Ground floor of our building is below our Foundation, it's very straight forward..."

But although that's enough for me to want no part of it, that's not what I was gesturing at. When we dig under the "Foundation" to look at the standard library we find that contrary to your assurance what works and how it works varies from one platform to another, just Apple only care about Apple platforms and so as usual they don't think that's worth mentioning.

They do have this information, they just don't publish it on their Apple pages because they're Apple and yet they insist this counts as the Swift documentation - and that should be all the reason you need not to take such "support" seriously.

Re: Swift Package Index joins Apple

#46

Glad to see it. I like the SPM, but it definitely has its "rough edges." Having an index like this, is great. However, I guarantee that there will be some caterwaulin', if Apple decides to regulate which packages get indexed (which I think should happen, as it's now an official Apple brand).

> … if Apple decides to regulate which packages get indexed

I have mixed feelings here. If they disallow too much, they’ll alienate too many projects and there will be an exodus of non-Apple platform Swift devs.

I guess it doesn’t really gate pulling any dependencies you want, but too much and/or the wrong kind of filtering (e.g. removing non-Apple alternatives to core Apple libraries) would not look (nor feel) good.

Re: Swift Package Index joins Apple

#47

Glad to see it. I like the SPM, but it definitely has its "rough edges." Having an index like this, is great. However, I guarantee that there will be some caterwaulin', if Apple decides to regulate which packages get indexed (which I think should happen, as it's now an official Apple brand).

> … if Apple decides to regulate which packages get indexed I have mixed feelings here. If they disallow too much, they’ll alienate too many projects and there will be an exodus of non-Apple platform Swift devs. I guess it doesn’t really gate pulling any dependencies you want, but too much and/or the wrong kind of filtering (e.g. removing non-Apple alternatives to core Apple libraries) would not look (nor feel) good.

Agreed. They do have a nasty habit of dinging competitors to Apple apps, in the App Store.

It would not be a good thing, if they did that, here.

It would be interesting to see what they do with some of my packages.

I release alternative UI views, and Apple is infamous for wanting to force all developers into conforming to their UX.

It would make me sad, if they blocked things like these:

https://github.com/RiftValleySoftware/RVS_Spinner

https://github.com/RiftValleySoftware/RVS_Checkbox

https://github.com/RiftValleySoftware/RVS_RetroLEDDisplay

Re: Swift Package Index joins Apple

#48
post #33

Earlier quoted context omitted.

> Is the feature I need available for this Linux device? If it’s in Foundation, yes. Swift 6 on Apple OSes now (since a while ago actually) uses the same open-source foundation as Linux. If it’s a proprietary framework (e.g. TabularData), no. It’s simple. For the rest, almost all Swift packages developed by Apple are fully compatible with Linux, and the documentation of said packages is usually explicit wrt. platform…

What a mess. A standard library and then apparently on top of that a Core and that's where they put a Foundation, you can imagine Apple architects arguing with the elevator contractors, "No, no, the Ground floor of our building is below our Foundation, it's very straight forward..." But although that's enough for me to want no part of it, that's not what I was gesturing at. When we dig under the "Foundation" to look…

At that point I’m gonna need specific examples, because such differences between platforms are getting more and more sparse…

Also I’m not sure what the Core thing you’re talking about even is.

Post reply on HN