Bug 294412 – [Swift] Availability versions are inaccurate in downlevels

• Component: Tools / Tests
• Status: NEW

[Elliott Williams]

In ObjC, `postprocess-headers-rule` strips out API_AVAILABLE attributes at build time, so that downlevel builds of Safari are not restricted from accessing WebKit API that shipped in more recent OS versions. While https://bugs.webkit.org/show_bug.cgi?id=294361 addresses _TBA_ versions being usable by downlevel builds, it doesn't propose a fix for _shipped_ APIs become inaccessible in Safari.

[Radar WebKit Bug Importer]

<rdar://problem/153851259>

[Alexey Proskuryakov]

> downlevel builds of Safari are not restricted from accessing WebKit API that shipped in more recent OS versions

This sounds like correct behavior to me, Safari should be able to use new APIs from aligned WebKit builds, even when deploying to an OS where ethernet system WebKit doesn't have them.

Sometimes new APIs only work on newer OSes, but we'd need a different kind of annotation for this, if it's actually an important problem to solve (I'd expect that such targeted API use would be cleanly conditionalized at caller site already).

[Elliott Williams]

Right. In ObjC, one can write

    -(void)myAPIThatHasAlreadyShipped WK_API_AVAILABLE(macOS(26.0), iOS(26.0));

and because it's using WK_API_AVAILABLE, we strip the annotation entirely when building downlevels. So a downlevel targeting macOS 15 would still be able to call this method.

In Swift, we have no WK_API_AVAILABLE-esque macro that we can turn off at build time. One would write

    @available(macOS 26.0, iOS 26.0, *)
    func myAPIThatHasAlreadyShipped()

and it would be disallowed in the same downlevel build.

[Elliott Williams]

One solution could be to come up with custom availability macros that we can retarget at build time. For example:

    @available(WebKit26_0)
    func myAPIThatHasAlreadyShipped()

where we compile with:

    swiftc ... -define-availability 'WebKit26_0 : macOS 26.0, iOS 26.0, visionOS 26.0'

In that downlevel build for Sequoia we'd compile with:

    swiftc ... -define-availability 'WebKit26_0 : macOS 15.4, iOS 15.4'

This would also have the advantage of saving everyone some typing by consolidating the different platforms into one availability macro.

[Elliott Williams]

And a custom availability macro would make it easier to implement https://bugs.webkit.org/show_bug.cgi?id=280912, which entails adding watchOS and tvOS availabilities to everything.