Background I have a SwiftUI app that uses OSLog and the new Logger framework. In my SwiftUI views, I would like to use something like Self._logChanges() to help debug issues. After some trial and error, I can see the messages appear in the System console log for the app I am debugging using the com.apple.SwiftUI subsystem. Problem I'd like to see those same messages directly in Xcode's console window so I can filter them as needed. How do I do that? Thanks! -Patrick

Background: We have an iOS app that supports a single window. We are using a UISceneDelegate. We do not support multiple windows or scenes. Problem: When a user mirrors the screen of their iPhone device, iOS automatically initializes a new scene with a non-interactive display role. For the time being, we would like to disable opting into this and instead simply mirror the existing device window. Going through the docs, I haven't been able to find any way of doing this. All the docs appear to assume that once you start supporting UIScene, you should automatically support any screen size, aspect ratio or connected display. In the Scenes Overview section, it claims that setting UIApplicationSupportsMultipleScenes to false will never create multiple windows, but I've confirmed under the debugger that this isn't true. Any ideas? Repro Steps: Create an iOS app with a single window that supports UISceneDelegate Launch the app on your iPhone (tested using iOS 17.3) Turn on your Apple TV From Control Center, tap the mirror icon (two small windows)

The following crash is happening in iOS 16 when we call snapshot.reconfigureItems(ids). We get the ids to reload by calling the CollectionView's indexPathsForVisibleItems, where the idea is to refresh the currently visible items. #0 (null) in __exceptionPreprocess () #1 (null) in objc_exception_throw () #2 (null) in -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] () #3 (null) in -[__UIDiffableDataSourceSnapshot _validateReloadUpdateThrowingIfNeeded:] () #4 (null) in -[__UIDiffableDataSourceSnapshot _commitUpdateAtomic:] () #5 (null) in -[__UIDiffableDataSourceSnapshot reconfigureItemsWithIdentifiers:] () #6 (null) in NSDiffableDataSourceSnapshot.deleteItems(_:) () We are also seeing a slight variation of the same crash: #0 (null) in __exceptionPreprocess () #1 (null) in objc_exception_throw () #2 (null) in -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] () #3 (null) in -[_UIDiffableDataSourceUpdate initWithIdentifiers:sectionIdentifiers:action:desinationIdentifier:relativePosition:destinationIsSection:] () #4 (null) in -[_UIDiffableDataSourceUpdate initWithReconfiguredItemIdentifiers:] () #5 (null) in -[__UIDiffableDataSourceSnapshot reconfigureItemsWithIdentifiers:] () #6 (null) in NSDiffableDataSourceSnapshot.deleteItems(_:) () These two crashes taken together currently account for 50% of all our app's crashes. According to the data we have, it is specific to iOS 16. Some questions: Is there anything we can do to mitigate this crash? Can we safely call snapshot.reloadItems(ids) instead? If so, how much of a performance hit would we expect to get?

The name of the function beginBackgroundTask appears to imply that it is safe to call from a background thread. However, because this is part of the UIApplication class, it causes a dispatch to the main thread first. This dispatch can prove problematic as it can introduce resource contention, or at worst deadlocks, if you're not very careful about how you're starting your task. Example: Main thread calls a lower layer of code, which is using a dispatch queue to process operations An item in that queue is already processing an item which happens to call beginBackgroundTask() If the operation being performed on the main thread is synchronous, you get a deadlock. If the operation is asynchronous, you can still run into a delay if your background queue performs a lot of operations, as each one briefly is blocking the main queue each time. The docs for beginBackgroundTask() claim that invoking the API is asynchronous, or that you can call this method at any time, but that doesn't appear to actually be the case. Was this by design? Is beginBackgroundTask() intended to be used very sparingly?