SwiftUI List performance

Hello @Cykelero, On iPhone, users shake the phone to undo. This is a system setting. From what I found and tried, I don't think TextField or even SwiftUI can disable that interaction on iPhone. But on Mac you can use the toggles listed above or the ⌘+Z function can be overwritten with AppKit commands Let me get a confirmation that I'm not missing anything, if possible. In the meantime let me know if this helps.  Travis Trotto - DTS Engineer

Hello! That definitely looks like a problem! I think that you’re encountering two separate issues: one with download cancellation and another with internal analytics. For the former issue, we’ll try to reproduce it on our side. It would be super helpful if you could file a feedback report in Feedback Assistant, making sure to attach sysdiagnose logs from the device on which asset-pack cancellation failed soon after reproducing the behavior. Plus, filing a feedback report ensures that you’ll be automatically notified when we fix the issue. We’ll let you know if we figure out a workaround before the fix is available. Thanks! The fact that version 0 of the asset pack with the ID X-XXXXXX-XXX finished being downloaded couldn't be reported: Error Domain=NSCocoaErrorDomain Code=3851 Property list invalid for format: 200 (property lists cannot contain objects of type 'CFError') That error message concerns the latter issue. If you installed the app from TestFlight, then the system collects data abou

XcodeRead - Read files from the project XcodeWrite - Write files to the project XcodeUpdate - Edit files with str_replace-style patches XcodeGlob - Find files by pattern XcodeGrep - Search file contents XcodeLS - List directory contents XcodeMakeDir - Create directories XcodeRM - Remove files XcodeMV - Move/rename files BuildProject - Build the Xcode project GetBuildLog - Get build output RunAllTests - Run all tests RunSomeTests - Run specific tests GetTestList - List available tests XcodeListNavigatorIssues - Get Xcode issues/errors XcodeRefreshCodeIssuesInFile - Get live diagnostics ExecuteSnippet - Run code in a REPL-like environment RenderPreview - Render SwiftUI previews as images DocumentationSearch - Search Apple docs and WWDC videos XcodeListWindows - List open Xcode windows The above is a list of MCPTools exposed by Xcode. Im am interested in the DocumentationSearch Tool . Here Xcode is able to search only Apple Docs. Lets say i am using a custom .xcframew

Part 2... Does this indicate a specific alignment restriction, memory fragmentation, or a resource conflict on Apple Silicon? No, I don't think anything like that is going on. Synchronization for Memory Visibility: To ensure that the virtual address mapping established in UserMap... is globally visible across all CPU cores and execution contexts before the kernel issues the first Bundled Task, are there recommended synchronization primitives or Memory Barrier calls? No, I don't think any special synchronization is required. If you're tracking the buffer through a direct pointer, then the relative gap between UserMapBundledParallelTaskCommandAndResponseBuffers and the first possible call to BundledParallelTaskCompletion is so large that any kind of synchronization is unnecessary. This is also a fine reason to not bother holding/freeing the IOMemoryMap— if you never free your buffer pointer, then its values will only EVER be NULL (uninitialized) or its valid value (post initialized). The more I think about this

Part 1... However, a subsequent call to ivars->fResponseMap->GetAddress() returns NULL (0x0). Subsequent call when? The expectation (and what our driver does) is that you'd immediately call GetAddress() and then basically never look at the map again. In one of our drivers, that never is quite literal. The code is basically: IOMemoryMap *memoryMap = NULL; if ( parallelCommandIOMemoryDescriptor->CreateMapping(0, 0, 0, 0, 0, &memoryMap) == kIOReturnSuccess ) { ivars->fCommandAddress = memoryMap->GetAddress(); } ... if ( parallelResponseIOMemoryDescriptor->CreateMapping(0, 0, 0, 0, 0, &memoryMap) == kIOReturnSuccess ) { ivars->fParallelResponseAddress = memoryMap->GetAddress(); } ...and, yes, that code leaks two IOMemoryMap's. I don't know what the exact thinking was, but I suspect they realized that the only reason that mapping would ever become invalid/useless was because the driver was being torn down, so freeing doesn't really matter. I'll admit, there is a certain charm to tha

Thank you for your question. I recommend providing a focused sample project, such as the image Image(“playerJersey_red”), which we will all be missing. I will need to replace it with a different image. Regarding the dropDestination cellContent, I understand that you define it, but it would be beneficial to have a sample that can be executed quickly and shared with others for verification. I think it is possible to have a view enabled as a drop destination but disabled as a draggable source based on certain conditions. The issue you're encountering with the .disabled modifier affecting both dragging and dropping could be because it disables all user interactions for the view. Instead, you should conditionally apply the .draggable modifier only when there is a player available? Use content.player.map { $0 } to provide a value only when player is not nil. This makes the view draggable only if a player exists and should keep the .dropDestination modifier without any conditions since you want all cells to be valid

Figured out the implementation! For anyone interested in implementing in IOS 26+ @Namespace private var namespace @State private var presentDialog: Bool = false and in the toolbar ToolbarItem(placement: .cancellationAction){ Button(role: .destructive) { presentDialog = true } label: { Text(Delete) } .confirmationDialog( Delete?, isPresented: $presentDialog, titleVisibility: .visible ) { Button(Delete, role: .destructive) { // perform delete } Button(Cancel, role: .cancel) { } } }

Hi Ziqiao, The important detail is step 3 - the user hasn't even opened Device B in weeks so that device is totally out of the loop. It's unaware of any deletions (or any changes at all) that have happened since step 1. Everything was synchronized initially, but then the user starts deleting items on Device A, which get synced up to iCloud. Meanwhile, back on device B, the app has been left unopened for weeks. When the user opens it up, they'll get .changeTokenExpired, and I'll fall back to the unify logic, the same behavior we use the first time this device syncs. I'm really confused about how deleted record ID's work. For my use case, it doesn't matter which device the record was created on - any device that has had a long delay between fetches such that it needs to do a full fetch will need a list of everything that was deleted on the server since the last fetch. For example, a user initially creates a record on Device A, syncs it to iCloud, Device B fetches. Later on, the user removes it on Devic

@DTS Engineer Thanks a lot for the detailed explanation — that makes sense. It seems that when migrating directly from ObservableObject to @Observable, extra care is needed around update ordering and intermediate states. In my case, this behavior leads to unexpected UI results, such as the scroll position ending up in an incorrect state (as shown in the screenshot above). I can consistently reproduce this on a real iPad Pro (M4) running iOS 26.2.1, where the UI visually jumps and then settles at an unintended position. I’ll need to adjust my approach to work around this behavior. I’d also be very interested to hear more from the SwiftUI team on the intended patterns or best practices for avoiding these intermediate states in UI code.