Swift Platform Work Group (tentatively named) is a new Swift community workgroup, working together to improve platform usability of Swift. This includes:
Expanding available target platforms for Swift. SPWG should embrace community works in cross compilation area, and, help the community to contribute related changes to upstream. So far, the most heated areas are Android (separatedly maintained by @Finagolfin and the Readdle team) and WebAssembly (by @Max_Desiatov and others in SwiftWasm community), but we also see works on RISC-V Linux and other targets. With the ongoing work of Swift compiler in Swift, being a Swift target becomes a prerequisite of being a Swift host platform.
Expanding available host platforms for Swift. This includes both expanding the officially supported Linux distributions, and adding new platforms like OpenBSD and Musl Linux. This also includes the work of expanding architecture availability, e.g., Windows on ARM. The work will be more complicated and largely involves Swiftâs build infrastructure.
Improving Swift toolchain experience on existing platforms. Different platform and toolset may have different behavior, and Swift tools should handle these differences for users. The ultimate goal is a unified yet native cross-platform experience, including cross-compilation experience. This is a large area which requires collaboration with SwiftPM and SourceKit-LSP team, and also expanded CI support.
Empowering Swift compiler for existing platforms. Currently, Swift has many language features that are not available for Linux and Windows. This includes restricted platform module, missing API availability and, ultimately, library evolution and ABI stability. By unlocking more functionalities, developers can get more from Swift â and theyâll be more likely and willing to use Swift.
Working towards a better cross-platform Swift ecosystem. This mainly includes introducing guidelines and helpers for coding, building, testing and CI, like SSWG has done for server libraries. By helping library authors writing and testing cross-platform codes correctly, the whole community will benefit from extensive platform support.
And, in its current state, SPWG wonât:
Invest in Apple platform support. Swift functionalities and experience on macOS and other Apple platforms are mature, compared to other platforms. Moreover, modifications to Swift toolchain on macOS may impact Xcode support and OS release, which is not open-source and thus uncontrollable. However, weâre willing to collaborate with related teams in focused areas like cross-compilation.
Invest in low-resource and bare-metal platforms. Although this is also an inspiring area, such platforms are different from others and the work is more specific. A new workgroup has been proposed to exploring this area and SPWG will work with them if necessary.
Note that this initiative is not from the Swift core team or Apple. As the original author, Iâm calling out for community effort and official support in this area by forming SPWG officially.
Since the release of Swift 2.0, which is only available on Ubuntu and macOS, Swift has evolved to officially support CentOS, Amazon Linux and Windows. Community support or improvements are also notable, and we wish to maximize community efforts and bring Swift platform support to the next level by forming SPWG, as described in On the road to Swift 6:
Would it be worthwhile for the pitch to also describe how the new workgroup will enable all these goals? Most platforms require custom work, so my experience with Android will not usually be useful for your work with Windows. Sometimes we can generalize, as in changing the layout of the runtime libraries to support multiple architectures in one resource directory, but often we cannot.
One immediate benefit I can think of is to create a high-bandwidth hub where those adding new platforms can speak to and receive advice from those who already did similar work about the common issues faced, maybe on a Matrix group or something. Another possibility would be to create an Opencollective or some other funding mechanism, where the community could fund something like a FreeBSD port and the workgroup would manage that effort.
Swift is already a very cross-platform language, this workgroup would be a good way to make it one of the best.
From my perspective, we ought to try our best to ensure the end using experience is mostly identical. The implementation could be very different on different platforms, and we already met problems with swift-system where we found it hard even to keep the API surface aligned across platforms. Documentations and PR threads make sense for tracking those differences and their reasons. Code reviews from other members and steady CI support are also important to make sure a platform-specific patch doesnât accidentally affect other platforms.
Itâs worth noting that all Swift workgroups have regular meetings. For every big change or divergence we decide to make, itâs worth first pre-pitched and discussed during the meeting. I would expect feedbacks or suggestions, and sometimes a change will benefit or fit into other platforms as well. The meeting note is also a great resource for later contributors to see what difficulties weâve met and their final solutions, in case they need them in their work.
I would like Swift Platform Work Group to maintain Swift ports in an SSWG way, where platform support are incubated and, as they grow mature and get upstreamed, we can mark them as graduated and officially supported. Community feedback is important here because the more users we have, the more likely we can know where to improve.
SSWG has a âSwift Open Sourceâ Slack workspace which is very responsive to server-related questions, especially those regarding SSWG projects. Itâs a place where users and maintainers can raise questions and discuss with each other, and all threads are public and searchable. Thatâs something we can take away.
As for funding, I donât know if a Swift official (if) workgroup should receive funding by itself, but I guess we wonât block involved communities and individual maintainers from doing so. CI is where the workgroup itself will need financial support and I wish we can have a healthy model to make it run.
Even though you said SPWG wouldn't invest in low-resource and bare-metal platforms, I can see that a stable Swift tooling experience and better cross-platform support can be of great help for those areas.
Thanks for this difficult and important work. Iâm really happy to see the community stepping up. While I would hope that Apple can put some of its own resources behind some of these efforts, many of which do ultimately benefit Apple, Iâm also heartened to see a broader community stepping up beyond the walls of Apple. Swift deserves to be more than just the âApple language.â
Putting my educator hat on, I want to especially cheer for the items under Improving Swift toolchain experience on existing platforms and Empowering the Swift compiler for existing platforms. Iâve wanted to use Swift more in my teaching, but pain points around its Windows and Linux support have been a major roadblock in the past. Just one year ago, I finally had a nontrivial number of students successfully running Swift code on their Windows machines. Hooray! Progress!
To use Swift in an intro class, however, with new beginners for whom even the tiniest install glitch or usability flaw can be crushing, the experience would have to be quite a bit smoother than it is. Even Java + VS Code â a combination with a huge user base and years of work â just barely cuts the mustard on this front! âSuitable for an intro classâ is one of the highest bars to which a toolchain can aspire.
Iâm running one Swift-based assignment again later this fall, which means a class full of students installing Swift, ~half of them on Windows. Iâm wondering: Is there a SPWG forum where I can forward reports of paint points, both large and small? Even if theyâre not strictly the fault of the Swift toolchain, but rather some interaction of, say, Swift + Windows defaults, or Swift + VS Code? Even if theyâre not strictly bugs, but just points of confusion such as UX slip-ups or bad defaults? I would love to help advance the state of the art on this front, but donât want to create noise where itâs not helpful.
Both SPWG and the already proposed Swift Tooling Workgroup will be dedicated to improving user experience of Swift on supported platforms. While the areas may unavoidably overlap, I see SPWG more of handling platform-related features and bugs, and STWG focusing on general usability improvements. It seems your requests are mostly related to the tooling side.
I would like to see these two new workgroups come into reality and work together. For user feedback, we may introduce a single Slack workspace for the two workgroups, since the two need cooperation frequently by themselves. There could be platform- or tool-specific as well as general channels for user feedback, and so both workgroups can be involved. WDYT? @0xTim
It was the runtime library discussion that caught my eye and brought me here. In addition to resolving that issue on Linux, it would be very helpful to start the work of sending patches upstream to LLVM (and any other tools forked and modified) to enable Swift support natively and not have to compile and include duplicates of system tools.
I am working to get Swift into Debian main. It is a long process, but progress is being made. I can try to represent the perspective of the Debian Policy that dictates what our packages must and must not do.
@Ron_Olson might be someone to include as he is the Fedora package maintainer.
I expect that theyâll sometimes awkwardly straddle the two sides in ways that require some coordination across groups. And Iâm sure that it wonât always be clear to me which group applies to a particular problem, sitting as I do outside of both groups.
Having a Slack workspace or some such entry point for reporting pain points encountered off Apple platforms would certainly be nice!
Awesome! Thank you. I have been calling for something like that for quitesome time now. I sincerely hope that one of the effects of this group is to decrease the gaping gap in Foundationâs feature parity.
In contrast to what many âServer-side-Swiftâ people seem to think, Foundation is going to be relevant for cross-platform apps quite substantially and the semantics and feature gap is hurting a lot. Even more so when community contributions are actively discouraged by pretty much ignoring them. (That may be unfair and a bit harsh, but itâs my perception when looking at the pull requests)
At risk of derailing a thread, it's important to note that having the API surface aligned across platforms is an explicit anti-goal for Swift System. Quoting the readme:
System is a multi-platform library, not a cross-platform one. It provides a separate set of APIs and behaviors on every supported platform, closely reflecting the underlying OS interfaces.
System's goal is to faithfully represent the semantics of a platform's API in fluent Swift, not to provide a cross-platform abstraction layer.
Nice explanation! I mentioned Swift System here because I regard it as a typical case where we should carefully design the differences in API design and implementation across platforms. These differences should be well documented and explained, so users and contributors can know how we get there.
BTW, as a multi-platform package, Swift System 1.0 is not doing very well regarding to Windows support, and it reflects the miss of cross-platform guidelines and best practices. Thatâs something I would like to address by the âworking towards a better cross-platform Swift ecosystemâ goal.
Can you elaborate on what sort of help is even required to upstream those ports?
The RISC-V patch looks fairly trivial, and the Wasm port appears to have been stable for quite some time. Do we need better testing from the community, or... what?
Yes. It is very clear (?) that there should be a âcoreâ Swift equal on all platforms, including important âcoreâ(*) libraries. (And I think that nobody wants âlanguage featuresâ to be different on any platforms.) E.g. having to import FoundationNetworking on non-Apple platform to use URLRequest and URLSession seems strange (apart from all historical reasons), and where such cross-platform libraries exist, I would hope that Apple would also use them on its platforms (if this is possible), e.g. having to use autoreleasepool just on Apple platforms for some methods in Foundation would not be necessary if the same implementations(**) would be used.
Clearly stating where something is not cross-platform is then quite important. Maybe the developer should even be warned when using features not available on all platforms when not stating according platforms in Package.swift? (I know the current âplatformsâ entry works differently. And yes, there is the âavailableâ notation, but this is for source code, not for compiled libraries?)
(*): Yes, this is could be read as a reference to .NET Core from Microsoft, but I do not think that it will or should go as far. For an extreme case, having the same GUI experience on all platforms is certainly not a sensible goal.
(**): At the end of this interview Ben Cohen mentioned something about using the same implementations if I understand it correctly.
As a contributor, I observed noticeably slow responses to patches around platforms apart from Darwin and Linux, even for trivial ones. This could be a result of multiple factors:
new platform maintainers often donât have commit access;
thereâs no platform manager so non-trivial changes are not easily evaluated;
thereâs no CI or testing infrastructure so others donât know if it actually works;
âŠ
This, however, becomes a blocker for new official platform support, even if the port is pretty mature. It will take time for us to smooth out these issues by letting a specific group of people to handle it officially. (And yes, CI costs, and weâre clearly in short of it. Iâm not sure if funding can help, but thatâs important for new portsâŠ)
And like how SSWG tracks its own project and evaluates others regularly, SPWG will track the state of each unofficial port, including maturity, popularity and upstreaming process, so interested users can see the progress in a more direct way.
I apologize iâm advance for my naĂŻve perspective; but the questions that come to mind are:
How do multi-platform improvements work with integration into Swift proper? Ie, is Apple fine to i have them included? Or are we dealing with a fork all the time?
Same question for libraries/frameworks etc.
Ideally, one would want anything cross-platform to
be implemented as consistently as possible, which wonât happen without a clear plan, guidelines, rules etc.. It would be great if Apple would endorse/approve such a thing.
Swift is an open-source effort, which should be open to any reasonable improvements, instead of having explicitly what Apple needs. New platform support, of course, can be upstreamed. Windows support is exactly the case, and SwiftWasm upstreaming is in progress. Eventually we should merge mature ports into mainline and announce them as officially supported.
IMO SPWG can take care of it, while Appleâs not so involved â weâre having plenty of people outside of Apple in various existing workgroups and theyâre taking charge of a few important aspects of the Swift project. Itâs a goal to improve cross-platform usability of standard/core/official libraries and as I mentioned in the initiative, there shall also be guidelines for other library maintainers to follow.
No no no, no fork please (of course, legally everyone is allowed to do a fork, and technically you are working in a fork to do a pull request blablabla, but you know what I mean).
I'd just like to add that I've worked two weeks in May to provide support for Swift on Exherbo. I had to pause it but I'll mainly be back on it from March 6th to September 15th 2023, to hopefully finish the packaging. I may work on it before March 2023, but I can't confirm this yet. @compnerd has been of immense help for this challenging task.