feat(config): allow macOS fullscreen and transparent APIs to be enabled independently

[tenderdeve]

Closes #15487

macOSPrivateApi currently couples two unrelated capabilities: it enables the WKWebView fullscreen API and transparent webview backgrounds. Apps that only need fullscreen are forced to also opt into the transparent-background private API. wry already exposes these as separate fullscreen / transparent features, so this splits them at the Tauri layer too.

Changes

• New config options app > macOS > fullscreenApi and app > macOS > transparentBackgroundApi.
• New Cargo features macos-private-api-fullscreen (→ wry/fullscreen) and macos-private-api-transparent (→ wry/transparent).
• macOSPrivateApi kept as-is; it now enables both sub-features, so existing configs are unchanged.
• AppConfig::features() emits only the sub-feature(s) the config actually needs.
• Transparent-only cfg gates in tauri/tauri-runtime-wry retargeted to macos-private-api-transparent; fullscreen is compile-time via wry/fullscreen.
• Regenerated config schema.

Testing

• cargo test -p tauri-utils (config tests pass).
• cargo check -p tauri -p tauri-runtime-wry under each of the three feature combinations.

[velocitysystems]

Great work @tenderdeve. I also know another contributor was looking into this. Any thoughts or feedback @polw1?

[velocitysystems]

Recommend we match the naming of the crate feature flags:

• privateApiFullscreen
• privateApiTransparent

Prefixing them with privateApi* makes it immediately obvious the user is opting into a private API.

[polw1]

One thing about this feature mapping:

I understand this is technically fine today because this is in tauri-runtime, but at the same time, reading that the new transparent-only feature enables the old macos-private-api feature can feel a bit confusing at first.

It also means tauri-runtime/macos-private-api effectively has to keep meaning “transparent support”.

Maybe that tradeoff is perfectly fine if we do not expect more macOS private API gates in tauri-runtime.

But from an API design perspective, I wonder if it would be clearer to mirror the split in tauri-runtime too and keep the old feature as an alias:

macos-private-api = ["macos-private-api-transparent"]
macos-private-api-transparent = []

That would keep compatibility while making the mapping read more directly:

tauri/macos-private-api-transparent
-> tauri-runtime/macos-private-api-transparent
-> tauri-runtime-wry?/macos-private-api-transparent
-> wry/transparent

Not a blocker from my side, mostly a naming/design tradeoff that maintainers may have a better feel for

[polw1]

Should we also update the crate-level feature docs in crates/tauri/src/lib.rs?

The existing macos-private-api feature is documented there, but these two new public features (macos-private-api-fullscreen and macos-private-api-transparent) are not listed yet.

Since users can now enable them directly, it may be useful to document them next to the existing legacy macos-private-api entry so they show up clearly in the generated crate docs

[tenderdeve]

thanks for the review both

@polw1 added the docs for the two new features in fea51b2, sat them right next to the existing macos-private-api entry in lib.rs.

re mirroring the split into tauri-runtime - i left it on the umbrella name because tauri-runtime's own gates (window.rs / webview.rs) still cfg on macos-private-api, so making it read -transparent all the way down means renaming those cfg attrs too. don't mind doing that but since you said it's non-blocking / a maintainer-feel thing i'll leave that call to them rather than touch the runtime gates unprompted.

@velocitysystems the keys currently sit under app > macOS > { fullscreenApi, transparentBackgroundApi } and are documented as private-api opt-ins. can rename to privateApiFullscreen / privateApiTransparent no problem, just want a maintainer ok first since it's public config schema. will change it as soon as there's a thumbs up.