Attached a symbolicated crash report from one of those Xcode sessions to FB16595418. If I'm understanding this right, it looks like BGTaskScheduler registerForTaskWithIdentifier is already being called internally by the modifier. Thread 2 Crashed: 0 libsystem_kernel.dylib 0x1ef16f1dc __pthread_kill + 8 1 libsystem_pthread.dylib 0x2281a3b40 pthread_kill + 268 2 libsystem_c.dylib 0x1a5f9c234 __abort + 132 3 libsystem_c.dylib 0x1a5f9c1b0 abort + 136 4 libc++abi.dylib 0x2280cd5a0 abort_message + 132 5 libc++abi.dylib 0x2280bbf10 demangling_terminate_handler() + 344 6 libobjc.A.dylib 0x19b560e48 _objc_terminate() + 156 7 libc++abi.dylib 0x2280cc8b4 std::__terminate(void (*)()) + 16 8 libc++abi.dylib 0x2280cfe1c __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88 9 libc++abi.dylib 0x2280cfdc4 __cxa_throw + 92 10 libobjc.A.dylib 0x19b55ee74 objc_exception_throw + 448 11 Foundation 0x19d3a6990 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 288 12 BackgroundTasks 0x236e9d6ec -[BGTaskScheduler _unsafe_registerForTaskWithIdentifier:usingQueue:launchHandler:] + 448 13 BackgroundTasks 0x236e9d4ec -[BGTaskScheduler registerForTaskWithIdentifier:usingQueue:launchHandler:] + 128 14 SwiftUI 0x1a2b77b4c -[BGTaskSchedulerProxy registerForTaskWithIdentifier:launchHandler:] + 220 15 SwiftUI 0x1a34a8028 closure #1 in AppRefreshBackgroundTask.register() + 344 16 SwiftUI 0x1a27cbe15 <deduplicated_symbol> + 1 17 SwiftUI 0x1a293c239 <deduplicated_symbol> + 1 18 SwiftUI 0x1a27ac829 <deduplicated_symbol> + 1 19 libswift_Concurrency.dylib 0x1a9adbcc9 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1

Thanks for the response. I am still a bit confused however. My understanding is that the .backgroundTask modifier is the replacement for BGTaskScheduler.register in SwiftUI. And the code that runs during the background task is part of that modifier. As per the WWDC22 video Efficiency awaits: Background tasks in SwiftUI, it is used to register the handler. Also worth noting that the video uses a short ID similar to what I did. If I take out the modifier, the app crashes with this message: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'No launch handler registered for task with identifier notifications' Which indicates that the modifier is indeed used for registering the handler. There's no difference to this behaviour whether I use the short ID notifications or the reverse DNS com.ip18.SubManager.notifications. If the modifier is not there then the app crashes. Interestingly when I simply killed and ran my app from Xcode multiple times, I eventually came across the All launch handlers must be registered before application finishes launching crash in one of those launches. Which is probably what the crash reports are about.

Hi Kevin, There's no usage of BGTaskScheduler.register anywhere in my app. Am I supposed to call this method at some point? I use the background tasks API in two places currently: Calling BGTaskScheduler.shared.submit during .onChange(of: scenePhase) when newPhase == .active, on the view that appears when my app is launched. It schedules the background task whenever my app is brought to the foreground. .backgroundTask(.appRefresh("notifications")) attached to my WindowGroup. I attached the code snippet of this in my initial bug report. I have just managed to reproduce the crash after quitting and relaunching the app about 100 times. The bug report has been updated with the sysdiagnose and a copy of the crash report.

Submitted a bug report: FB16595418

Got the update today but disappointed that it doesn't have a dark mode icon on iPad. Apple should lead by example and use the latest features in their first party apps. I guess we will have to wait a few more months for that similar to the App Store Connect and TestFlight apps...

I submitted FB16079255 and it's now saying "Potential fix identified, for a future OS update". Hopefully it will be fixed in macOS 15.4.

This is my app: https://apps.apple.com/gb/app/submanager-subscription-list/id1632853914

I submitted feedback and their response was “unable to diagnose”

Ignore my above comment, it seems having iPhone Mirroring enabled delays my notifications by 10 seconds even if I have my MacBook closed? When I turned off passcode it automatically unpaired iPhone Mirroring which was why my notifications arrived immediately. But when I paired my phone back to my Mac my notifications are now delayed again.

It seems turning passcode lock off and on gets rid of the delay… can anyone here try doing this to see if the delay is gone? I will keep an eye on my phone to see if the delay happens again.

This bug still exists in iOS 18.2 beta 3. Why is such a critical issue not fixed yet? I have to wait several seconds for my 2FA notification to arrive for example. And my iPad doesn't have this problem with AI enabled, why is my iPhone 16 Pro having this issue?

It says it will be coming by the end of this year

You can’t use any of the Apple Intelligence features on the simulator. You have to use a physical device.

Fixed in iOS 18.2 beta 2

This issue continues to be present in iOS 18.1 beta 7. Your documentation says it can be used with TextField, but it doesn't seem to work. Any idea when this will be fixed?