"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.
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
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.
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.
> 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...
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.
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.
Always great to see community members see success.
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 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.
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
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...
This news makes it easy. I’m starting the engines on this…
We might be browsing less, but the models need a source of truth for package metadata, etc.
