“swiftui”

Thank you for your post and your screenshot. While the screenshot depicts the app as a SwiftUI View, your post explicitly mentions that the app is built using UIKit Storyboards? When utilizing Xcode Previews with a storyboard-based macOS application that retains the default window controller entry point, it is important to note that the app’s entry point is typically defined by a window controller in the storyboard (often linked to the initial scene). In full-screen mode, macOS may preserve this state across UI refreshes. Could you please isolate the entry point of the app and create a new focused project that displays it? Additionally, I recommend providing your expectations so that we can assist you in fulfilling them. If you intend to use SwiftUI, I would suggest sticking to that framework. Albert Pascual
  Worldwide Developer Relations.

Thanks for the post. Great question as there are so many ways to accomplish this and probably better than the code I had for an icon. SwiftUI developers please feel free to jump info this thread and provide a simple solution to this problem. Label(title: {}) { Image(systemName: gearshape.fill) .resizable() .aspectRatio(contentMode: .fit) .frame(width: 44, height: 44) .foregroundColor(.white) .background( Circle() .fill(Color.blue.opacity(0.8)) .overlay { Circle() .stroke(Color.white, lineWidth: 2) } ) } The icon maintains perfect circular shape with consistent padding and size. Added subtle background and outline for better visibility. Albert Pascual
  Worldwide Developer Relations.

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

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 .xcframework or i have added HTML Docs of my

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

@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.