Initiative: Swift Platform Work Group

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.

9 Likes

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

2 Likes

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.

2 Likes

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!

Yeah, so sharing the same Slack workspace looks like a good solution.

1 Like

Awesome! Thank you. I have been calling for something like that for quite some 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)

1 Like

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.

9 Likes

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.

1 Like

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.

2 Likes

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.

5 Likes

I think it mostly reflects the lack of any volunteers with deep knowledge about windows system API. =)

3 Likes

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.

1 Like

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).

For everything else see maybe this comment.

See the same comment mentioned above.

Happy to see such workgroup was created!

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.

To be clear, this is no more than an initiative, instead of an announcement — SPWG is not a thing yet, but I would like to see people pushing it and finally bringing it to life.

Despite not being mentioned in the post, making Swift available on more Linux distributions is also a promising goal. Thank all of you who’re working on it!

2 Likes

Super happy to see this initiative. I've been trying to dip my toes in cross compiling swift a few times in the previous years without success, so i'm afraid i won't be able to help much at least in the beginning, beside writing some documentation and testing some scripts on my configuration.

Where can people join this workgroup ?

Just to be clear - Windows ARM support is in many senses already there. Although not released, there are ARM64 toolchain builds, and an ARM64 SDK as well. There is a cache file available to build the ARM64 SDK

The ARMv7 support has a few known issues with code generation: e.g. HFAs are not lowered properly ( WIP/IRGen: PCS for ARM VFP CC does not correctly handle HFAs by compnerd · Pull Request #14304 · apple/swift (github.com))

The ARM64 runtime does build, though there is a failure that needs to be investigated still in Foundation that currently causes issues with the swift-driver. The C++ driver does function properly though.

In fact, the X86 target also has been repaired for the most part. The X86 support has one known limitation: calling conventions on C functions. In particular here, SIL has a limitation that it does not properly preserve the calling convention and if the calling convention does not match the default calling convention, it will lower the calls to C or closures improperly.

5 Likes

The Slack was renamed from the Swift Server Slack to Swift Open Source to encompass more than just server work. The Website Workgroup also coordinate their efforts their so the more the merrier! Feel free to create public/private channels as needed

3 Likes