Hi everyone,
I am currently implementing the new Search API in a UIKit app using @AppIntent(schema: .system.search), ShowInAppSearchResultsIntent, and UISceneAppIntent. While testing on the iOS beta, I’ve hit a significant lifecycle disparity between how UIKit and SwiftUI apps process system intents during a process-cold launch.
According to the documentation for UIScene.ConnectionOptions.appIntent, this property should contain the intent that triggered the scene creation. However, in a UIKit app with a single-window scene lifecycle, this isn't happening consistently.
Here is the behaviour breakdown I am seeing:
Cold Launch (Siri/Search → App completely closed)
- SwiftUI App: Works as documented. The intent is present in connection options. scene(_:willPerformAppIntent:) is not called.
- UIKit App (with AppIntentSceneDelegate): The connectionOptions.appIntent property is completely nil inside scene(:willConnectTo:options:). Instead, the intent is delivered late via scene(:willPerformAppIntent:) right after scene connection completes.
Warm Launch (Siri/Search → App already suspended in memory)
- Both SwiftUI and UIKit: Behave identically. The intent is delivered directly to scene(_:willPerformAppIntent:).
The Problem
Because of this gap, there is no unified way to handle a process-cold launch under UIKit. There is no LaunchOptionsKey available to identify that an App Intent initiated the launch, and the missing connection option forces us to bifurcate our routing logic.
I have already filed a bug report via Feedback Assistant: FB24513291 and attached a minimal reproducible sample project.
Has anyone else run into this specific AppIntentSceneDelegate race condition on the iOS beta? If so, what architecture or unified pattern are you using to normalize the lifecycle routing between cold and warm launches in UIKit?
Any insights or clean workaround ideas would be highly appreciated!