feat(mobile): multi-window support #14484
Conversation
Package Changes Through 00dcedcThere are 6 changes which include tauri-macos-sign with patch, tauri with minor, tauri-runtime-wry with minor, tauri-runtime with minor, tauri-utils with minor, tauri-bundler with patch 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 |
|
here's an example: https://github.com/lucasfernog/tauri-mobile-multi-window-example |
velocitysystems
left a comment
velocitysystems
left a comment
There was a problem hiding this comment.
We're very excited about this feature @lucasfernog. I've left comments on #1154 and #1633. Here are some additional general questions:
Platforms & Compatibility
- How will this affect Tauri's minimum supported versions?(i.e. Requires iOS 13+ and Android 12L)
- What is the fallback behavior for unsupported platforms?
- Which features of the Window API are available vs not available on mobile?
Performance & Resource Management
- How do we intend to handle app lifecycle events? e.g. sleep/resume
- How can we optimize multi-window support so as not to affect battery life?
|
|
||
| #[cfg(feature = "unstable")] | ||
| #[command(root = "crate")] | ||
| pub async fn create_webview<R: Runtime>( |
There was a problem hiding this comment.
While we may not wish to enforce this (since it is device-specific) there is a theoretical limit to the number of web-views which can be created based on the available memory.
If the app begins to use too much memory the OS may mark it for termination particularly if it doesn't respond to memory warnings and attempt to free memory.
There was a problem hiding this comment.
right, that's not something we're worried - otherwise we would need to implement such check for all platforms
|
|
||
| #[cfg(feature = "unstable")] | ||
| #[command(root = "crate")] | ||
| pub async fn create_webview<R: Runtime>( |
There was a problem hiding this comment.
WebViews are full browser engines that continue consuming significant CPU, GPU, and battery resources (15-25% per hour) even when the app is backgrounded, unless explicitly paused through lifecycle event handlers (onPause/onResume on Android or scene lifecycle hooks on iOS).
This can reduce background drain to 1-3% per hour—a critical requirement for app store approval and acceptable user experience.
There was a problem hiding this comment.
for Android the system pauses the activity automatically when it moves to the background.. I would expect iOS to do the same
There was a problem hiding this comment.
@lucasfernog Unlike iOS I don't believe Android automatically pauses the WebView's internal threads or JS timers when the Activity's onPause(..) is called. The Android WebView has explicit methods onPause(..) and pauseTimer(..).
See this SO discussion for further discussion.
There was a problem hiding this comment.
I've implemented that but it didn't help much tauri-apps/wry@0904dc9 (#1633)
i think pauseTimer is something that each user should decide if they want to call or not - they can do so in their TauriActivity subclass.
| } | ||
|
|
||
| #[cfg(desktop)] | ||
| mod desktop_commands { |
There was a problem hiding this comment.
Apps can't currently detect if multi-window is available. Should we add an API like this? e.g.
Typescript
if (await app.supportsMultiWindow()) {
// Create new window
} else {
// Ignore
}Rust
pub fn supports_multi_window() -> bool {
#[cfg(target_os = "iOS")]
{
ios_version() >= 13.0
}
#[cfg(target_os = "android")]
{
android_api_level() >= 32 // Android 12L
}
#[cfg(desktop)]
{
true
}
}
The default minimum version for iOS is already 14+ but min Android is 7, but both are configurable. The
The activity gets replaced on Android (new activity in the stack).
That's something I wanted to do a second pass in the future, most of the APIs can be supported.
That's something the system handles. We can add sleep/resume events per window in the future.
As far as I know there's nothing special we can/need to do. |
Leverages scenes on iOS and Activity embedding on Android.
All window APIs are now exposed on mobile too. Some of them are still ignored though (like setting a title).
iOS
Android
needs tauri-apps/tao#1154 and tauri-apps/wry#1633