It's Apple, theres a high chance they'll just delete it and pretend it never existed. They've got a pretty consistent reputation for this now. Dark Sky, PrimeSense, Drive.ai, Beddit, Topsy, NextVR, Fleetsmith, FingerWorks, to name a few.
From what I've heard, it sounds like it's not nearly as good or simple an experience as DarkSky was. But as an Android user I wouldn't know, DarkSky was just killed by Apple for everyone but Apple customers when they merged it in.
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”.
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?
Parent comment said "Well I was thinking about making a competitor...."
Response said "Working on an idea after it has been Sherlocked is a bold choice"
Child comment asked what Sherlocked meant. I explained.
Apple purchasing Swift Package Index is great. The Sherlocking above comment was in response to the suggesting that theyd create a project apple has already made first party
Cloning features and UI in your own product is not dishonorable. Outcompeting someone who didn’t bake in a moat isn’t doing anything wrong, or Burger King and Wendy’s shouldn’t exist.
Well at least they didn't have their product managers reach out to "start a conversation" like Google and Microsoft's who then blatantly rip off the product later.
> "Here's how I see it," Jobs said — I'm loosely paraphrasing.
> "You know those handcars, the little machines that people stand on and pump to move along on the train tracks? That's Karelia. Apple is the steam train that owns the tracks."
> So basically the message was: get out of the way, kid; this is our market.
Hope folks will always keep that in mind as they develop software for proprietary platforms they don't own.
> Hope folks will always keep that in mind as they develop software for proprietary platforms they don't own.
You're right of course and "The Other Road Ahead" was very prescient, but I think the desktop vs web-app divide is marginal nowadays, excepting one huge difference: desktop apps can offer a guarantee of privacy which browser based apps cannot.
Note that a guarantee is just that, Apple offer privacy guarantees, but there is is of course no such thing as absolute privacy or security.
It's perfectly possible to write desktop apps that are thin clients for web apps, so there's no real divide except where the code executes: in the browser sandbox, or in the OS sandbox.
The current issue with desktop apps is mainly UI framework related. The browser based programming model has had so many resources thrown at it that somehow JavaScript and a bunch of divs is probably the best UI framework there is, and it pains me to say that.
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.
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.
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.
My driver's license is in a form factor Apple cannot scan. A few months ago, I tried to get it scanned four times (with the UI telling me various versions of "your ID is too blurry" / "there was a technical issue") before Apple just blocked me from applying for the developer program.
Their support gave me the exact same template: "After reviewing your account details, it looks like we can’t verify your identity with the Apple Developer app or provide further assistance with the Apple Account for Apple developer programs."
I was only unblocked recently (surprisingly -- I thought I was banned forever), and so I decided to try applying with passport instead. That got further, as instead of saying my ID image was blurry, it said "ID Verification Rejected".
I am in contact with developer support right now and they told me that one of my devices or phone numbers was registered with another developer account, but they haven't told me which one (only to "remove phone numbers and devices that you don’t own" -- which isn't applicable as I own all of them).
They're taking 4+ days to reply each time though, which is super frustrating.
Yes, of course, it seems that type of ID was specifically rejected in the story above. Only drivers allowed to sign up. Non-drivers rejected because they don’t drive.
Yes, I have a passport which is accepted by every other company I have had to verify id with. Apple doesn't offer it as an option for UK accounts for some reason.
I agree, but I just created anew Apple id, and got a developer subscription straight away on the web without it asking for id. I suppose they will probably require id if I submit to the app store, but the fact that I already paid should carry more weight I hope.
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.
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.
Yes, Apple is quite selfish when it comes to open source. They avoid GPL license code because they only want to selectively share their code, which is one of the reason they now avoid GCC and stopped utilising GNU Coreutils in their OSes. It supports developments of some popular opensource apps (like Blender) because it is very popular and not having it on its platform hurts it. And now, by charging developers an annual fee for distribution through App Stores, they also prevent many non-commercial open source applications from being available on the App Store. As Apple also further makes money from any commercial apps through the app store (by extorting a commission from them), it doesn't really want such popular free opensource apps to compete with the commercial apps - every time someone uses one of these free apps, Apple also loses money. Thus, by gatekeeping distribution Apple now effectively cripples the growth of open source applications on its platform. (The only reason a few of it - like VLC, for example - still survives on the App Store is because some kind people donate the money to pay Apple's fees - a waste of money and a shameful act for a trillion dollar company).
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
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.
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.
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...
> 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.
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.
Foundation is on top of Core Foundation, not "Core". Core Foundation is a C++ version of certain Foundation primitives for operating system services that can't depend on the Objective-C runtime.
The Swift standard library would be built on top of that, not the other way around.
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.
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.
I'm always surprised as well when new languages targeting widespread use launch without an official one. Dotnet/C#, Go and other languages that come batteries included with the package manager built into some kind of compiler/SDK binary, make the out of the box experience so much smoother, and the community hasn't fragmented nearly as much as say Java, Python and JS have into competing third party package management and project build tools.
Everyone in the Go community more or less uses the same Go modules support built into the SDK binary, much like how almost the entire DotNet community uses the NuGet package manager support built into the dotnet SDK binary. There are no extra dependencies to grab your project dependencies and build it.
My experiences in those langauges is that there is so much less debate over tooling, and people just get work done. No one in DotNet is waging an equivelent holy war about Gradle vs Maven etc...
I'm all for choices, but the languages who have made package management a first class citizen in their SDKs tend to be the languages I've enjoyed working in the most. I think package management tooling is a critical piece of developer ergonomics.
People used to joke a lot about how JS has a new framework every week, but I feel that way about Python build tooling! I've now had to use uv, poetry, pipenv, hatch...
I find your choice of examples (dotnet and go) baffling to me. Both enjoyed a very long life (8-10 years) past “1.0” before getting a standard package manager. The other examples, Java, python and JS are significantly older than Go (and even dotnet). Python and JS also had a significantly different intended use (scripting) than where they ended. Expectations of a language and its ecosystem changed. The compiler, linker, build system, package manager, LSP, linter, formatter, debugger, and plenty more are expected of any new language now.
Well not Go's package manager, right? Go modules came out 2019, Swift 2015?
I wasn't arguing against Swift needing a default package manager, I agree with that. Just the examples you picked to compare with are odd in context. You could compare Swift to its contemporaries like Rust or Zig and come to the same conclusion.
Because a package index isn’t actually core to a programming language, and specifically with Swift, Apple tried to ship as many of the necessary types as possible in the standard library
I guess that explains why Dave Verwer handed off ownership of the iOS Dev Weekly newsletter.
Always great to see community members see success.
Yes, congrats to Dave on two successes!
Thank you both!
Agreed, congratulations are in order!
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…
Working on an idea after it has been Sherlocked is a bold choice.
It's Apple, theres a high chance they'll just delete it and pretend it never existed. They've got a pretty consistent reputation for this now. Dark Sky, PrimeSense, Drive.ai, Beddit, Topsy, NextVR, Fleetsmith, FingerWorks, to name a few.
DarkSky was at least incorporated into their weather app tho.
From what I've heard, it sounds like it's not nearly as good or simple an experience as DarkSky was. But as an Android user I wouldn't know, DarkSky was just killed by Apple for everyone but Apple customers when they merged it in.
As an Android user you can absolutely pay for access to dark sky's api.
I think I can pay for access to the Apple Weather api, which is neither the DarkSky api, nor the DarkSky app that was killed by Apple.
And Sherlock even
What does Sherlocked mean?
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
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)
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?
Parent comment said "Well I was thinking about making a competitor...."
Response said "Working on an idea after it has been Sherlocked is a bold choice"
Child comment asked what Sherlocked meant. I explained.
Apple purchasing Swift Package Index is great. The Sherlocking above comment was in response to the suggesting that theyd create a project apple has already made first party
Indeed, it seems like the honorable approach.
Cloning features and UI in your own product is not dishonorable. Outcompeting someone who didn’t bake in a moat isn’t doing anything wrong, or Burger King and Wendy’s shouldn’t exist.
Well at least they didn't have their product managers reach out to "start a conversation" like Google and Microsoft's who then blatantly rip off the product later.
https://thehustle.co/sherlocking-explained
https://www.karelia.com/blog/the-long-story-behind-karel.htm...
> An hour later, Steve Jobs called me.
> "Here's how I see it," Jobs said — I'm loosely paraphrasing.
> "You know those handcars, the little machines that people stand on and pump to move along on the train tracks? That's Karelia. Apple is the steam train that owns the tracks."
> So basically the message was: get out of the way, kid; this is our market.
Hope folks will always keep that in mind as they develop software for proprietary platforms they don't own.
https://www.paulgraham.com/road.html
> If you want to write desktop software now you do it on Microsoft's terms, calling their APIs and working around their buggy OS.
> And if you manage to write something that takes off, you may find that you were merely doing market research for Microsoft.
> Hope folks will always keep that in mind as they develop software for proprietary platforms they don't own.
You're right of course and "The Other Road Ahead" was very prescient, but I think the desktop vs web-app divide is marginal nowadays, excepting one huge difference: desktop apps can offer a guarantee of privacy which browser based apps cannot.
Note that a guarantee is just that, Apple offer privacy guarantees, but there is is of course no such thing as absolute privacy or security.
It's perfectly possible to write desktop apps that are thin clients for web apps, so there's no real divide except where the code executes: in the browser sandbox, or in the OS sandbox.
The current issue with desktop apps is mainly UI framework related. The browser based programming model has had so many resources thrown at it that somehow JavaScript and a bunch of divs is probably the best UI framework there is, and it pains me to say that.
So SJ was right, right?
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.
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?
Or send in a PR for gitlab/… support?
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 :-)
Merging a PR with Apple is harder than merging into the left side of a six-lane highway during rush hour.
Is it? What's difficult about it? I see PRs from contributors outside Apple all the time in https://github.com/swiftlang/
Do I dare mention the family guy way to achieve this? :P
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.
[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.
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.
My driver's license is in a form factor Apple cannot scan. A few months ago, I tried to get it scanned four times (with the UI telling me various versions of "your ID is too blurry" / "there was a technical issue") before Apple just blocked me from applying for the developer program.
Their support gave me the exact same template: "After reviewing your account details, it looks like we can’t verify your identity with the Apple Developer app or provide further assistance with the Apple Account for Apple developer programs."
I was only unblocked recently (surprisingly -- I thought I was banned forever), and so I decided to try applying with passport instead. That got further, as instead of saying my ID image was blurry, it said "ID Verification Rejected".
I am in contact with developer support right now and they told me that one of my devices or phone numbers was registered with another developer account, but they haven't told me which one (only to "remove phone numbers and devices that you don’t own" -- which isn't applicable as I own all of them).
They're taking 4+ days to reply each time though, which is super frustrating.
I'm not sure about the laws where you're at, but to me, this sounds like something they should have to accommodate you on.
Don’t jurisdictions generally offer ID cards for non-drivers that are functionally equivalent for ID purposes, you just can’t drive?
Yes, of course, it seems that type of ID was specifically rejected in the story above. Only drivers allowed to sign up. Non-drivers rejected because they don’t drive.
Yes, I have a passport which is accepted by every other company I have had to verify id with. Apple doesn't offer it as an option for UK accounts for some reason.
I agree, but I just created anew Apple id, and got a developer subscription straight away on the web without it asking for id. I suppose they will probably require id if I submit to the app store, but the fact that I already paid should carry more weight I hope.
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
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.
No true Scotsman…
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.
Yes, Apple is quite selfish when it comes to open source. They avoid GPL license code because they only want to selectively share their code, which is one of the reason they now avoid GCC and stopped utilising GNU Coreutils in their OSes. It supports developments of some popular opensource apps (like Blender) because it is very popular and not having it on its platform hurts it. And now, by charging developers an annual fee for distribution through App Stores, they also prevent many non-commercial open source applications from being available on the App Store. As Apple also further makes money from any commercial apps through the app store (by extorting a commission from them), it doesn't really want such popular free opensource apps to compete with the commercial apps - every time someone uses one of these free apps, Apple also loses money. Thus, by gatekeeping distribution Apple now effectively cripples the growth of open source applications on its platform. (The only reason a few of it - like VLC, for example - still survives on the App Store is because some kind people donate the money to pay Apple's fees - a waste of money and a shameful act for a trillion dollar company).
Dude. Apple basically created USB-C.
Not only is Apple bad at open source, they ban participating on open source projects outside of work.
https://web.archive.org/web/20200421143520/https://twitter.c...
This acquisition sounds like a sign that Apple wants to get better on that front.
That's a pretty low bar, and doesn't necessarily mean "good".
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.
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
I've never heard of the first one!
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
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.
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.
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.
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...
> 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.
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.
Foundation is on top of Core Foundation, not "Core". Core Foundation is a C++ version of certain Foundation primitives for operating system services that can't depend on the Objective-C runtime.
The Swift standard library would be built on top of that, not the other way around.
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.
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.
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
And there I was hoping the Swift ecosystem could emancipate itself from Apple instead of getting eaten up.
I wonder if package indexes become more important in our new day-to-days with LLMs, not less.
We might be browsing less, but the models need a source of truth for package metadata, etc.
kind of surprised Swift didn't launch with this by default, built in-house
I'm always surprised as well when new languages targeting widespread use launch without an official one. Dotnet/C#, Go and other languages that come batteries included with the package manager built into some kind of compiler/SDK binary, make the out of the box experience so much smoother, and the community hasn't fragmented nearly as much as say Java, Python and JS have into competing third party package management and project build tools.
Everyone in the Go community more or less uses the same Go modules support built into the SDK binary, much like how almost the entire DotNet community uses the NuGet package manager support built into the dotnet SDK binary. There are no extra dependencies to grab your project dependencies and build it.
My experiences in those langauges is that there is so much less debate over tooling, and people just get work done. No one in DotNet is waging an equivelent holy war about Gradle vs Maven etc...
I'm all for choices, but the languages who have made package management a first class citizen in their SDKs tend to be the languages I've enjoyed working in the most. I think package management tooling is a critical piece of developer ergonomics.
People used to joke a lot about how JS has a new framework every week, but I feel that way about Python build tooling! I've now had to use uv, poetry, pipenv, hatch...
I find your choice of examples (dotnet and go) baffling to me. Both enjoyed a very long life (8-10 years) past “1.0” before getting a standard package manager. The other examples, Java, python and JS are significantly older than Go (and even dotnet). Python and JS also had a significantly different intended use (scripting) than where they ended. Expectations of a language and its ecosystem changed. The compiler, linker, build system, package manager, LSP, linter, formatter, debugger, and plenty more are expected of any new language now.
All of them pre-exist Swift, so I think it's perfectly fair to compare. Swift wasn't made in a vacuum.
Well not Go's package manager, right? Go modules came out 2019, Swift 2015?
I wasn't arguing against Swift needing a default package manager, I agree with that. Just the examples you picked to compare with are odd in context. You could compare Swift to its contemporaries like Rust or Zig and come to the same conclusion.
I think you missed it: go and dot net launched without package managers. It was a long time before they had a standard package manager.
Because a package index isn’t actually core to a programming language, and specifically with Swift, Apple tried to ship as many of the necessary types as possible in the standard library
I wonder if this means we’ll get an official registry now. The failed partnership with Github was announced 7 years ago.
Back when I was working with Swift, I always thought Swift Package Index was made by Apple
Good this is useful