Consider continuing to use FlutterLaunchEngine for FlutterImplicitEngine callback

[vashworth]

Currently, when migrating to UIScene, you add the FlutterImplicitEngineDelegate to your AppDelegate and add a didInitializeImplicitFlutterEngine callback. This callback is called when the FlutterEngine is created by the FlutterViewController, primarily from a storyboard.

- @objc class AppDelegate: FlutterAppDelegate {
+ @objc class AppDelegate: FlutterAppDelegate, FlutterImplicitEngineDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
-    GeneratedPluginRegistrant.register(with: self)
    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }

+   func didInitializeImplicitFlutterEngine(_ engineBridge: FlutterImplicitEngineBridge) {
+     GeneratedPluginRegistrant.register(with: engineBridge.pluginRegistry)
+   }
}

flutter/engine/src/flutter/shell/platform/darwin/ios/framework/Source/FlutterViewController.mm

Line 308 in 72cfdc7

BOOL performedCallback = [_engine performImplicitEngineCallback];

This change was made due the Storyboard initializing later in the lifecycle than before. It now initializes after application:didFinishLaunchingWithOptions:.

However, due to this, plugins cannot receive application:didFinishLaunchingWithOptions: event because the engine is not created yet.

To work around this, we call those methods once the engine is created by the storyboard

flutter/engine/src/flutter/shell/platform/darwin/ios/framework/Source/FlutterViewController.mm

Lines 318 to 329 in 72cfdc7

	// When migrated to scenes, the FlutterViewController from the storyboard is initialized after the
	// application launch events. Therefore, plugins may not be registered yet since they're expected
	// to be registered during the implicit engine callbacks. As a workaround, send the app launch
	// events after the application callbacks.
	if (self.awokenFromNib && performedCallback && FlutterSharedApplication.hasSceneDelegate &&
	[appDelegate isKindOfClass:[FlutterAppDelegate class]]) {
	id applicationLifeCycleDelegate = ((FlutterAppDelegate*)appDelegate).lifeCycleDelegate;
	[applicationLifeCycleDelegate
	sceneFallbackWillFinishLaunchingApplication:FlutterSharedApplication.application];
	[applicationLifeCycleDelegate
	sceneFallbackDidFinishLaunchingApplication:FlutterSharedApplication.application];
	}

However, this seem to be problematic:

• BGTaskScheduler requires Registration of all launch handlers must be complete before the end of [applicationDidFinishLaunching(_:)
  • https://developer.apple.com/documentation/backgroundtasks/bgtaskscheduler/register(fortaskwithidentifier:using:launchhandler:)
  • Add UIScene life cycle support Dev-hwang/flutter_foreground_task#376

May also be related: #183900

When first investigating UIScene, FlutterLaunchEngine was introduced. This allowed plugins to still be registered in application:didFinishLaunchingWithOptions: by creating a FlutterEngine and saving it to the FlutterAppDelegate, which can be accessed via the singleton app instance. Then once the FlutterViewController initializes, it will “take” the FlutterEngine from the FlutterAppDelegate instead of creating one.

There was some disagreement on the API, though, which is why we changed to this.

https://flutter.dev/go/ios-ui-scene-lifecycle-migration
go/flutter-ios-uiscene-delegate-adoption-v1

I wonder if there's some way we could still use the FlutterLaunchEngine but still with the FlutterImplicitEngineDelegate

[VaradGupta23]

This is a tricky situation.

The current approach with FlutterImplicitEngineDelegate makes sense for the UIScene lifecycle, but it does feel like we’re working around the timing issue rather than solving it. Especially with things like BGTaskScheduler, where registration really has to happen during application:didFinishLaunchingWithOptions:.

The earlier FlutterLaunchEngine idea seemed cleaner in that regard, since it guarantees the engine exists early enough for plugins to hook into the app lifecycle properly. The downside was API complexity, but from a behavior standpoint it feels more predictable.

Maybe there’s a middle ground where:

• the engine is still created early (like FlutterLaunchEngine)
• but the delegate/callback approach is preserved for flexibility

Right now it feels like plugin authors have to be aware of these timing quirks, which isn’t ideal.

Curious if others have run into issues with lifecycle-dependent plugins because of this.

[inceptusp]

yeah, I stumbled upon this because we have an internal developed plugin that needs to run code at didFinishLaunchingWithOptions exactly (or just after it, but before anything else) , if the code runs later, it does not work and, after migrating to UIScene, it, obviously, stopped working. I have made it work again with a very ugly workaround so I'm looking forward for this.

Also, in the subject of plugin initialization and the Delagate callbacks, can you please take a look at #74024? Our plugin is one suffering the consequences of that issue... We worked around it by manually calling its didFinishLaunchingWithOptions method from inside the AppDelegate one, which was also made difficult to do with the UIScene change and the problem described in this issue since the plugin instance is not initialized by didFinishLaunchingWithOptions anymore.

The workaround to #74024 looks something like (before UIScene):

import UIKit
import Flutter
import plugin

@main
@objc class AppDelegate: FlutterAppDelegate {
    override func application(
        _ application: UIApplication, 
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        GeneratedPluginRegistrant.register(with: self)
        
        // * THIS SHOULD NOT BE HERE. IT IS A WORKAROUND DUE TO https://github.com/flutter/flutter/issues/74024
        Plugin.instance?.application(application, didFinishLaunchingWithOptions: launchOptions)
        
        return super.application(application, didFinishLaunchingWithOptions: launchOptions)
    }
}

After migrating to UIScene, the ugly workaround I mentioned, involves saving the parameters from didFinishLaunchingWithOptions into vars and moving the Plugin.instance?.application call to didInitializeImplicitFlutterEngine, which runs just after didFinishLaunchingWithOptions:

import UIKit
import Flutter
import plugin

@main
@objc class AppDelegate: FlutterAppDelegate, FlutterImplicitEngineDelegate {
    private var app: UIApplication?
    private var lOpts: [UIApplication.LaunchOptionsKey: Any]?
    
    func didInitializeImplicitFlutterEngine(_ engineBridge: FlutterImplicitEngineBridge) {
        GeneratedPluginRegistrant.register(with: engineBridge.pluginRegistry)
        
        // * THIS SHOULD NOT BE HERE. IT IS A WORKAROUND DUE TO https://github.com/flutter/flutter/issues/74024
        Plugin.instance?.application(app!, didFinishLaunchingWithOptions: lOpts)
    }
    
    // default AppDelegate
    override func application(
        _ application: UIApplication, 
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        app = application
        lOpts = launchOptions
        
        return super.application(application, didFinishLaunchingWithOptions: launchOptions)
    }
}

By not calling it manually, it falls into #74024 problem and this one (if we remove all other plugins from the equation so it bypasses #74024)

[hellohuanlin]

Looks like didInitializeImplicitEngine being called by FlutterVC is originated from the original design doc:

class UserAppDelegate {
  func didFinishLaunching() {
    launchRegistrant = self
    super.didFinishLaunching()
  }

  func registerPlugins(viewController) {
    GeneratedPluginRegistrant.register(viewController)
    makePlatformChannel(viewController)
  }
}

It seems that the purpose if the delay was to be able to access the VC (thus it waits the registration until the VC is created). However, given that we are not accessing the VC in implicit engine callback now, we could call it before didFinishLaunching returns.

Though if we go this route, it means we can't add the VC to FlutterImplicitEngineBridge anymore for #186971 (since VC hasn't been created in didFinishLaunching). We would have to come up with a new protocol and send the VC via a different method (e.g. func didInstantiateFlutterVC).

Since decisions in these 2 issues affect each other, I'm gonna write up a quick doc and compare a few options.