chore(cli): enable iOS scenes lifecycle by default

[lucasfernog]

this will be enforced on iOS 27

[github-actions]

Package Changes Through bff1ef7

There are 11 changes which include tauri with minor, @tauri-apps/api with minor, tauri-macos-sign with patch, tauri-build with minor, tauri-bundler with minor, @tauri-apps/cli with minor, tauri-cli with minor, tauri-runtime with minor, tauri-runtime-wry with minor, tauri-utils with minor, tauri-plugin with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
@tauri-apps/api	2.10.1	2.11.0
tauri-utils	2.8.3	2.9.0
tauri-macos-sign	2.3.3	2.3.4
tauri-bundler	2.8.1	2.9.0
tauri-runtime	2.10.1	2.11.0
tauri-runtime-wry	2.10.1	2.11.0
tauri-codegen	2.5.5	2.5.6
tauri-macros	2.5.5	2.5.6
tauri-plugin	2.5.4	2.6.0
tauri-build	2.5.6	2.6.0
tauri	2.10.3	2.11.0
@tauri-apps/cli	2.10.1	2.11.0
tauri-cli	2.10.1	2.11.0

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[lucasfernog]

follow-up for #14484

[FabianLars]

am i stupid or is "enable iOS scenes lifecycle" and "UIApplicationSupportsMultipleScenes" not the same? Do you have any sources for that? I see that the scenes framework will be required but also requiring every app to support multiple scenes/windows sounds insane to me (but then again, we're talking about apple)

[FabianLars]

Also, how does this affect devs that did not adapt to our multi-window api? Does tauri handle the implications internally?

[JeffTsang]

Here's the relevant documentation:
https://developer.apple.com/documentation/technotes/tn3187-migrating-to-the-uikit-scene-based-life-cycle

There are two ways to migrate to the scene-based life cycle:

1. Add a UIApplicationSceneManifest key with a scene configuration in the Info.plist file
2. Implement the application(_:configurationForConnecting:options:) method in the app delegate

Supporting multiple scenes is optional, so UIApplicationSupportsMultipleScenes does not have to be set to true unless the app supports two or more scenes simultaneously.

[lucasfernog]

we use the scene lifecycle (application(_:configurationForConnecting:options:) method) when the plist property is enabled:
https://github.com/tauri-apps/tao/blob/3ecc2a833fc9746acfd2dc3bbf9200bc036cc2fd/src/platform_impl/ios/view.rs#L750
https://github.com/tauri-apps/tao/blob/3ecc2a833fc9746acfd2dc3bbf9200bc036cc2fd/src/platform_impl/ios/scene.rs#L41

Also, how does this affect devs that did not adapt to our multi-window api? Does tauri handle the implications internally?

if you're only creating a single view, nothing will change - but the OS will show a "create new window" entry when you press the app icon on iPad, and well you won't handle the event so it'll open a blank window

[FabianLars]

but the OS will show a "create new window" entry when you press the app icon on iPad, and well you won't handle the event so it'll open a blank window

This sounds quite bad honestly considering that we're now forcing that "optional" property on everyone.

Can't we register the delegate method regardless of the info plist value and give devs the option whether or not they want to support multiple scenes?

[JeffTsang]

It would be best to allow devs to choose whether to support multiple scenes. Implementing the application(_:configurationForConnecting:options:) method in the app delegate should work regardless of whether multiple scenes are supported.

[lucasfernog]

but the OS will show a "create new window" entry when you press the app icon on iPad, and well you won't handle the event so it'll open a blank window

This sounds quite bad honestly considering that we're now forcing that "optional" property on everyone.

Can't we register the delegate method regardless of the info plist value and give devs the option whether or not they want to support multiple scenes?

I'll give it a try later, let's pause this PR in the meantime.