fix(core): custom application delegate scene wiring and non-scene launch timing - #11367

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

Two follow-up fixes to #11181, both on iOS.

1. A custom application delegate broke scenes entirely

Current behavior

The two scene-related UIApplicationDelegate methods — applicationConfigurationForConnectingSceneSessionOptions and applicationDidDiscardSceneSessions — were installed only on the built-in Responder class at module load. The delegate setter just stored whatever it was given, and run() hands that class to UIApplicationMain.

So an app doing Application.ios.delegate = MyDelegate — common for push tokens, openURL, or an SDK that requires it — gave iOS a delegate with no scene methods at all, no scene configuration was ever returned, and scenes were dead. There is no workaround by subclassing: NativeScript cannot extend an already-extended native class, so class MyDelegate extends Responder is not available.

New behavior

The defaults are installed on whichever delegate class is in use, per method and only when absent, so a delegate that brings its own implementation still wins.

For the case where you want to handle some of it yourself and leave the rest to NativeScript, the defaults are now public and take the same arguments as the delegate methods:

@NativeClass()
class MyDelegate extends UIResponder implements UIApplicationDelegate {
  static ObjCProtocols = [UIApplicationDelegate];

  applicationConfigurationForConnectingSceneSessionOptions(app, session, options) {
    if (session.role === someCustomRole) {
      return myOwnConfiguration;
    }
    return Application.ios.defaultSceneConfiguration(app, session, options);
  }
}

defaultDiscardSceneSessions(application, sceneSessions) is available the same way.

Also handled:

• window accessor. Responder provides one; a custom delegate loses it, and UIKit queries delegate.window on non-scene apps. One is installed only when the class has no prototype-level window at all. It stores what is assigned rather than copying Responder's NOOP setter — silently swallowing this.window = x on someone's own class would be worse than the original breakage.
• static ObjCProtocols. Without it the ObjC runtime may never dispatch to the class. Protocols are a one-time class-build parameter, so this cannot be added after the fact — assigning a delegate class that does not declare UIApplicationDelegate now warns once, loudly, telling you to add the line.
• Timing. The delegate is consumed by UIApplicationMain inside run(); assigning one afterwards warns, since it can no longer take effect.

Worth noting for anyone reading this who only wants to customise scene configuration: configureForScenes() already covers that without a custom delegate — the default consults it first and honours whatever it returns. This fix is for apps that need a custom delegate for unrelated reasons and lost the scene wiring as collateral.

2. launch no longer fired at didFinishLaunching on a background launch

Current behavior

#11181 changed two things about the non-scene startup path when only one was intended. shouldDelayLaunchEvent became a no-op, and the first window's content — and with it the legacy launch event — became automatically deferred whenever applicationState was Background at launch.

Previously the default fired launch and built the root view in applicationDidFinishLaunching regardless of background state, and deferral was strictly opt-in through the flag. Plugins rely on launch arriving at didFinishLaunching, background launches included — a silent push, for instance, needs handlers registered before it is processed.

New behavior

The automatic background deferral is gone. Content resolves in applicationDidFinishLaunching again, and delaying it is opt-in through shouldDelayLaunchEvent, which remains deprecated but works as it always did for non-scene apps.

ready is unchanged: still raised in didFinishLaunching on every path, before any window is registered.

Two pieces of deprecation text were factually wrong and are corrected — shouldDelayLaunchEvent's "has no effect", and launchEvent's claim that it does not fire for background launches, which now holds only for scene-based apps.

Tests

413 → 419 passing. The launch-timing specs drive the real didFinishLaunchingWithOptions and didBecomeActive on a fresh iOSApplication, and were mutation-verified: restoring the background check fails exactly the two tests that pin the restored behavior.

No new import cycles (unchanged at android 89 / ios 88).

Not covered by CI

Device-only: that protocol conformance actually reaches the installed IMPs on a custom delegate class, UIApplicationMain behavior with one, and a real background launch (silent push) firing launch at didFinishLaunching.