How to get added to swift-server organization on GitHub?

Well that's where we differ: for something like a JSON parser, just as an individual, I'd want to see comprehensive tests and benchmarks at the very least (bonus points for fuzzing). It's a complex format with a lot of edge-cases. I would expect the SSWG to have at least those kind of standards before recommending a package.

I could go dig for some links, but I don't think that would be productive. And no, I don't think this thread is toxic. I've interacted with the people here long enough to know they post considered questions and opinions and do try to make things better. Generally these forums attract higher quality posters than places such as Reddit or Twitter.


i think there’s a misunderstanding here. i don’t think that recommendation should be the first thing that happens to a package once it goes public. rather, i want to see some kind of support or guidance for the package in the time between when it was spun-off from a private project, and when it’s finally grown all the things you’ve mentioned.

it doesn’t make sense to recommend a project while it’s still “sandbox” or “incubating”, and even less sense for recommendation to be the prerequisite to being considered either of those things.

i honestly think the committee would be better off renaming “incubating” to "graduated”, and “graduated” to something like “certified”. the question then becomes, where do we keep track of all these incubating projects, if not under the swift-server umbrella? how do we help them move forward?

right, a lot of us recognize each other from the mailing list days, even :)


since this discussion has been getting pretty abstract, i went ahead and made a pitch for json over in the pitches section!


I wonder whether we should just take a step back and reconsider the whole "server" in SSWG.

My personal take on that is that I fell in love with Swift and after writing 20 years of Python and Vala next to 12 years of Objective-C, I finally have a programming language that can target both my user interface apps and all the tools (not necessarily server-related) on Linux and macOS. Finally one language for both the shiny things and the boring things (exaggerating, of course).

For me, Swift has enormous potential to offer for the people who write Python, Ruby, Rust, and Go these days. And despite all the hassle to get a comfortable development environment working on non-Apple platforms, once you have something, it just rocks.

So: How can we make Swift more attractive to those people? Isn't that the more important question than "server" or not?

wouldn’t that just be a Swift Working Group?


:sweat_smile: Alright then, how about the SONAPWG then? Guess…


do you have an example of something that is a high priority to you, but does not seem to be a high priority to the server committee? that would help make this discussion more concrete

1 Like

There is plenty of things outside Apple that I wish got more momentum and are not server related.

  • wasm for example, the tram maintaining that is doing a great work but doesn’t seem that people really knows about it.
  • Lately I’ve been looking ant multi-platform game dev and there is things (raylib swift bindings, godot bindings) but it also seems too obscure (sometimes not even compiling)
    Not to diminish the value if those efforts, quite the opposite! I’m just trying to point out that yes, the issues being discussed here are not exclusive for ‘server’.

i made the godot bindings, are they not compiling?

I tried some days ago and was not able to make it work. SPM complained about a conflict of dependencies with swift-argument-parser, some "root" package had a version <1 and another had >1. But the error was not clear on which packages had the issue.

In any case I didn't want to derail the conversation, sorry ^^

1 Like

Indeed, I have.

Ignoring all the problems I have during the development (including Foundation's bugs, missing capabilities, and different semantics on NAPs (non-Apple platforms)), what really grieves me is the deployment process.

If it wasn't for the great work of @futurejones, we would not have a proper installation process for Swift. Cutting toolchain tarballs is last century. For many developers (and many users as well), not having proper operating system packages is a major showstopper. What makes this even more problematic is the lack of static compilation, so if you want your binary packages to be consumed by anyone else, you need to depend on a runtime library package.

This is what in my opinion should be a high priority of anyone who wants to increase Swift's popularity.


the release number for swift-argument-parser has doubled since this summer, so it probably just needs a version bump. (feels like i just released it yesterday…)

at the time the plugin was written, package plugins were still very experimental so it depended on master of SwiftPM instead of a tagged release. in the 6 or so months since, that’s probably no longer the case.

in the meantime, can you file an issue on github with your platform and a small test project?

since it wouldn’t be swift if you weren’t holding it wrong, i have learned that swift binaries are just like any other type of binary and they search for libraries in the same directory that the toolchain lived in at the time when the binary was originally compiled.

in this thread i managed to compile with a dynamic standard library on a separate machine from the deployment target, by recreating the directory structure of the target machine.

it’s annoying, but at least we have a solution/workaround for it, which is more than can be said for a lot of other problems in this space

just reiterating. it's amazing that @futurejones does what he does


Imagine how cool it would be if Apple would actually fund such important FOSS efforts, and use the results officially.


seriously, it could really make a whole world of difference.

obligatory retweet:


Isn't static compilation supposed to work since a year or so? @fabianfett

If you mean statically linking the Swift stdlib, Dispatch and Foundation*. Yes, it is supposed to work. It was however broken on 5.6 and main up until a few days ago. Announcement post on the forums

Open PRs to fix the issues on main (@Alejandro):


Just adding here for visibility - we have a new Swift Server Community org on GH that solves most of the issues asked here