“swiftui”

Hello @yuval-nachman, Thank you for your post. It sounds like the .swipeActions aren’t being registered because that gesture is used to scroll horizontally for pagination. If this is not the case, please provide more information and include a code snippet that reproduces the issue. Because ScrollView’s pagination recognizer sits higher in the view hierarchy, the ScrollView claims the touch first. SwiftUI has no API for controlling gesture recognizer priority, like UIKit does with require(toFail:), which is for this exact scenario. As a workaround, consider changing the input method for list row from a .swipeAction to a .contextMenu or button, or try using next/previous page buttons instead of swiping to change pages, since thats the same recognizer that .swipeActions works with. When it comes to designing UX, there is likely something in the Design HIG that applies to your use case: See Designing for iOS. Lastly, hearing your use case would be useful in an Enhancement Request. If you file an enhancem

Thanks for the clear write-up. Your reading is correct. As of macOS 26, SwiftUI's file modifiers are fileImporter (open, returns URLs), fileExporter (writes a document or Transferable item you supply), and fileMover (moves an existing file). None of them return a bare destination URL the way NSSavePanel does, so there is no SwiftUI equivalent for choosing a save location and getting a URL back. Presenting .fileExporter with an empty placeholder document only to read its URL writes an empty file and works against how the modifier operates, so it is not a substitute. NSSavePanel is the supported way to get that destination URL, and using it from a SwiftUI app is a normal use of AppKit, not a workaround. You present it from your SwiftUI action, read panel.url, and pass that URL to your database. Since you create the file at that location, the sandbox behavior is relevant: the NSSavePanel documentation notes that when someone saves through the panel, macOS adds the chosen file

Can you open a bug report for it ? we reported a lot of issues with DeviceActivityReport views not behaving like regular SwiftUI views, and this would complement those bug reports

Hello @1066, Thank you for your post. In iOS 26, this is controlled by the system, however, in the 27 releases, SwiftUI introduces new toolbar APIs to control how these items are displayed as your app resizes. Use visibilityPriority modifier to keep important groups of toolbar items visible. Use toolbarOverflowMenu to permanently place lower priority toolbar items into the overflow menu. User topBarPinnedTrailing to pin needed toolbar items to the trailing edge at all times. Check out the WWDC26 What’s new in SwiftUI session for more new updates which might relevant to your project.  Travis

Thanks for the very interesting post. I’m a little confused and I’m guessing too much for a Monday I think. The reason you are seeing this AttributeGraph: cycle detected warning comes down to how Swift Concurrency, I think. However because your code is a minimal reproducible example, the correct fix depends on what you are actually doing between isWorking = true and isWorking = false in your real app. I don’t see how that code will produce anything. In SwiftUI, Button actions are implicitly isolated to the @MainActor. When you create a Task { ... } inside a button action, that Task should inherits the MainActor. Because your Task is already on the MainActor, calling await MainActor.run { ... } does not actually suspend or switch threads. It should executes synchronously. You are setting isWorking = true and then instantly setting isWorking = false in the exact same runloop without any code or anything to run between them? If your real app does some heavy calculations or data parsing between the two s

Hello @Jordan, From WWDC26 session: Modernize your UIKit app Menus will automatically display this item when there's content relevant for Siri. To provide more relevant information specific to your app, use the new View Annotations API. With it you can annotate specific views with AppEntities. For SwiftUI: Use .appEntityIdentifier() on something like each cell inside of a ForEach: ForEach(items) { item in CellView(item: item) .appEntityIdentifier( EntityIdentifier(for: MyItemEntity.self, identifier: item.id) ) .contextMenu { ... } } This is the View Entity Annotation API from session 343: Explore advanced App Intents features for Siri and Apple Intelligence Note: MyItemEntity must conform to AppEntity with a persistent identifier. For more information see: App Intents I hope this helps!  Travis

IB is such a perfect tool to visually build a layout, I am very sad to see it so neglected. Fully agree. Doing in code makes is so hard to understand and quasi impossible to maintain. And I don't find SwiftUI so good to design precise UI (where many items need to be precisely positioned). I compared Xcode 26.3 and 16.4 : 26.3 takes between 9 and 12s to open the first view in IB, instead of 6s. Would be really interesting to know what it does differently.