Any interest in Linux improvements? Has Swift for Linux caught up yet?

I may submit a proposal if the Swift community needs better Linux support. Or tooling in general that is not tied to Xcode/Apple.

I think Swift is an excellent language and serious contender, especially since it's like Kotlin/Java but actually has value types (or at least pretends to. I remember reading they're CoW / not actually value types under the hood). But last time I tried using it the lack of Linux and non-Xcode/AppCode support was a dealbreaker.


FWIW CoW is a manual optimization done for certain specific value types, not a characteristic of value types in Swift in general.


Swift runs fine on Linux overall, and the Foundation library is planned to be equal on all supported platforms. AppCode (and the Swift plugin for CLion) are deprecated, use the excellent Swift extension for Visual Studio Code as development environment (tip: set Editor › Inlay Hints: offUnlessPressed). So you might again give it try on Linux :blush:

1 Like

The interest is there, but is held back by the devastating state of swift-corelibs-foundation. The implementation gaps are widening and no one seems to be assigned to review pull requests and make it smaller. Instead a vague new Swift-native implementation of Foundation is being worked on that is missing crucial infrastructure.

If we can get enough people behind such an initiative, it might be worth it to fork swift-corelibs-foundation for a better experience on !APPLE platforms.


I would rather put the energy into the proposed re-implementation which I think is a good idea and avoid any fork and in the meantime do early checks on Linux while developing.

1 Like

Foundation is a no-go on constrained server deployment targets, it is too large and uses too much memory. the framework should be broken up or replaced with smaller, more specialized packages.

Foundation does not harm consumer-grade macOS/iOS applications, because the library ships with the OS and can be shared between many applications. but Foundation unfortunately is a killer on platforms like linux where static linking is the standard.

i personally have sunk thousands of hours over many years into developing server-friendly, Foundation-free alternatives. but it gobbles up a lot of time and it is a very aggravating process, when you consider that users of other languages do not need to waste time reinventing everything from scratch.


That‘s the plan for the re-implementation according to the blog entry already mentioned.

…BTW what about the flto option of the LLVM linker, shouldn‘t this linker option remove parts that you do not need?

Without disagreeing that it makes sense splitting a large monolithic framework into pieces,

If you replace "Foundation" with something else (like"large image processing library", etc) in this sentence what difference would it make? Couldn't dynamic linking be used on linux?

Isn’t the answer more to improve dead/unused code stripping also, I’ve seen a few cases like e.g.

Then it should matter less how the code is structured when linking statically.

1 Like

That‘s all good for those folks who want to use it in, say, 2025 or later, it doesn‘t help the developers who are actually struggling since years against swift-corelibs-foundation until this very point of time.

1 Like

Does anyone know when will the new foundation be released to the public? And is there anywhere on the forum where this is discussed?

See this forums topic by @Tony_Parker. I guess the community will be involved before it will be finished.

Update: No planned release date mentioned.