Scene-based Launch Detection

Our app supports UIScene. As a result, launchOptions in application(_:didFinishLaunchingWithOptions:) is always nil.

However, the documentation mentions that UIApplication.LaunchOptionsKey.location should be present when the app is launched due to a location event.

Given that our app is scene-based:

How can we reliably determine whether the app was launched due to a location update, geofence, or significant location change?

Is there a recommended pattern or API to detect this scenario in a Scene-based app lifecycle?

This information is critical for us to correctly initialize location-related logic on launch.

Relevant documentation: https://developer.apple.com/documentation/corelocation/cllocationmanager/startmonitoringsignificantlocationchanges()

For apps that support UIScene, the UIApplication launch options will be nil.

Instead the app will be presented with the UIScene.ConnectionOptions.

Not every launch option will have an equivalent connection option.

Specifically for CoreLocation triggered app launches, as after launch there will always be a delegate method that will be called to pass on the information, you can use that as an indicator that your app was launched by CoreLocation and based on the specific method that was called back, you can determine which API has triggered it.

Could you please clarify which specific callback(s) we should rely on as the indicator? We want to make sure we’re detecting the launch source correctly and aligning with the intended behavior.

We are facing the exact same limitation on our side, and not only with CoreLocation but also with background (silent) push notifications.

With a scene-based app, launchOptions is always nil, and while UIScene.ConnectionOptions is supposed to be the replacement, it does not cover all cases. As mentioned by Apple, “not every launch option will have an equivalent connection option” — and background push notifications seem to be one of those missing cases.

In practice, when the app is woken up by a silent push (content-available), there is no reliable way to distinguish this scenario from a normal launch using connectionOptions. This makes it impossible to prevent unintended UI initialization or to branch logic correctly at startup.

Relying on delegate callbacks (like didReceiveRemoteNotification) helps once the app is already running, but it does not solve the initial launch ambiguity — especially when the app is relaunched in the background.

So overall, we fully agree with the original concern: there is currently no clear or reliable way to determine the true launch reason in a Scene-based lifecycle for certain triggers (location, silent push, etc.), which makes some use cases very hard to implement correctly.

Would be great to have clarification or an official recommended pattern from Apple for these scenarios.

Any developer who is adversely affected by the lack of options in UIScene.ConnectionOptions should file a Bug Report about this for consideration.

Bug Reporting: How and Why? has tips on creating a successful bug report.

Scene-based Launch Detection
 
 
Q