We have discovered that our UIViewRepresentable view isn't being dismantled after its window is dismissed via dismissWindow(). This seems to result in a leak of our custom Coordinator class. Every time the user opens a new window, a new Coordinator is created; if the user then dismisses the window manually, or we dismiss it programmatically, the Coordinator remains in memory with no way to destroy it. Is this expected behavior? How can we be sure to clean up our Coordinator when the view's window is closed? Thanks.

On visionOS, I have discovered that if dismissWindow is followed immediately by a call to openWindow, the new window does not open where the user is looking at. Instead, it appears at the same location as the dismissed window. However, if I open the new window after a small delay, or after UIScene's willDeactivateNotification, the new window correctly opens in front of the user. (I tested this within a opened immersive space.) Does this imply that dismissWindow is actually asynchronous, in the sense that it requires extra time to reset certain internal states before the next openWindow can be called? What is the best practice to close a window, then open a new window in front of the user's current head position?

Hi. I recently added SwiftUI context menus and picker menus to my app, but when they are activated they flicker rapidly, and it is impossible to select anything (there is no hover effect either). When these menus are activated, the console prints lots of warning messages similar to this: [NetworkComponent] Cannot find component's entity (guid=14395713952467043328, typeID=295756909031380028, type=CustomComponentRCPInputTargetComponent, entity=0x1047c6750). This issue doesn't seem to happen on visionOS 1.2 simulator, but is reliably reproducible on visionOS 2.0 simulator and device. Any idea what this might be related to? I am attempting to narrow down on the issue but it's challenging to do so without knowing what the error is about. Thanks!

We've recently discovered that our app crashes on startup on the latest visionOS 2.0 beta 5 (22N5297g) build. In fact, the entire field of view would dim down and visionOS would then restart, showing the Apple logo. Interestingly, no app crash is reported by Xcode during debug. After investigation, we have isolated the issue to a specific USDZ asset in our app. Loading it in a sample, blank project also causes visionOS to reliably crash, or become extremely unresponsive with rendering artifacts everywhere. This looks like a potentially serious issue. Even if the asset is problematic, loading it should not crash the entire OS. We have filed feedback FB14756285, along with a demo project. Hopefully someone can take a look. Thanks!

I am trying to change the highlight color of the tabs in SwiftUI, but when I applied .tint() to the TabView (which is the root view of my app), the entire app seems to be affected. What's more, the views under each seems to randomly switch between the default blue tint and the custom tint I configured. Is there a way to only change the tab bar's tint color? Thanks!

Following up on my previous post about how to change the foreground tint color of tab bars in SwiftUI: https://developer.apple.com/forums/thread/760008 I have subsequently discovered the toolbarForegroundStyle(_:for:) modifier, documented here. However, when I tried to use it in Xcode, it doesn't seem to be publicly declared, even though it should have been available since iOS 16 according to the doc. Was this a mistake? I have filed feedback FB14553959.

I added a background view to my SwiftUI List, and would like to move it up as user scrolls (similar to the effect of that of the Health app). I can't add it onto the background of a List row, because List unconditionally clips content to a row, and I would like the view to extend past a insetted row's bounds (scrollClipDisabled does not work on List). So I added the view as the background view of the entire List. Currently, I am achieving this by monitoring contentOffset using the new onScrollGeometryChange(for:of:action:) modifier, updating a state variable that controls the offset of the background view. The code looks something like this: struct ContentView: View { @State private var backgroundOffset: CGFloat = 0 var body: some View { List { ... } .background { backgroundView .offset(y: backgroundOffset) } .onScrollGeometryChange(for: ScrollGeometry.self) { geometry in geometry } action: { oldValue, newValue in let contentOffsetY = newValue.contentOffset.y let contentInsetY = newValue.contentInsets.top if contentOffsetY <= -contentInsetY { backgroundOffset = 0 } else { backgroundOffset = -(contentOffsetY + contentInsetY) } } } } However, this results in bad scrolling performance. I am guessing this is due to backgroundOffset being updated too frequently, and thus refreshing the views too often? If so, what is a more performant approach to achieve the desired effect? Thanks!

With the new @Observable macro, it looks like every time the struct of a view is reinitialized, any observable class marked as @State in the struct also gets reinitialized. Moreover, the result of the reinitialization immediately gets discarded. This is in contrast to @StateObject and ObservableObject, where the class would only be initialized at the first creation of the view. The initialization method of the class would never be called again between view updates. Is this a bug or an expected behavior? This redundant reinitialization causes performance issues when the init method of the observable class does anything slightly heavyweight. Feedback ID: FB13697724

I have recently moved some of my data save operations from the view context to background contexts. Since the switch, some (but not all) of my users are reporting that the background save operations crash 100% of the time. After researching, I have narrowed it down to the fact that these save operations involve establishing a relationship to an entity with a derived attribute. An example is shown below: try await CoreDataStack.shared.performBackgroundTask { context in var transaction = Transaction(context: context) transaction.amount = NSDecimalNumber(decimal: 0) transaction.id = UUID() let account = Account.account(withName: "Default", in: context) transaction.account = account try context.save() } // <= Crashes! In the above example, each Transaction has a to-one relationship to an Account, and the latter has a to-many relationship the the former. Account has a derived attribute called balance that is calculated using the expression sum:(transactionItems.amount). The would then crash when the performBackgroundTask block exits (after the save() operation returns): Thread 4 Crashed: 0 libobjc.A.dylib 0x00000001850ae00c objc_release_x8 + 8 1 CoreData 0x00000001900d8cfc -[_CDSnapshot dealloc] + 72 (_CDSnapshot.m:691) 2 CoreData 0x00000001900d8b68 _NSQLRow_dealloc_standard + 48 (NSSQLRow.m:156) 3 CoreFoundation 0x0000000187d72228 __CFBasicHashRemoveValue + 192 (CFBasicHash.c:1332) 4 CoreFoundation 0x0000000187d7212c CFBasicHashRemoveValue + 452 (CFBasicHash.c:1418) 5 CoreFoundation 0x0000000187d71638 CFDictionaryRemoveValue + 196 (CFDictionary.c:477) 6 CoreData 0x00000001900f6fa8 -[NSPersistentStoreCache decrementRefCountForObjectID:] + 96 (NSPersistentStoreCache.m:120) 7 CoreData 0x00000001900f6eec -[NSSQLCore managedObjectContextDidUnregisterObjectsWithIDs:generation:] + 172 (NSSQLCore.m:4329) 8 CoreData 0x00000001900f30f4 0x1900d6000 + 119028 9 CoreData 0x00000001900f4d74 gutsOfBlockToNSPersistentStoreCoordinatorPerform + 204 (NSPersistentStoreCoordinator.m:404) 10 libdispatch.dylib 0x000000018fe9b0d8 _dispatch_client_callout + 20 (object.m:576) 11 libdispatch.dylib 0x000000018fea26e0 _dispatch_lane_serial_drain + 744 (queue.c:3934) 12 libdispatch.dylib 0x000000018fea31e8 _dispatch_lane_invoke + 380 (queue.c:4025) 13 libdispatch.dylib 0x000000018feae258 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7185) 14 libdispatch.dylib 0x000000018feadaa4 _dispatch_workloop_worker_thread + 532 (queue.c:6779) 15 libsystem_pthread.dylib 0x000000020f3c0c7c _pthread_wqthread + 288 (pthread.c:2696) 16 libsystem_pthread.dylib 0x000000020f3bd488 start_wqthread + 8 performBackgroundTask is defined as: func performBackgroundTask<T>(_ block: @escaping (NSManagedObjectContext) throws -> T) async rethrows -> T { try await container.performBackgroundTask { context in context.transactionAuthor = appTransactionAuthorName context.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy return try block(context) } } Things to note: If I do not establish the relationship to Account from Transaction, the crash doesn't happen; if I uncheck derived on the balance attribute of Account, the crash also does not happen. For those users who are experiencing the crash, the crash rate is 100%; for those who aren't experiencing the crash, the crash never happens. So it's either 100% or 0%. I have double checked all concurrency usages and all operations are performed within NSPersistentCloudKitContainer's performBackgroundTaskmethod, so it's probably not a threading issue. I have also tried ASan, Core Data's concurrency debug, as well as Zombie objects to no avail. The crash seems to be related to a user's existing data. While I couldn't reproduce the crash on my own database, once I replaced the underlying SQLite file with one of my crashing user's, the crash is 100% reproducible. I am at my wit's end here. Is this an internal Core Data bug, or am I doing something incorrectly? Any help is greatly appreciated!

I am trying to replace the navigation tab bar with a custom bottom toolbar when a view enters edit mode. Currently, I am using the following code to achieve this: content .toolbar(isEditing ? .hidden : .visible, for: .tabBar) . toolbar(isEditing ? .visible : .hidden, for: .bottomBar) However, this results in a janky animation. When the bottom bar appears, it animates in above (in contrast to in place of) the tab bar, then "jumps" back down to the correct offset without animation. I had to workaround this by delaying the appearance of bottom bar by 0.3s. I am already using withAnimation(). Is this a bug or am I using the APIs incorrectly? Is there a more seamless way to achieve this switching effect other than delaying the bottom bar? Thanks!

In SwiftUI, I have noticed that sometimes at the end of a keyboard dismiss animation, it leaves a white "inset" on the screen. The white inset would then disappear without any animation. For more detailed demonstration, I have filed feedback FB13694633. Is there a way to work around this white inset for now? Thanks!

It is impossible to enter Chinese characters after tokens are inserted into .searchable text field. Input is directly converted into Pinyin alphabets without giving the user a chance to choose its corresponding Chinese character. If no view is provided in the "token" view builder of the searchable initializer, then this issue does not happen. I have filed feedback FB13957127. In the meantime, I was wondering if there are any possible workarounds? This bug essentially prevents Chinese users from using the search feature of my app. Thanks!

Currently I have a cloud syncing status icon that utilizes the new "rotate" symbol effect introduced with iOS 18. After the synchronization is complete, I want to replace the icon with another symbol using the "replace" contentTransition. These are the codes I used to achieve this: Image(systemName: coreDataStack.cloudKitUIStatus.symbolName) .foregroundColor(coreDataStack.cloudKitUIStatus.symbolColor) .symbolEffect(.rotate, isActive: coreDataStack.cloudKitUIStatus == .inProgress) .contentTransition(.symbolEffect(.replace)) However, the rotation effect continues after the replace transition. This means the new icon (checkmark.icloud.fill) continues the spinning animation from the previous symbol (arrow.triangle.2.circlepath.icloud) until it completes the full circle. How can I stop the rotation immediately before the contentTransition? Thanks!