SwiftUI List performance

Update / Resolution In my case, the flashing preview was not a capture pipeline issue, but a SwiftUI view lifecycle issue. The camera preview was conditionally shown using: authorized && session.isRunning && cameraReady During lock/unlock or camera switches, SwiftUI re-evaluates this condition multiple times. AVCaptureSession.isRunning can briefly fluctuate during interruption recovery, causing SwiftUI to: remove the preview view show a placeholder immediately reinsert the preview This rapid view swapping appeared as a “blank flash”. The preview layer itself was fine. Fix I removed session.isRunning from the SwiftUI visibility condition. The logic is now: authorized && cameraReady cameraReady is set once after initial setup and never toggles during interruptions. The preview view stays mounted at all times. Why this works AVCaptureVideoPreviewLayer already handles short “no frames” periods gracefully. By keeping the preview layer mounted and avoiding

FB20843042 is the feedback we filed which includes a sample project. What is the intent of foo(key: MyCustomTraitKey.self)? It was added in an effort to identify the source of the crash by minimizing types and functions used from system SDKs. The issue occurs with any function with the same signature. The original ossie wsa found when calling https://developer.apple.com/documentation/swiftui/environmentvalues/subscript(_:)-9zku

Thank you for your post. I am attempting to understand what you are tying to accomplish. Because you are using the UIHostingController I guess you are using UIKit and SwiftUI together? It would be greatly appreciated if you could provide a focused sample to demo the issue, without code is really hard for me. In my opinion I believe this error message suggests that you are attempting to directly add a subview to the view hierarchy of a view controller, which is not suggested and can result in issues with the view hierarchy. A view controller is designed to manage its own view hierarchy, and directly tampering with it can lead to unexpected behavior. If you wish to overlay or add views around the SwiftUI content managed by a view controller, you should do so by adding your views to a common superview that contains the view controller’s view. If your objective is to integrate UIKit views into SwiftUI, consider using to encapsulate a UIKit view and incorporate it within your SwiftUI

So basically, could I build the Photos app (or something like it) in SwiftData. Seems to be no. Because Query cannot handle anything remotely close to the thousands of displayed objects. I tested a manual fetch on context. Performed in milliseconds as expected. But anything in Query, completely fails with like 10 seconds when it gets bad

Due to the very low latency of our hardware for specific commands (e.g., TEST UNIT READY). Logs reveal a severe timing conflict: The interrupt handler (Completion path) is triggered and successfully invokes BundledParallelTaskCompletion, which returns normally. Crucially, at this exact microsecond, the original UserProcessBundledParallelTasks call (Submission path) has not yet finished its loop or returned to the system. Immediately after both paths eventually return, the DEXT process crashes (Corpse), subsequently triggering a Kernel Panic. Something doesn't sounds right here. There are actually a few different things that concern me: (1) There's a reasonably long cycle to get to your interrupt handler from the kernel. I'm skeptical that there's any way for an interrupted to fire before UserProcessBundledParallelTasks finishes running unless UserProcessBundledParallelTasks is doing something that substantially delays its own process. (2) From the kernel side, how bundled commands actually work is that Proces

Updating to XCode 26.2 and macOS Tahoe 26.2 and im now greeted with Trace file had no swiftui data this occurs if I profile with XCode and chose a template I profile with XCode and chose a blank template and manually choose SwiftUI I manually run the Instruments, manually run the app, attach and open a document in my swiftUI app however, if i DO NOT load a document (macOS based swiftui app), im able to get swiftui traces my feeling here is theres something going on with complicated traces that cause an issue modelling the data stream, or capturing the trace? Im not familiar with the nuances here but this isnt working for anything that NEEDS profiling.

I'd like to comment the second question a bit, as it hasn't been addressed yet: Sometimes when running on a new device it will create a second UserSettings while it is waiting for the original one to sync from CloudKit. When you use SwiftData + CloudKit, under the hood, the framework uses NSPersistentCloudKitContainer to synchronize data. In that environment, duplicate data is sometimes inevitable, which is discussed in great details in the following section: Remove duplicate data The solution is to de-duplicate the data. How to do so is discussed and demonstrated in the sample code. Back to what to what you intent to achieve, my suggestion will be: If you plan to use SwiftData + CloudKit extensively in your app, you might need to handle duplicate data anyway. In this case, persisting user settings to your SwiftData store (and Synchronizing them via NSPersistentCloudKitContainer) makes a lot of sense. If the target is as simple as saving some Cloud-based user settings, I'd probably consider NSUbiquitousKeyVal

After experimenting with this code a bit I can see one potential issue: if you first initialize the SectionReader Tool with an empty list [] for sections, the .anyOf guide doesn't properly initialize and isn't enforced. I can't tell from the above code when you are initializing SectionReaderTool, but here's an important rule: When you initialize your LanguageModelSession with a tool, e.g. let session = LanguageModelSession(tools: [SectionReaderTool(.....)]), the property parameters will be computed at that time and the schema it produces will be added to the LanguageModelSession's instructions. Once the tool definition is in the instructions, it's never updated. What that means, is if you end up changing your SectionReaderTool or sections at any time after that, the model will never see your updates. So in theory, if you sometimes were to have an empty list [] initially for the tool, the anyOf would never work, even if you later added sections to the list. If that's not your issue,

I am working on the real project. The changes to the list of @Model are still not being captured in the Observations. When I modify or add/remove from the list sometimes a property of the object that IS NOT changed shows as being changed. That property has exactly one setter call and is not linked to the edit, add, or remove code. When I tried to observe the list as a whole, I achieved a FATAL ERROR for illegal attempt to resolve a future for a relationship that doesn't have a cached value!

Hi Kevin, Thank you for your previous guidance. We have shifted our driver architecture to the UserProcessBundledParallelTasks model with Shared Command/Response Buffers to optimize I/O performance. But, we are encountering a persistent Kernel Panic / DEXT Crash (Corpse) immediately after switching to the Bundled mode, preventing the target discovery and initialization sequence from completing, while the legacy mode (UserProcessParallelTask) is rock-solid and stable. Implementation Details: Memory Mapping: Successfully implemented UserMapBundledParallelTaskCommandAndResponseBuffers. DEXT correctly obtains the virtual addresses for both buffers. Dispatching: Inside UserProcessBundledParallelTasks, we iterate through the parallelRequestSlotIndices, reading from the shared command buffer and dispatching tasks to the hardware. Completion: Upon hardware completion, we populate the shared response buffer in the asynchronous path (ISR/Poll) and invoke BundledParallelTaskCompletion with the corresponding OSA