294412 2025-06-12 15:25:17 -0700 [Swift] Availability versions are inaccurate in downlevels 2026-02-13 16:56:03 -0800 1 1 1 Unclassified WebKit Tools / Tests WebKit Nightly Build Unspecified Unspecified NEW InRadar P2 Normal --- 1 emw webkit-unassigned ap richard_robinson2 webkit-bug-importer oldest_to_newest 2123377 0 emw 2025-06-12 15:25:17 -0700 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. 2124775 1 webkit-bug-importer 2025-06-19 15:26:12 -0700 <rdar://problem/153851259> 2124782 2 ap 2025-06-19 16:13:51 -0700 > 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). 2181573 3 emw 2026-02-13 16:49:39 -0800 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. 2181577 4 emw 2026-02-13 16:54:34 -0800 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. 2181582 5 emw 2026-02-13 16:56:03 -0800 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.