[firebase_messaging][iOS] getToken intermittently takes 3.5–6s force-close during startup token flow can lead to prolonged no-push state

[yangheecho]

Is there an existing issue for this?

• I have searched the existing issues.

Which plugins are affected?

Messaging

Which platforms are affected?

iOS

Description

After migrating iOS to UIScene (FlutterImplicitEngineDelegate + UIApplicationSceneManifest),
Correction: In our case, this does not appear to be strictly UIScene-migration-specific.

What changed on our side is the Flutter upgrade:

• Flutter was upgraded from 3.35.2 to 3.41.6.
• Current project Flutter version is 3.41.6 (.fvmrc / .fvm_config.json).

From our observations, the issue started after this Flutter version upgrade window.

FirebaseMessaging.getToken() frequently takes 3500ms ~ 6000ms (more than ~50% of cold starts in our testing).
During repeated launch/force-close cycles, push delivery can enter a broken state (foreground/background/terminated all not receiving), and in some sessions onTokenRefresh does not fire even after long foreground wait.

APNs registration is usually fast, but getToken() latency is highly variable and seems to correlate with the no-push state.

Reproducing the issue

1. Fresh install (or clear app data).
2. Launch app on iOS physical device and allow notification permission.
3. Startup calls (async):
   • iOS: wait for getAPNSToken()
   • then call getToken()
4. While getToken() is still pending (slow case), force-close the app.
5. Relaunch and test push delivery.
6. Result: push may stop arriving in all states (foreground/background/terminated).

Code sample (sanitized)

Future<void> initializeFcmTokenLifecycle() async {
  await Firebase.initializeApp();
  await FirebaseMessaging.instance.setAutoInitEnabled(true);

  final settings = await FirebaseMessaging.instance.requestPermission(
    alert: true,
    badge: true,
    sound: true,
    provisional: false,
  );
  final isAuthorized =
      settings.authorizationStatus == AuthorizationStatus.authorized ||
      settings.authorizationStatus == AuthorizationStatus.provisional;
  if (!isAuthorized) return;

  FirebaseMessaging.instance.onTokenRefresh.listen((newToken) async {
    await secureStorage.saveFCMToken(newToken);
    await sendWelcome(pushToken: newToken); // backend token sync
  });

  if (Platform.isIOS) {
    final deadline = DateTime.now().add(const Duration(seconds: 8));
    while (DateTime.now().isBefore(deadline)) {
      final apns = await FirebaseMessaging.instance.getAPNSToken();
      if (apns != null && apns.isNotEmpty) break;
      await Future.delayed(const Duration(milliseconds: 100));
    }
  }

  final stopwatch = Stopwatch()..start();
  final token = await FirebaseMessaging.instance.getToken();
  logger('getToken elapsedMs=${stopwatch.elapsedMilliseconds} token=$token');
}

@main
@objc class AppDelegate: FlutterAppDelegate, FlutterImplicitEngineDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    UNUserNotificationCenter.current().delegate = self
    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }

  override func application(
    _ application: UIApplication,
    didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
  ) {
    Messaging.messaging().apnsToken = deviceToken
    super.application(application, didRegisterForRemoteNotificationsWithDeviceToken: deviceToken)
  }
}

In affected sessions, previously used tokens return server-side errors such as ApnsError(BadDeviceToken, INVALID_ARGUMENT) and FcmError(UNREGISTERED, NOT_FOUND).

Log Output

1) APNs registration is stable/fast (not the bottleneck)

Across multiple launches, APNs token stays the same and registration callback is fast (~95-100ms after first launch):

[2026-04-20T08:02:31Z] didRegisterForRemoteNotificationsWithDeviceToken length=32 elapsedMs=815 token=35f8cee6...ceb19cac(64)
[2026-04-20T08:02:44Z] didRegisterForRemoteNotificationsWithDeviceToken length=32 elapsedMs=95 token=35f8cee6...ceb19cac(64)
[2026-04-20T08:02:51Z] didRegisterForRemoteNotificationsWithDeviceToken length=32 elapsedMs=98 token=35f8cee6...ceb19cac(64)

2) Normal startup case: getToken returns in ~2.0s and refresh path syncs

This is a successful/healthy cycle:

[2026-04-20T08:02:33.459716Z] [main.fcm.fetch] startup getFCMToken start
[2026-04-20T08:02:33.460255Z] [main.fcm.fetch] apns ready token=35F8CEE6...9CAC(64) elapsedMs=0
[2026-04-20T08:02:35.520007Z] [FirebaseService.getFCMToken] token success=fa4isv8F...nOTQ(142) elapsedMs=2059
[2026-04-20T08:02:35.522910Z] [main.fcm.update] source=onTokenRefresh saved=fa4isv8F...nOTQ(142)
[2026-04-20T08:02:35.608702Z] [main.fcm.update] source=onTokenRefresh welcome sync done

3) Slow startup case: getToken takes ~4.7s and token rotates

This shows high latency and token change in another cycle:

[2026-04-20T08:02:51.791883Z] [main.fcm.fetch] startup getFCMToken start
[2026-04-20T08:02:51.793125Z] [main.fcm.fetch] apns ready token=35F8CEE6...9CAC(64) elapsedMs=1
[2026-04-20T08:02:56.491239Z] [FirebaseService.getFCMToken] token success=fa4isv8F...YMOo(142) elapsedMs=4696
[2026-04-20T08:02:56.495063Z] [main.fcm.update] source=onTokenRefresh saved=fa4isv8F...YMOo(142)
[2026-04-20T08:02:56.527137Z] [main.fcm.update] source=onTokenRefresh welcome sync done

4) Problematic window: getToken started but no success line in this capture

This is the key evidence for "started token flow but no completion observed" (e.g., force-close/interruption window):

[2026-04-20T08:03:02.565053Z] [main.fcm.fetch] startup getFCMToken start
[2026-04-20T08:03:02.565753Z] [main.fcm.fetch] apns ready token=35F8CEE6...9CAC(64) elapsedMs=0
(no matching `FirebaseService.getFCMToken token success` after this in this log capture)

Firebase Core version

4.7.0

Flutter Version

3.41.6

Relevant Log Output

Flutter dependencies

Expand Flutter dependencies snippet

firebase_messaging: 16.2.0
firebase_messaging_platform_interface: 4.7.9
firebase_core: 4.7.0
firebase_core_platform_interface: 6.0.3

Additional context and comments

No response

[SelaseKay]

Hi @yangheecho, thanks for the report. Does the issue persist when you revert to a previous flutter version?

[yangheecho]

@SelaseKay

Yes — I tested by reverting to Flutter 3.35.2 (Dart 3.9.0), and the issue is still reproducible.

Firebase SDK versions used in this rollback test:

• firebase_core: ^3.15.2
• firebase_messaging: ^15.2.10
• iOS native Firebase SDK (CocoaPods): 11.15.0

The latency is better than on 3.41.6, but if I terminate the app very quickly after launch, I can still reproduce the “push not received” state until the app stays foreground long enough for token sync to complete.

From my 3.35.2 test logs:

• Aggregate (startup getFCMToken success path): avg 935.60ms (10 launches), max 3211ms
• APNs registration is usually fast, so this does not look like APNs registration itself is the main bottleneck.

[2026-04-20T12:31:12.875606Z] [main.fcm.fetch] startup getFCMToken start
[2026-04-20T12:31:16.087763Z] [FirebaseService.getFCMToken] token success=fm37Fj54...OvQI(142) elapsedMs=3211

(Here, app restarted before token success was logged.)

[2026-04-20T12:30:49Z] didRegisterForRemoteNotificationsWithDeviceToken length=32 elapsedMs=98

So in short: reverting to 3.35.2 reduces latency, but does not fully eliminate the repro when the app is terminated quickly.

Also, one question:
Is there any supported way (server-side signal, another Firebase product, or iOS background/terminated callback) to reliably confirm whether getToken() completed successfully if the app process is terminated before the Dart side receives the result?

[yangheecho]

Quick update from my side:

I can consistently reproduce this only when installing/running via local dev flow (flutter build ios + flutter install).

In contrast, when the same app is installed from TestFlight or App Store, I don’t observe the same behavior (token invalidation / push stop) under similar test patterns.

Question:
Can FCM/APNs token lifecycle behavior differ depending on installation path (local sideload/dev install vs TestFlight/App Store distribution)?
If yes, are there any known caveats or expected differences we should account for when debugging token invalidation?

[SelaseKay]

Hi @yangheecho, I'm not able to reproduce this. In my case, token is returned almost immediately. Have you tested against other devices? I'll look into this further. I do suspect there isn't much to do in flutterfire to resolve this as we rely strictly on the native SDK's tokenWithCompletion to fetch the fcm token.

[yangheecho]

@SelaseKay Thanks for the quick response.

I was able to reproduce this on other iOS devices as well. However, it only occurs when the app is installed via flutter build + flutter install. With the same code, builds installed normally through TestFlight or the App Store do not reproduce the issue and return the token almost immediately.

Could the installation path affect this behavior?

[google-oss-bot]

Hey @yangheecho. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!