Our application has seen a surge in the volume of background launches starting from April and May, and we want to know under what circumstances the application can be launched from the background.
First, here's how I determined background launches: we analyze user logs and append UIApplication.appState to each line of log, finding that every log from the start to the end of user sessions has an appState of UIApplicationStateBackground.
By checking the "ActivePrewarm" in main() and printing the launch options from application:didFinishLaunchingWithOptions:, we found several scenarios for background launches:
launchOptions has a value with the key UIApplicationLaunchOptionsRemoteNotificationKey.
launchOptions has no value and there is no "ActivePrewarm."
launchOptions has no value but has "ActivePrewarm."
I would like to know:
Under what circumstances will notifications trigger a background launch (I cannot replicate this locally)?
Under what circumstances does an application launch in the background and trigger application:didFinishLaunchingWithOptions: but without any launch options?
I hope informations below can provide some insights.
Regarding "ActivePrewarm," I've read various questions and answers in the Apple Developer Forums, such as this thread, which states that "ActivePrewarm" does not trigger application:didFinishLaunchingWithOptions: but occurs due to certain behaviors in the application. I would like to know what behaviors may cause this background launch, as there is no information in the launch options, or how I can identify what behaviors triggered it.
Specifically, based on that same thread, I've tried to gather more information using runningboardd, and I've currently identified two special cases:
When I restart my phone and unlock it after a short period, there is information:
<RBSDomainAttribute| domain:"com.apple.dasd" name:"DYLDLaunch" sourceEnvironment:"(null)">
]>
Every day, at intervals of a few hours, there is information:
<RBSDomainAttribute| domain:"com.apple.dasd" name:"DYLDLaunch" sourceEnvironment:"(null)">
]>
Then, the following similar information follows:
12:15:56.047625+0800 runningboardd Executing launch request for app<{my_bundle_id}((null))> (DAS Prewarm launch)
12:15:56.050311+0800 runningboardd Creating and launching job for: app<{my_bundle_id}((null))>
12:15:56.050333+0800 runningboardd _mutateContextIfNeeded called for {my_bundle_id}
12:15:56.080560+0800 runningboardd app<{my_bundle_id}((null))>: -[RBPersonaManager personaForIdentity:context:personaUID:personaUniqueString:] required 0.000954 ms (wallclock); resolved to {1000, 39E408CF-2E67-4DB0-BF73-CFC5792285CD}
12:15:56.080632+0800 runningboardd 'app<{my_bundle_id}(39E408CF-2E67-4DB0-BF73-CFC5792285CD)>' Skipping container path lookup because containerization was prevented (<RBSLaunchContext: 0xcd8cc9180>)
12:15:56.080939+0800 runningboardd 'app<{my_bundle_id}(39E408CF-2E67-4DB0-BF73-CFC5792285CD)>' Constructed job description:
<dictionary: 0xcd8aa2a00> { count = 19, transaction: 0, voucher = 0x0, contents = *** }
12:15:56.084839+0800 runningboardd [app<{my_bundle_id}((null))>:1649] Memory Limits: active 4096 inactive 4096
<private>
12:15:56.084861+0800 runningboardd [app<{my_bundle_id}((null))>:1649] This process will be managed.
12:15:56.084882+0800 runningboardd Now tracking process: [app<{my_bundle_id}((null))>:1649]
12:15:56.084928+0800 runningboardd Calculated state for app<{my_bundle_id}((null))>: running-active (role: Background) (endowments: (null))
12:15:56.086762+0800 runningboardd Using default underlying assertion for app: [app<{my_bundle_id}((null))>:1649]
12:15:56.086977+0800 runningboardd Acquiring assertion targeting [app<{my_bundle_id}((null))>:1649] from originator [app<{my_bundle_id}((null))>:1649] with description <RBSAssertionDescriptor| "RB Underlying Assertion" ID:33-33-23101 target:1649 attributes:[
<RBSDomainAttribute| domain:"com.apple.underlying" name:"defaultUnderlyingAppAssertion" sourceEnvironment:"(null)">,
<RBSAcquisitionCompletionAttribute| policy:AfterApplication>
]>
12:15:56.087203+0800 runningboardd Assertion 33-33-23101 (target:[app<{my_bundle_id}((null))>:1649]) will be created as active
12:15:56.087946+0800 runningboardd [app<{my_bundle_id}((null))>:1649] reported to RB as running
12:15:56.088053+0800 runningboardd Calculated state for app<{my_bundle_id}((null))>: running-active (role: Background) (endowments: (null))
12:15:56.088114+0800 runningboardd [app<{my_bundle_id}((null))>:1649] Set jetsam priority to 0 [0] flag[1]
12:15:56.088136+0800 runningboardd [app<{my_bundle_id}((null))>:1649] Resuming task.
12:15:56.088211+0800 runningboardd [app<{my_bundle_id}((null))>:1649] Set darwin role to: Background
12:15:56.088449+0800 runningboardd [app<{my_bundle_id}((null))>:1649] set Memory Limits to Hard Inactive (4096)
12:15:56.089314+0800 runningboardd Successfully acquired underlying assertion for [app<{my_bundle_id}((null))>:1649]
12:15:56.589755+0800 runningboardd Invalidating assertion 33-76-23100 (target:app<{my_bundle_id}((null))>) from originator [osservice<com.apple.dasd>:76]
12:15:56.590332+0800 runningboardd Removed last relative-start-date-defining assertion for process app<{my_bundle_id}((null))>
12:15:56.593760+0800 runningboardd [app<{my_bundle_id}((null))>:1649] Suspending task.
12:15:56.594120+0800 runningboardd Calculated state for app<{my_bundle_id}((null))>: running-suspended (role: None) (endowments: (null))
From these logs, I understand that the system is accelerating the launch speed of the application.
But the time interval between these two logs below is very short, which suggests that the prewarm is executed just before main, and then the process is suspended. Is this understanding correct?
12:15:56.089314+0800 runningboardd Successfully acquired underlying assertion ...
12:15:56.589755+0800 runningboardd Invalidating assertion ...
Regarding "DAS DYLD3 Closure Generation," I speculate that after a user restarts their phone, the system uses DYLD3 to prepare closures for frequently used applications, allowing for faster application launches. Is this assumption correct?
Linsey
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Our application uses UIActivityViewController to share files, and we have received numerous complaints from users stating that triggering the share functionality causes the app to hang, making it unresponsive. Users are instructed to restart their devices, after which the sharing function works normally.
0 libsystem_kernel.dylib 0x00000001daae2708 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x00000001daae5e18 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x00000001daae5d30 mach_msg_overwrite + 424
3 libsystem_kernel.dylib 0x00000001daae5b7c mach_msg + 24
4 libdispatch.dylib 0x00000001926d1f14 _dispatch_mach_send_and_wait_for_reply + 544
5 libdispatch.dylib 0x00000001926d22b4 dispatch_mach_send_with_result_and_wait_for_reply + 60
6 libxpc.dylib 0x0000000211c1b84c xpc_connection_send_message_with_reply_sync + 256
7 Foundation 0x00000001891e98d8 __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 16
8 Foundation 0x00000001891e6034 -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2160
9 Foundation 0x000000018924fda4 -[NSXPCConnection _sendSelector:withProxy:arg1:] + 116
10 Foundation 0x000000018924fa18 _NSXPCDistantObjectSimpleMessageSend1 + 60
11 ShareSheet 0x00000001a89e7b2c -[SFShareSheetSlotManager ensureConnectionEstablished] + 220
12 ShareSheet 0x00000001a89e7960 -[SFShareSheetSlotManager ensureXPCStarted] + 440
13 ShareSheet 0x00000001a89e7f90 -[SFShareSheetSlotManager activate] + 188
14 ShareSheet 0x00000001a8a0020c -[SHSheetServiceManager init] + 100
15 ShareSheet 0x00000001a89f347c -[SHSheetInteractor _setupServiceManagerIfNeeded] + 52
16 ShareSheet 0x00000001a89f1998 -[SHSheetInteractor initWithContext:] + 76
17 ShareSheet 0x00000001a89dd450 +[SHSheetFactory createMainPresenterWithContext:] + 204
18 ShareSheet 0x00000001a89d3e90 -[UIActivityViewController _createMainPresenterIfNeeded] + 84
19 ShareSheet 0x00000001a89d53c4 -[UIActivityViewController _viewControllerPresentationDidInitiate] + 104
20 UIKitCore 0x000000018d247fd0 -[UIViewController _presentViewController:withAnimationController:completion:] + 220
21 UIKitCore 0x000000018d24a71c __63-[UIViewController _presentViewController:animated:completion:]_block_invoke + 88
22 UIKitCore 0x000000018d244ad0 -[UIViewController _performCoordinatedPresentOrDismiss:animated:] + 532
23 UIKitCore 0x000000018d2447c0 -[UIViewController _presentViewController:animated:completion:] + 324
24 UIKitCore 0x000000018d2445cc -[UIViewController presentViewController:animated:completion:] + 164
Above is the stack trace when the hang occurs. We found that UIActivityViewController ultimately calls xpc_connection_send_message_with_reply_sync, which synchronously waits for messages on the main thread, leading to the hang.
Are there any suggestions that can avoid this waiting forever hang?
I found that the application can be launched in the background, but the launchOptions in application:didFinishLaunchingWithOptions: in AppDelegate is empty. I would like to know under what circumstances the application can be launched in the background, given that background fetch is not enabled.