Restrict platforms for packages?

Is it currently possible to restrict platforms for Swift Packages? For example, if I want to explicitly ensure my package is not able to be used with tvOS, for whatever reason.

1 Like

There is no way to declare it in the manifest to affect package resolution.

But you can do the following in any of the source files:

#if os(tvOS)
#error("This package does not support tvOS.")

May I ask why you want to do this?

For the same reason CocoaPods allows it: to make support for a platform on a package I maintain explicit, to improve discoverability for new packages (especially in GitHub or Dave Verwer’s site and other examples sure to pop up), to ensure a new dependency can support the platforms my product is being built on, etc.

If you (or really anyone) thinks these reasons are invalid, can you tell me why? I could just be thinking about this the wrong way.

Explicitly opting in would make much more sense to me—or at least being able to explicitly opt out.

I could see doing something like .tvOS(.unsupported), or making it so if you list one platform you have to be explicit for the rest.

I have no opinion of my own, but I can provide a few links If you are curious about the history of the API for specifying platforms.

Here is the proposal that added platform specification:

Here is its review:

And here is its acceptance:

Thanks Jeremy, this is extremely helpful context.

This is exactly what I was wondering:

Restricting supported platforms: Some packages are only meant to work on certain platforms. This proposal doesn't provide ability to restrict the list of supported platforms and only allows customizing the deployment target versions. Restricting supported platforms is orthogonal to customizing deployment target and will be explored separately.

I wonder if this exploration ever occurred otherwise?

It hasn’t been revisited yet. (At least not on this forum.)

1 Like

What happens if you require a minimum version that doesn't exist? Like 999.0?

Then, as with #error, clients will be unable to build it. But #error at least allows you to provide a meaningful explanation.

Note that either may bite back if some tool wants to build for multiple things at once and fails to provide a way to opt out of a platform. (I have heard rumours to this effect about Xcode + XCFrameworks, but I haven’t tested it myself.)

The absolute safest way, (albeit most repetitive and annoying as a vendor) is probably to surround all the sources in #if os(WhatIActuallySupport). That way clients that do want to support another platforms can still safely import your package, using it were possible and filling in the rest with some alternate dependency. If you actively block compilation, they do not have this option—they must either drop the platform, or drop your package.