ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
79% Positive
Analyzed from 1025 words in the discussion.
Trending Topics
#swift#apple#developer#linux#open#source#more#lot#rust#great
Discussion (41 Comments)Read Original on HackerNews
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).
Always great to see community members see success.
- https://swiftpackageregistry.com
- https://swiftpackageindex.com
This news makes it easy. I’m starting the engines on this…
In reference to when Apple created a project called Sherlock that was a direct copy of a popular Mac app Watson
> 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.
"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.
If they’ve ever done something we don’t like we’re not allowed to celebrate anything.
Might send the wrong message.
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.