fix(ios): use minimal windowing control style on iPadOS 26 - #1250
Conversation
Package Changes Through 118c980There are 1 changes which include tao with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
eb8574e to
118c980
Compare
|
@FabianLars This now forces Tao to use the correct windowing mode on iOS 26 (and is compatible with iOS 27). |
FabianLars
left a comment
There was a problem hiding this comment.
i have no means to test this atm but looks safe enough
I've verified this with local debug + release builds and a CI/CD build pushed to TestFlight. |
Resolves tauri-apps/tauri#15521
Description
iPadOS 26 adds macOS-style system window controls to the top-left corner of every windowed scene. Because a Tao window hosts a fullscreen
WKWebViewwith no native toolbar, these controls do not contribute to the safe area and float on top of, overlapping, the web content. There is no native toolbar for them to integrate with.Fix
Implement
UIWindowSceneDelegate's optionalpreferredWindowingControlStyle(for:)method onTaoSceneDelegate, returning theminimalstyle. Theminimalstyle places the controls in a safe-area strip above the content instead of floating over it. This is the same approach taken by Flutter and Capacitor.No runtime version check is needed:
preferredWindowingControlStyleForScene:is an optional protocol method the system only sends on iPadOS 26+, and theUISceneWindowingControlStyleclass is resolved lazily at call time. On earlier iOS versions the conformance is inert and nothing changes.This also enables the
UISceneWindowingControlStyleandUIWindowScenefeatures onobjc2-ui-kitand bumps theobjc2crate family0.3.0->0.3.2, since theUISceneWindowingControlStyletype does not exist in0.3.0. The bump is patch-level and the macOS build is unaffected.Testing
cargo check --target aarch64-apple-ios -p taocompiles with no errors.cargo check -p tao(macOS host) still compiles, confirming the dependency bump does not regress the desktop build.Related
madsmtm/objc2#849