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.