“swiftui”

@DTS Engineer Thanks for the quick follow-up. I'm pretty familiar with what you've presented. The problem with invoking NSSavePanel from within a SwiftUI macOS application is that you don't necessarily have access to the underlying NSWindow to properly present the NSSavePanel as a sheet, which would be the expected user experience. I'm aware of the following ways to work around this, all of which feel awkward in a pure SwiftUI environment: Assume the application's current key window is the one to use. Use an NSViewRepresentable as a window accessor Abandon the full SwiftUI app lifecycle and just using a traditional AppKit lifecycle for window management. Are there other ways I've overlooked that are more idiomatic SwiftUI? The ability to ask the user for a URL to save content to is such a fundamental macOS feature that it's omission genuinely perplexes me. Are you able to elaborate at all as to what the general rational and thinking is behind this?

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