How exactly are you determining that a notification is what triggered the launch? Is this through "UIApplicationLaunchOptionsRemoteNotificationKey" or something else? How is the payload for your push configured and, more specifically, are you including "content-available" on regular pushes? What priority are you using and does your app include a notification service extension? We determine that this background launch was triggered by a remote notification via UIApplicationLaunchOptionsRemoteNotificationKey, the value corresponding to UIApplicationLaunchOptionsRemoteNotificationKey is almost identical to the other regular notifications, and we did not use 'content-available'. Our app does include a notification service extension.

The issue is not with the background launch itself, but rather that we would like clear documentation to understand what behaviors trigger a background launch. For example, according to the documentation, silent notifications are supposed to launch the app in the background, but in actual scenarios, I have found that regular notifications can also trigger the background launch of the app. Therefore, I hope there can be a list that provides at least some clarity on the situations in which the app can launch from the background, so that we know not only what happens but also why it happens.

I've attached the full crash report generated by Metric, thanks for your help! sharesheet_hang_crash_log.txt

Thanks again~ What we really need here is an "applicationWillSuspend" API/delegate, that would actually tell your app "we're going to suspend your app" without artificially extending your apps lifecycle (like a background task would). I'd appreciate it if you would file a enhancement request asking for this, then post the bug number back here. I have file a feedback regarding the suggestion for an "applicationWillSuspend" API, and please let me know if there are any inaccuracies in my feedback. Use MetricKit or a service* that's built on it. Whatever disadvantages it may have, the simple fact that it's crash reporter will NEVER break your app is an advantage that cannot be overstated. Currently, our application utilizes MetricKit, including diagnostics for disk, CPU, crashes, etc., and we do upload the corresponding information to our server. Today I looked into MetricKit and discovered that starting from iOS 16, it added MXCallStackTree in MXAppLaunchDiagnostic. Could it possibly help in understanding the application's launch reason? A breakthrough discovery! When examining the logs for background launches, I found that some logs contain launchOptions though just a few, which include UIApplicationLaunchOptionsURLSessionKey. However, I couldn't find the meaning of this key in UIApplication.h. The only clue I found was in this forum thread. If you could provide more information on this, it would be greatly appreciated. Part 4, Now Playing, A New Hope Regarding the Now Playing suggestion, I found that switching "Fast App Termination" to "On" didn't work. When I put the app into the background and then reopen it, it does not restart, so I couldn't really test that case.

Thank you very much for your response! Let me first describe the overall startup process of my application, how we determine abnormal exits, and how we identify background launches. In application:didFinishLaunchingWithOptions:, we conduct the overall startup process of the application. We log every key path within this process, and we print the UIApplication.appState to determine the application’s foreground and background states at each key point. Additionally, we log many key paths during the user's interactions, which also include UIApplication.appState. In various lifecycle APIs of AppDelegate, we also print logs to confirm the overall lifecycle of the application. Due to historical reasons, our application does not use SceneDelegate. To determine abnormal exits, when application:didFinishLaunchingWithOptions: is called, we start listening for foreground and background notifications, UIApplicationWillTerminateNotification, and atexit. We only write a file named "normalExitFile" when receive UIApplicationDidEnterBackgroundNotification, UIApplicationWillTerminateNotification, or atexit. When the application starts, we first check whether the "normalExitFile" exists and whether a crash occurred last time (we also write a file when we received crash signals). If both are absent, we conclude that the user had an abnormal exit last time. At this point, we report the user logs to the server, delete the "normalExitFile" to reset the application to its initial state, and then begin listening for the next lifecycle processes (foreground and background notifications, UIApplicationWillTerminateNotification, atexit). Starting from May, the quantity of these abnormal log reports surged. We noticed that a small portion of the logs had appState aligning with our expectations, transitioning from UIApplicationStateInactive to UIApplicationStateActive, and the final logs were all UIApplicationStateActive, with no logs indicating a background transition (logs indicating transitions to the background also had corresponding logs for returning to the foreground). We consider these logs to be normal, indicating that the user experienced an abnormal exit. However, for the majority of the other logs, the appState remained UIApplicationStateBackground throughout, with no UIApplicationStateInactive printed, or any other lifecycle log prints. This suggests that from the moment application:didFinishLaunchingWithOptions: was called, the UIApplication.appState has consistently been UIApplicationStateBackground. From the logs, we can confirm that application:didFinishLaunchingWithOptions: was invoked. Particularly while determining whether it was a background launch, I added logs of user actions (whether user had clicked somewhere last time) and periodic logging (To check if the UIApplication.appState has change). For these background launch logs, it's clear that no user click events occurred at any point, and most periodic logs ceased around the 30-second mark. This led me to initially suspect silent notifications, as I read in the documentation that silent notifications provide the application with 30 seconds to process. However, the logs printed in userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler: did not appear in the background launch logs, so can I rule out silent notifications as the cause? Do you become the "Now Playing" app? Now playing apps can also be launched into the background and (I think?) PiP support requires "Now Playing". We do use the Now Playing feature, but that was introduced in January last year, which doesn't align with the timing this May. Of course, it could be that there is increased usage of Now Playing in some business flows. Is there a way to determine if Now Playing triggered the background launch? Or with more information I provided, do you have any other suspects? Thanks for your time.

Our application has an SDK that detects whether the user last exited abnormally. Simply put, if the app is quit from the foreground and does not receive the willTerminate callback, and there is no crash stack, it is deemed an abnormal exit. In May of this year, the reports of abnormal exits suddenly surged. Upon investigation, we found that the application was being launched in the background, and during the SDK initialization, it was set to a foreground state, which caused users who were launched in the background to be counted as having exited abnormally in the foreground. We want to clarify the reasons for our application's background launches. I found in the documentation that a few scenarios can cause background launches: Background fetch Remote notifications - Silent notifications App prewarm Analysis: Our application's background modes only enable Audio, AirPlay, Picture in Picture, and Remote notifications, so the possibility of background fetch can be ruled out. As for silent notifications, the code does not have any use cases, but we cannot rule out the possibility that the server sent a silent notification causing the launch. However, in the abnormal exit logs, we do print the launchOptions in application:didFinishLaunchingWithOptions:, but the value is empty. The documentation states that if it is a silent notification, applicationDidEnterBackground: will be called after application:didFinishLaunchingWithOptions:. We can confirm through the logs that this method was not called. Regarding app prewarm, I see that this was introduced after iOS 15. However, the surge in abnormal exits started in May of this year and occurred only after the application was updated to a certain version. The percentage of abnormal exits for older versions did not increase, which suggests it might not be strongly correlated with the iOS system. Therefore, we cannot determine whether the app prewarm caused the application to launch in the background. I would like to ask if there is any method to ascertain if the recent launch was due to prewarm? Or is there any way to log specific API calls to determine the reason for the background launch?