SP-001: Platform Support Levels

Evolution Proposal Reviews
1

Hi everyone,

The Platform Support Levels document was previously (and erroneously) published as a Vision Document; after much discussion about what to do, we've come to the conclusion that we need a new kind of document, of which this is the first instance.

This review therefore has two purposes:

  1. To review the naming and template for what we're currently calling "Policy Documents", and
  2. To review the Platform Support Levels document as the first instance of the above.

We considered splitting the review into two separate parts, but of course we wouldn't be able to accept the Platform Support Levels document without the naming and template for policy documents being settled, and we also wouldn't benefit from accepting the naming and template for policy documents without actually having one we're ready to publish.

Therefore, the review of SP-001 Platform Support Levels beings now and runs through February 12, 2026.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. In this case, we are interested in comments on:

  • The naming of this new category of documents.
  • The policy document template.
  • The Platform Support Levels document itself.

Some questions you might want to answer in your review:

  • Do you think "Policy Document" encapsulates the purpose of this kind of document?

  • Is POL-nnnn a reasonable numbering scheme?

  • Does the policy document template have the right metadata? Do we need additional fields? Or additional values for existing fields?

  • Do you feel the Platform Support Levels proposed are broadly correct?

  • Do we have the balance of requirements right for each tier?

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Thanks for contributing to Swift!

Alastair Houghton
Review Manager

12 Likes
2

Having now sat with the document when it was a Vision document, I have some possibly new thoughts, namely:

  • It may be worthwhile to briefly discuss bootstrap builds, given that Swift now depends on Swift. New platforms will require bootstrap builds to be functional and that changes that break bootstrap builds should be treated as breakages for Tier 1 platforms. This may already be a part of some CI configurations, I haven't checked.

  • Toolchain support on Tier 2 and below is not described; again, given that Swift depends on Swift now, does it make sense to specify that lower tier platforms should only include the libraries and not the compilers? I prompted the question elsewhere but specifying what actually constitutes the toolchain -- what makes sense to consider as a unit in a Swift SDK may be worth formalizing?

  • What constitutes provenance information at Tier 2?

  • Just as an academic question: should FreeBSD be considered Tier 1 given advertised support for the platform, or is this effectively a "sponsored Tier 2" platform?

3 Likes
3

The proposal introduces two concepts that don't have any definitions or hints for what exactly these concepts stand for. Would it be possible to introduce some clarity?

  • Swift Supplemental Libraries
  • Swift Core Libraries
3 Likes
4

They are, I was surprised to see that three linux bootstrap CI jobs are a required element of the daily snapshot candidate CI runs, but funny you mention this now, because bootstrapping with trunk itself is being discontinued this week, dropping down to only supporting bootstrapping with the 6.2 release.

I think this is fine, as we can always cross-compile the Swift stdlib and compiler initially for new upcoming platforms.

My understanding is neither, as it has not been through this outlined platform review process, but I am not on PSG so don't know what is under discussion internally.

5

They explained, but a little bit hidden in a way in this bit:

1 Like
6

Am I understanding this correctly that Foundation, FoundationEssentials, FoundationNetworking, FoundationXML and Dispatch are not required by any platform support level?

7

I believe the plan is that we'll remove the need for bootstrap builds by making cross-compilation work. @etcwilde can probably elaborate on that.

I don't think we need to explicitly call out bootstrap builds in this document, however.

That's correct. It's only a requirement for Tier 1 Toolchain Hosts. Tier 2 or 3 platforms may or may not provide a toolchain — that has no bearing on their tier level — and it's also possible to have a platform that is Tier 1 but not as a toolchain host (even if that platform can support a toolchain, and even if someone is actually building such a thing). An example of a platform that might find itself in that place is Android, since it's theoretically possible to build a toolchain that runs on Android, but I think we would normally expect users to cross-compile.

This is intentionally left unspecified. The ideal would be an SBOM (Software Bill Of Materials) in a standard format (e.g. SPDX, CyloneDX), but the stipulation here is that provenance information exists, not that it's in a particular format.

Current Tier 1 platforms are Apple platforms (macOS, iOS et al), Linux and Windows.

We intend at some point to publish a platform tier list on swift.org.

That's an interesting point, and you're right, that, as written, they are indeed not a hard requirement, though I think if you proposed moving a platform to Tier 2 or Tier 1 without them, the Platform Steering Group is likely to ask you why they aren't present.

Is this a reasonable stance? Do we think we need some extra wording to explain this?

8

Though, if one is building Swift and the libraries, you have to build them anyway since they're a dependency. Why would one not ship the dependency you've already worked to build for the platform?

I think it'd be a good idea to have a commitment around that or similar. I don't think cross-compilation is going to be ideal in some cases, so it would be important to have well-lit alternatives.

9

I'd appreciate if the proposal had a link to that document, as I imagine I'm not the last person asking for that to be clarified.

4 Likes
10

This makes it sounds like to me that these libraries should be at least an explicit soft requirement for any Tier 1 platform. I personally would lobby for even making them a hard requirement since the majority of the packages in the Swift ecosystem depend on one of those modules in some form or another.

2 Likes
11

Believe me I’m all for this, but won’t that put the awkward situation where Apple platforms are a Tier 1 support platform, they have a hard requirement to support FoundationEssentials yet they don’t

2 Likes
12

It does. That's what @ktoso quoted.

They aren't, in fact, a dependency of the Swift runtime libraries themselves, and we can certainly imagine situations where some or all of them might not be present (embedded or other small systems). I think it might be reasonable to indicate that their presence is strongly recommended, however.

I don't want to dwell on this as I think it's a distraction from the proposal we're discussing here, but my understanding is that the intention is that bootstrapping will not be a thing in future.

As I said above, we don't want to rule out the possibility of platforms for which those libraries make no sense being in Tier 1 in the future. The document as it stands explicitly says that its list is a minimum requirement; the expected set of libraries is, I think, somewhat platform specific and if you ask to be in Tier 2 or Tier 1 then the Platform Steering Group is going to pay attention to the set of libraries you have.

Smaller platforms (embedded systems and retrocomputing) might not want all of or even any of the Foundation libraries or for that matter Dispatch. Yes, that would mean that they can't use a wide variety of Swift packages, but that might be an acceptable trade-off, and I don't think it should mean that we can't say that, for instance, Arduino couldn't be Tier 1.

At the same time, I think we'd raise our eyebrows if someone proposed to make Haiku into a Tier 1 platform and it didn't have all of the libraries you mention present.

The question then is whether, and how, we express that in the document.

3 Likes
13

It's an utterly pointless nitpick, but "POL"? :slightly_smiling_face: Perhaps "SP" for "Swift Policy"?

(I'll show myself out.)

1 Like
14

So a Tier 1 platform that supports the features those libraries are meant to expose is expected to make those libraries available, but a Tier 1 platform where those features are not expected to be supportable doesn’t, if I catch your drift?

I assume we’d will never require the exact same API surface for libraries on every Tier 1 platform (for example, if it totally doesn’t make sense for Windows to have some file-related Foundation API that’s too POSIX-brained, then it shouldn’t). In that spirit, it seems fine to consider that a hypothetical Tier 1 Arduino toolchain trivially fulfills any requirement to make, say, Dispatch available if zero APIs in that library make sense for the platform and zero are available.

1 Like
15

Somewhere between a few quick readings and an in-depth study.

Yes, I think this is great, and I'd love to see the project formalize more policies long-term!

Seems reasonable to me.

I think so — though I'd be interested to see either this proposal (or a follow-up one) go a bit more into depth about the intended relationship between a platform and its distributions. I appreciate that the proposal clearly spells out the difference between them, but I think that in practice, Swift distributions make a much larger practical difference to everyday Swift developers than platforms, especially on a platform like Linux. (e.g., support for "Linux" is hard to evaluate if the existing distributions of Swift are not compatible with your distro.)

This may very well be off-topic so please don't hesitate to redirect, but what comes immediately to mind:

  • Do we intend to offer tiers of support for distributions too (e.g., "official", "experimental", "exploratory" distributions), or is this considered out-of-scope for the Platform Steering Group / the Swift project in general?
    • e.g. "Official" distributions are available via swift.org; "experimental" distributions are well-supported externally (e.g., by package managers), and we'd like to ensure that Swift keeps building for these distributions; "experimental" is everything else
  • Whether or not tiers are offered, do we intend to also offer a distribution inclusion/promotion process similar to a platform one?

To be clear: I'm thinking about this from the perspective of someone who currently packages and maintains builds for Gentoo Linux, which is a source-oriented distribution; I package both source and binary builds for Swift, though this is a non-trivial effort because Swift doesn't build out of the box on Gentoo and requires a host of patches to both compile and adhere to distro standards/expectations. I'd find it helpful, if we're formalizing policies for platform support, to set clear policies and expectations for individual distributions, too; I wouldn't, for example, ever expect to see Gentoo builds on swift.org, but it'd be helpful to know whether distributions outside of the official ones are officially in "you're on your own" territory — both as a user of Swift, and as a package maintainer.

8 Likes
16

The following existing platforms are in Tier 1 regardless of any text in this document:

  • All Apple platforms (macOS, iOS and so on).
  • Linux
  • Windows

This may need more details. For example, we’re using Linux on armv7. We’d love it to be tier 1, but at this point I don’t think that is realistic.

1 Like
17

Yes, I think that's accurate.

Agreed (though Foundation probably will have much the same API surface everywhere, as even the decades-old bits of it were designed to be platform agnostic; after all, it used to run on Windows, back in the OpenStep era…).

I think it would likely be better if import Dispatch just didn't work in that kind of case, rather than the import succeeding but not actually providing any API.

We did talk about this a bit when writing the proposal, and it's certainly important for Linux to think about which distributions we support. Other operating systems don't really have the concept of a distribution separate from the platform itself, so this really is a very Linux-specific thing.

That's a really complicated question. I think when we say Linux is "Tier 1", we mean that Swift should work on at least some set of Linux distros for which we provide official support (currently I think that means UBI9, Amazon Linux and Ubuntu). In terms of other Linux distros like Gentoo, I don't see that as meaning you're entirely on your own — I think we'd accept reasonable patches that make the code more Gentoo-friendly as long as they don't break the distros we're currently officially supporting.

I know that doesn't entirely answer your question, and partly that's because I'm not sure exactly who has responsibility for deciding which Linux distros we officially support…

This is similar in a way to @itaiferber's question. Linux supports — in principle — a huge range of different CPU architectures and there's clearly no way that we will have official support for all of the different combinations of architecture, architecture variant and distribution. I don't even think it's viable to track support for every possible combination.

When we say "Linux is Tier 1", what we mean here is that there is some set of Linux distros, with some set of architectures that we care about, that meet (or should meet) the requirements in the document. That set of architectures and distributions can and will change over time; the same is true for the other platforms — it's just most visible for Linux.

My thinking here is that when we publish our list of platforms and tiers on swift.org, for platforms like Linux we'll likely include a list of triples and/or distributions that we actively support. I suppose if someone had done a bunch of work on supporting e.g. S390 Linux or ColdFire Linux or some other weird architecture, we could use this same process to add to the list of triples, and maybe likewise on the Linux distribution front. I don't know that we need to state that in the document explicitly though.

18

I agree with the general sentiment above - Linux is too broad to mention for Tier 1, we should be specific and not treat Linux as one platform (i.e. call out what distributions are Tier 1). That opens the door for other distributions to have a path to becoming a tier 1 supported platform, and make it obvious which distributions are only experimentally supported.

I’m assuming that Tier 2 includes the requirements from Tier 3 and Tier 1 includes all the requirements from Tier 2 (and Tier 3). Because currently there’s no written explicit requirement for Tier 1 platforms to support the standard library etc.

I also would like to see what exactly are “Swift Core Libraries” - because without a definitive list there are repos and libraries that currently live in a grey area. We should be explicit about what those core libraries are.

An important aspect of Tier 1 platforms is that maintenance of support of these platforms is the collective responsibility of the Swift project as a whole, rather than falling entirely on the platform owner

This is an important part, but doesn’t provide any timescales. I’m not proposing we introduce strict SLAs but when bugs are discovered, how do we go about getting them fixed. E.g. strict memory checking doesn’t work on Windows. How do we escalate issues like that and ensure they are fixed?

7 Likes
19

We ought to be specific about Apple platforms and Windows too. We don't support Mac OS X 10.4 on PowerPC, obviously. Nor do we support Windows NT on DEC Alpha.

4 Likes
20

I think this'd be great to call out explicitly in the doc, then!

I personally agree with @0xTim that it may not make sense, then, to treat "Linux" as a single platform — but if we're moving forward with the nomenclature anyway, then it'd be great to at least very clearly call out what that means.

3 Likes