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).

I guess that explains why Dave Verwer handed off ownership of the iOS Dev Weekly newsletter.

Always great to see community members see success.

• lsllc

  today at 8:23 PM

  Yes, congrats to Dave on two successes!

  • daveverwer

    today at 8:36 PM

    Thank you both!

Back when I was following Swift, I was a bit confused by there being 2 distinct sites that seemed to be pretty much the same thing:

- https://swiftpackageregistry.com

- https://swiftpackageindex.com

Well I was thinking about making a competitor to SPI because they only support GitHub repo’s.

This news makes it easy. I’m starting the engines on this…

• unfunco

  today at 7:09 PM

  Working on an idea after it has been Sherlocked is a bold choice.

  • nish__

    today at 7:18 PM

    What does Sherlocked mean?

    • julianozen

      today at 7:20 PM

      It means Apple (or big tech) has adopted/cloned your product basically killing your products ability to succeed

      In reference to when Apple created a project called Sherlock that was a direct copy of a popular Mac app Watson

      • jrmg

        today at 7:35 PM

        This makes it sound like Sherlock was named in response to Watson. It was the other way around.

        Earlier versions of Mac OS had an app called ‘Sherlock’[^1] that could search local files and the web in a fairly rigid manner.

        ‘Watson’[^2] was a third party shareware app very much inspired by Sherlock (and obviously, given the name, not trying to hide that!) that was much more flexible, more ‘OS X-like’, arguably much more user friendly, and was open to plugins (like, there was a movie time search plugin, an eBay plugin, an Amazon plugin etc).

        Sherlock 3[^3], in MacOS 10.2, was redesigned with a UI very like that of Watson, and also allowed similar plugins, making Watson obsolete.

        In the Apple developer world, “being Sherlocked” came to mean “your app being made obsolete by Apple including identical functionality with the OS”.

        1: https://winworldpc.com/res/img/screenshots/f2d124c36d74f71c6... 2: https://en.wikipedia.org/wiki/Karelia_Watson 3: https://en.wikipedia.org/wiki/Sherlock_(software)

      • embedding-shape

        today at 9:03 PM

        But here Apple seems like they avoided that by buying the project instead of creating their own clone. Doesn't that make it nothing lime the Sherlock/Watson situation?

        • MoonWalk

          today at 9:15 PM

          Indeed, it seems like the honorable approach.

    • doodpants

      today at 7:21 PM

      https://thehustle.co/sherlocking-explained

    • xd1936

      today at 7:20 PM

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

      • cavoirom

        today at 7:40 PM

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

        • fastball

          today at 9:52 PM

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

        • MBCook

          today at 8:53 PM

          I think the Sherlock thing was in the OS 8 or OS 9 days whereas Spotlight didn’t come around until sometime in macOS X, maybe 10.4 or so?

• rahkiin

  today at 6:46 PM

  Or send in a PR for gitlab/… support?

  • peterspath

    today at 7:27 PM

    They did not want that and discouraged it.

    • daveverwer

      today at 8:36 PM

      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.

      • peterspath

        today at 9:34 PM

        That is good to hear :-)

  • bigyabai

    today at 7:32 PM

    Merging a PR with Apple is harder than merging into the left side of a six-lane highway during rush hour.

    • rescripting

      today at 7:40 PM

      Is it? What's difficult about it? I see PRs from contributors outside Apple all the time in https://github.com/swiftlang/

• trollbridge

  today at 7:36 PM

  Please get in touch, as I've wanted this to support Gitlab (et al) for a while, and I'm nervous about the future of SPI now.

• huflungdung

  today at 6:50 PM

  [dead]

Not optimistic here. While I'm glad the SPI guys are getting paid (that is, a full time job), Apple is pretty bad at open source and developer services both, and they explicitly call out developer identity as a future direction, which doesn't fill me with hope.

• RobMurray

  today at 8:48 PM

  I tried to get a personal developer account (I'm already a developer through an organisation). The app required a Driver's license as the only accepted ID. I don't drive because I'm blind. They did a screen share and talked me through applying on the web site. It failed. They never gave a reason and ignored me when I asked for one. They just said

  "Hello Robert, Thank you for your patience while I awaited a response from our operations team.

  Upon review, we have found that we can’t verify your identity with the Apple Developer app or provide further assistance with the Apple Account for Apple developer programs.

  You can still take advantage of great content using your Apple Account in Xcode to develop and test apps on your own device. Learn more about Xcode development.

  I do apologise that I was not of more help to you in this situation but wish you the best of luck for the future. "

  They will destroy the developer experience when they add identity and signing.

• marcelox86

  today at 6:47 PM

  I see the opposite, they have a lot of oss projects nowadays and most of their new, interesting stuff is getting open sourced too, a la Microsoft

  • jshier

    today at 6:51 PM

    Simply being open doesn't make them good open source projects. Luckily the SPI shouldn't need to conform to Apple's release schedule, and should operate mostly independently, so the worst aspects of Apple's open source projects will be less of an issue.

    • y1n0

      today at 7:11 PM

      No true Scotsman…

      • bigyabai

        today at 8:19 PM

        Even simpler, this is a "no Scotsman" scenario. Apple has unprecedented contempt for Open designs and software standards, even compared to the pitiful example that Microsoft and Google set.

        Unlike them, Apple takes a stance of contravening the public good to emphasize lock-in. They refused USB-C for as long as possible to sell licensed serial connectors that their Macs didn't even use. They fought tooth-and-nail to politicize the free distribution of software when the EU wanted to enable sideloading. They abandoned open initiatives like Khronos, for no reason other than to screw over cross-platform developers. They give Safari special OS entitlements that they refuse to extend to competing mobile browsers, and then justify it as if they can't write a safe OS.

        There is no company on planet Earth that goes this far to undermine FOSS. Apple is the fakest Scot.

• SoKamil

  today at 6:36 PM

  This acquisition sounds like a sign that Apple wants to get better on that front.

  • jshier

    today at 6:52 PM

    That's a pretty low bar, and doesn't necessarily mean "good".

    • MBCook

      today at 8:54 PM

      That’s right. Whenever a company does something that seems good let’s just start being mean.

      If they’ve ever done something we don’t like we’re not allowed to celebrate anything.

      Might send the wrong message.

kind of surprised Swift didn't launch with this by default, built in-house

Apple has something with Swift similar to what Google has with Go. The language has a lot of desirable features for server development very much like Go and Rust. Especially when compared to Java and C#.

It makes sense for them to build their services using Swift instead of something like Go and the Swift-on-server team has been doing a lot of work to get swift in a usable state on Linux. Having a thriving opensource (starting with a package index) makes a lot of sense to them for that.

My only problem with Swift is personal taste and experience. I tried it on linux few times (admittingly few years ago now) and generally I wasn't a fan. Go and Rust solve all the problems that Swift could have solved for me, so I didn't bother. But just like node got an entire class of developers into server side programming, Swift could be apples approach to get their iOS and MacOS developers a way to easily write server side code in swift as well

• frizlab

  today at 7:45 PM

  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.

  • hocuspocus

    today at 7:58 PM

    Easy and approachable sound pretty subjective to say the least; feature and syntax wise, Swift has become an absolute monster of a language. Rust's tooling and ecosystem are ahead and these points matter to me more than the raw syntax in the age of LLMs.

    • frizlab

      today at 8:54 PM

      As per my experience, the learning curve of Swift is easier than rust’s. Yes, obviously, it’s subjective. Yes, if you want to do complex things in Swift (e.g. generic packs), the syntax is more complex, but that’s not needed every day.

      As per the tooling, idk enough to report on that.

      As per the LLMs remark, I do not use that at all, still, and hopefully never will, though I already know I won’t have the choice at some point, sadly.

  • tialaramex

    today at 8:08 PM

    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 it.

    Is the feature I need available for this Linux device? No idea, but it does work with watchOS and tvOS made by Apple...

    • frizlab

      today at 8:47 PM

      > 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 specifics, AFAIK.

      • tialaramex

        today at 10:08 PM

        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.

  • dhosek

    today at 9:14 PM

    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).

    • anextio

      today at 9:29 PM

      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.