At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for UI Frameworks. How would you recommend developers start adopting the new design? Start by focusing on the foundational structural elements of your application, working from the "top down" or "bottom up" based on your application's hierarchy. These structural changes, like edge-to-edge content and updated navigation and controls, often require corresponding code modifications. As a first step, recompile your application with the new SDK to see what updates are automatically applied, especially if you've been using standard controls. Then, carefully analyze where the new design elements can be applied to your UI, paying particular attention to custom controls or UI that could benefit from a refresh. Address the large structural items first then focus on smaller details is recommended. Will we need to migrate our UI code to Swift and SwiftUI to adopt the new design? No, you will not need to migrate your UI code to Swift and SwiftUI to adopt the new design. The UI frameworks fully support the new design, allowing you to migrate your app with as little effort as possible, especially if you've been using standard controls. The goal is to make it easy to adopt the new design, regardless of your current UI framework, to achieve a cohesive look across the operating system. What was the reason for choosing Liquid Glass over frosted glass, as used in visionOS? The choice of Liquid Glass was driven by the desire to bring content to life. The see-through nature of Liquid Glass enhances this effect. The appearance of Liquid Glass adapts based on its size; larger glass elements look more frosted, which aligns with the design of visionOS, where everything feels larger and benefits from the frosted look. What are best practices for apps that use customized navigation bars? The new design emphasizes behavior and transitions as much as static appearance. Consider whether you truly need a custom navigation bar, or if the system-provided controls can meet your needs. Explore new APIs for subtitles and custom views in navigation bars, designed to support common use cases. If you still require a custom solution, ensure you're respecting safe areas using APIs like SwiftUI's safeAreaInset. When working with Liquid Glass, group related buttons in shared containers to maintain design consistency. Finally, mark glass containers as interactive. For branding, instead of coloring the navigation bar directly, consider incorporating branding colors into the content area behind the Liquid Glass controls. This creates a dynamic effect where the color is visible through the glass and moves with the content as the user scrolls. I want to know why new UI Framework APIs aren’t backward compatible, specifically in SwiftUI? It leads to code with lots of if-else statements. Existing APIs have been updated to work with the new design where possible, ensuring that apps using those APIs will adopt the new design and function on both older and newer operating systems. However, new APIs often depend on deep integration across the framework and graphics stack, making backward compatibility impractical. When using these new APIs, it's important to consider how they fit within the context of the latest OS. The use of if-else statements allows you to maintain compatibility with older systems while taking full advantage of the new APIs and design features on newer systems. If you are using new APIs, it likely means you are implementing something very specific to the new design language. Using conditional code allows you to intentionally create different code paths for the new design versus older operating systems. Prefer to use if #available where appropriate to intentionally adopt new design elements. Are there any Liquid Glass materials in iOS or macOS that are only available as part of dedicated components? Or are all those materials available through new UIKit and AppKit views? Yes, some variations of the Liquid Glass material are exclusively available through dedicated components like sliders, segmented controls, and tab bars. However, the "regular" and "clear" glass materials should satisfy most application requirements. If you encounter situations where these options are insufficient, please file feedback. If I were to create an app today, how should I design it to make it future proof using Liquid Glass? The best approach to future-proof your app is to utilize standard system controls and design your UI to align with the standard system look and feel. Using the framework-provided declarative API generally leads to easier adoption of future design changes, as you're expressing intent rather than specifying pixel-perfect visuals. Pay close attention to the design sessions offered this year, which cover the design motivation behind the Liquid Glass material and best practices for its use. Is it possible to implement your own sidebar on macOS without NSSplitViewController, but still provide the Liquid Glass appearance? While technically possible to create a custom sidebar that approximates the Liquid Glass appearance without using NSSplitViewController, it is not recommended. The system implementation of the sidebar involves significant unseen complexity, including interlayering with scroll edge effects and fullscreen behaviors. NSSplitViewController provides the necessary level of abstraction for the framework to handle these details correctly. Regarding the SceneDelagate and scene based life-cycle, I would like to confirm that AppDelegate is not going away. Also if the above is a correct understanding, is there any advice as to what should, and should not, be moved to the SceneDelegate? UIApplicationDelegate is not going away and still serves a purpose for application-level interactions with the system and managing scenes at a higher level. Move code related to your app's scene or UI into the UISceneDelegate. Remember that adopting scenes doesn't necessarily mean supporting multiple scenes; an app can be scene-based but still support only one scene. Refer to the tech note Migrating to the UIKit scene-based life cycle and the Make your UIKit app more flexible WWDC25 session for more information.

I have a PDF which contains geocoordinates. I'm extracting out that image with the following code (this is for an iOS application): guard let cgDocument = CGPDFDocument(overlay.pdfUrl as CFURL) else { return } guard let cgPage = cgDocument.page(at: 1) else { return } var boundingRect = self.rect(for: overlay.boundingMapRect) let pdfPageRect = cgPage.getBoxRect(.mediaBox) let renderer = UIGraphicsImageRenderer(size: pdfPageRect.size) var img = renderer.image { ctx in UIColor.white.set() ctx.fill(pdfPageRect) ctx.cgContext.translateBy(x: 0.0, y: pdfPageRect.size.height) ctx.cgContext.scaleBy(x: 1.0, y: -1.0) ctx.cgContext.drawPDFPage(cgPage) } Once I have that image, I then need to adjust it to fit the specific coordinate corners. For that, I'm doing the following using a perspectiveTransform: let ciImg = CIImage(image: img)! let perspectiveTransformFilter = CIFilter.perspectiveTransform() perspectiveTransformFilter.inputImage = ciImg perspectiveTransformFilter.topRight = cartesianForPoint(point: ur, extent: boundingRect) perspectiveTransformFilter.topLeft = cartesianForPoint(point: ul, extent: boundingRect) perspectiveTransformFilter.bottomRight = cartesianForPoint(point: lr, extent: boundingRect) perspectiveTransformFilter.bottomLeft = cartesianForPoint(point: ll, extent: boundingRect) let txImg = perspectiveTransformFilter.outputImage! img = UIImage(ciImage: txImg) The original image is 792 x 612 (a landscape PDF) but the boundingRect covering the coordinates is 25625 x 20030. Obviously when I try to draw the image into that bounding box the app runs out of memory (25625 x 20030 x 4 is around 2GB of memory). What I'm struggling with is - how do I correctly scale this image to fit into the bounding box even though the bounding box is, oh, 10x the resolution of the actual device? There's some key CoreGraphics thing I'm sure I'm missing here.

NavigationLinks do not display correctly in tvOS 26. When using a Button, the correct behavior of vertically placing an Image or AsyncImage above one or two Text fields occurs. However, when using NavigationLink the image and text(s) are laid out horizontally. Attempting to fix this using a VStack prevents the text from sliding down as the NavigationLink receives focus. Using the hoverEffect modifier does not help. Using a Button (correct behavior): Using a NavigationLink without VStack: Using a NavigationLink with VStack:

Hi everyone! I'm building a tvOS 18.5 app using SwiftUI in Xcode 16.4, and I'm having trouble reliably detecting button clicks from the 2nd generation Siri Remote. .onMoveCommand(perform: handleMoveCommand) func handleMoveCommand(_ direction: MoveCommandDirection) { switch direction { case .right: nextQuote() case .left: previousQuote() default: break } } Swiping left or right on the remote's touch surface works as expected, the callback fires every time. However, when I press the physical left/right buttons (outside the touch surface), the input is unreliable. Sometimes it registers, other times I need to press multiple times or nothing happens at all. I’ve confirmed the view is .focusable(true) and bound with @FocusState. Is this a known limitation or bug with .onMoveCommand on recent tvOS versions? Or is there a more robust way to handle physical Siri Remote button presses?

One screen in my app uses a navigation bar with some buttons added to the titleView and some buttons added as a customView of a single rightBarButtonItem. In iOS 26 (beta 9), if I switch to the home screen and back again, the titleView and rightBarButtonItem disappear and an overflow button (three dots) appears instead. Nothing happens when I click the overflow button. Here's a screen capture: https://youtu.be/tthRnMz98kA This also happens when I switch to another app, when I rotate the device or when I resize the app window. In all cases, there is enough room to show all the buttons, but they still disappear. I overrode the viewWillTransition function in my view controller and logged when that runs. I can see that if I switch to the home screen and back again before that runs (within one or two seconds), there's no problem. But once that runs, the navigation bar items disappear and the overflow button appears. I have not done anything to set up the overflow button and don't have any need to use it. The documentation about it isn't very detailed, but it seems like it shouldn't be used unless I add it. This wasn't a problem in iOS 18 or earlier iOS versions. Does anyone know how to stop this? BTW, I'm using Swift, but not SwiftUI.

Hi everyone! I've encountered an issue when using Sheet + ScrollView on Mac Catalyst: the buttons in the toolbar appear with an abnormal gray color. import SwiftUI struct ContentView: View { var body: some View { VStack { } .sheet(isPresented: .constant(true)) { Sheet() } } } struct Sheet: View { var body: some View { NavigationStack { ScrollView { // <-- no issue if use List } .toolbar { Button(action: {}) { // <-- 👀 weird gray color Image(systemName: "checkmark") } } } } } Steps to Reproduce: On macOS 26.0 beta 9, use Xcode 26.0 beta 7 to create an iOS project and enable Mac Catalyst. Paste the code above. Select the Mac Catalyst scheme and run the project. The buttons in the toolbar show a strange gray appearance. If you change the ScrollView to a List in the code, the issue does not occur. FB20120285

I have been banging my head against this problem for a bit now. I am trying to build a bidirectional, infinitely scrolling list that implements these core requirements: Loads data up/down on the fly as the user scrolls Preserves scroll velocity as the list is updated Restores the scroll to the exact visual location after data has changed Ensures no flicker when restoring scroll position - the user cannot know the list has updated and should continue scrolling as normal Because LazyVStack does not play well with animations, I am opting to go with VStack and am implementing my own sliding window for data. This means that data can be removed as well as added, and a simple application of a height delta is not enough when restoring position. So far I have tried many things: Relying on ScrollPosition - simply does not work by itself as described (swift UI trying to keep the position stable with ID's) Relying on ScrollPosition.scrollTo - only kind of works with ID, no way to restore position with pixel perfect accuracy Intercepting the UIKit scrollView instance, using it to record and access the top row's position, mutating data and then queuing a scroll restoration using CATransaction.setCompletionBlock - this is the closest I've come, and it satisfies the top 3 requirements but sometimes I get a flicker on slightly heavier lists What I would really like, is a way of using ScrollView and granularly hooking into the lifecycle of the view after layout, and just before draw. At this point I would update the relevant scroll positions, and allow draw to continue. Is this possible? My knowledge is very limited at this point, but I believe I may be able to achieve something of the sort by swizzling layerWillDraw? Does this make sense, and is it prudent? In general, I'm very interesting in hearing what people have to say about the above, as well as this problem in general.

Environment iOS 26.0 (device), Xcode 26 beta 7 SwiftUI TabView using the new Tab("…", value:) API iPhone only (aware that minimize is iPhone-only) Issue .tabBarMinimizeBehavior(.onScrollDown) only works reliably in my Settings tab. In my other tabs (Dashboard / Games / Help), the tab bar does not minimize when scrolling, even though the content is scrollable. The main difference: those tabs are wrapped in a NavigationStack(path:) with a bound NavigationPath. Settings has no path binding. Repro (minimal) import SwiftUI enum TabSel: Hashable { case dashboard, games, settings } struct Root: View { @State private var selection: TabSel = .dashboard // Per-tab paths @State private var dashPath = NavigationPath() @State private var gamesPath = NavigationPath() var body: some View { if #available(iOS 26, *) { TabView(selection: $selection) { // ❌ Does NOT minimize when scrolling SwiftUI.Tab("Dashboard", systemImage: "square.grid.2x2.fill", value: .dashboard) { NavigationStack(path: $dashPath) { ScrollView { // ... } } } // ❌ Same here SwiftUI.Tab("Games", systemImage: "sportscourt.fill", value: .games) { NavigationStack(path: $gamesPath) { ScrollView { // ... } } } // ✅ Minimizes as expected on scroll SwiftUI.Tab("Settings", systemImage: "gear", value: .settings) { // Note: also inside a NavigationStack, but no `path` binding NavigationStack { ScrollView { // ... } } } } .tabBarMinimizeBehavior(.onScrollDown) } } } What I tried Removing nested stacks in child views → no change Ensured no .tabViewStyle(.page) / PageTabViewStyle() anywhere No toolbar(.hidden, for: .tabBar) on the tab roots Confirmed the content is scrollable and tested on device Expected All tabs should minimize the tab bar on downward scroll. Actual Only the Settings tab (no path binding) minimizes; tabs with NavigationStack(path:) do not. Questions Is this a known issue with NavigationStack(path:) and .tabBarMinimizeBehavior in iOS 26 betas? Any recommended workaround that keeps a bound NavigationPath per tab?

I’m trying to keep a specific row visually stable while the data backing a ScrollView changes. Goal 1. Before updating model.items, capture the top row’s offset relative to the scroll view. 2. Mutate the observable state so SwiftUI recomputes layout — but don’t draw yet. 3. Read the new layout, compute the delta, and adjust the scroll position so the previously visible row stays put. 4. Only then draw the new frame. Reduced example @Observable final class SomeModel { var items: [SomeItem] = [/* ... */] } struct MyBox: View { @Environment(SomeModel.self) private var model var body: some View { ScrollView { VStack { ForEach(model.items, id: \.id) { item in Color.red.frame(height: randomStableHeight(for: item.id)) } } } } } // Elsewhere: let oldRow = recordOldRow() // capture the row to stabilize model.items = generateNewItems() // mutate model (invalidates layout) let newPos = capturePreviousRowNewPosition(oldRow) // read new layout? restoreScrollPosition() // adjust so oldRow stays visually fixed // draw now Is that pipeline achievable in SwiftUI? If not, what’s the supported way to keep a row visually stable while the list updates?

Here is a simple view to demonstrate the issue struct ContentView: View { @State private var isPresented = false var body: some View { VStack { Button("Test") { isPresented = true } } .alert("Test", isPresented: $isPresented, actions: { Button("Delete All", role: .destructive) {} }, message: { Text("Are You Sure?") }) .padding() } }``` Which results in ![example alert]("https://developer.apple.com/forums/content/attachment/c6210120-d82e-4df5-a01a-fc5cb168e1bf" "title=Screenshot 2025-09-08 at 08.57.21.png;width=546;height=442") The destructive button is almost unreadable. WCAG score is 1.4, far below the minimum recommended 4.5. I found [this post](https://stackoverflow.com/q/66448869) on SO going back to Big Sur, but not on this forum. Any known workarounds (except for building my own dialogs, which I am trying to avoid)? Using confirmationDialog instead of alert does not make a difference.

I'm being faced with an issue when using SwiftUI's WebView on iOS 26. In many websites, the top/bottom content is unaccessible due to being under the app's toolbars. It feels like the WebView doesn't really understand the safe areas where it's being shown, because the content should start right below the navigation bar, and only when the user scrolls down, the content should move under the bar (but it's always reachable if the users scroll back up). Here's a demo of the issue: Here's a 'fix' by ensuring that the content of the WebView never leaves its bounds. But as you can see, it feels out of place on iOS 26 (would be fine on previous OS versions if you had a fully opaque toolbar): Code: struct ContentView: View { var body: some View { NavigationStack { WebView(url: URL(string: "https://apple.com")).toolbar { ToolbarItem(placement: .primaryAction) { Button("Top content covered, unaccessible.") {} } } } } } Does anyone know if there's a way to fix it using some sort of view modifier combination or it's just broken as-is?

I had noticed an unsettling behaviour about NSDocument some years ago and created FB7392851, but the feedback didn't go forward, so I just updated it and hopefully here or there someone can explain what's going on. When running a simple document-based app with a text view, what I type before closing the app may be discarded without notice. To reproduce it, you can use the code below, then: Type "asdf" in the text view. Wait until the Xcode console logs "saving". You can trigger it by switching to another app and back again. Type something else in the text view, such as "asdf" on a new line. Quit the app. Relaunch the app. The second line has been discarded. Am I doing something wrong or is this a bug? Is there a workaround? class ViewController: NSViewController { @IBOutlet var textView: NSTextView! } class Document: NSDocument { private(set) var text = "" override class var autosavesInPlace: Bool { return true } override func makeWindowControllers() { let storyboard = NSStoryboard(name: NSStoryboard.Name("Main"), bundle: nil) let windowController = storyboard.instantiateController(withIdentifier: NSStoryboard.SceneIdentifier("Document Window Controller")) as! NSWindowController (windowController.contentViewController as? ViewController)?.textView.string = text self.addWindowController(windowController) } override func data(ofType typeName: String) throws -> Data { Swift.print("saving") text = (windowControllers.first?.contentViewController as? ViewController)?.textView.string ?? "" return Data(text.utf8) } override func read(from data: Data, ofType typeName: String) throws { text = String(decoding: data, as: UTF8.self) (windowControllers.first?.contentViewController as? ViewController)?.textView.string = text } }

I have installed the iOS 26 Beta on my device and conducted a comprehensive functionality test of my iOS application, which I designed and developed. The application includes a feature that allows users to share images directly to X (formerly Twitter) and Facebook. During testing, I encountered an issue where the icons for X (formerly Twitter) and Facebook do not appear in the share dialog, despite both apps being installed on the device. This issue prevents users from sharing images to these platforms directly from the app. Steps to Reproduce: 1.Install iOS 26 Beta on a compatible device. 2.Ensure that both the X (formerly Twitter) and Facebook apps are installed and logged in on the device. 3.Open the iOS application and navigate to the image sharing feature. 4.Attempt to share an image using the share dialog. 5.Observe that the icons for X (formerly Twitter) and Facebook are missing from the share options. Expected Behavior: The share dialog should display icons for X (formerly Twitter) and Facebook, allowing users to share images directly to these platforms. Actual Behavior: The icons for X (formerly Twitter) and Facebook do not appear in the share dialog, preventing direct sharing to these platforms. Code Implementation: I have not implemented any code to exclude X (formerly Twitter) and Facebook from the share options. Below is the relevant code for controlling the share screen: let activityViewController = UIActivityViewController(activityItems: activityItems, applicationActivities: applicationActivities) let excludedTypes = [ UIActivity.ActivityType.assignToContact, UIActivity.ActivityType.print, ] activityViewController.excludedActivityTypes = excludedTypes activityViewController.completionWithItemsHandler = completion self.present(activityViewController, animated: true, completion: nil) As shown in the implementation, there is no exclusion of X (formerly Twitter) and Facebook, yet their icons do not appear in the share dialog.

In iOS 26, should we have bootloader that runs the repo on startup - or should we have that inside tasks in root view? we have repos that runs as a «closed» functions, we dont throw but updates swiftdata and we use @query in the views. So what is best? and for the repo we should have a repo that runs the upserts manage relations eg? Should that run on a modelactor?

i am try to build an app that show beautiful result represent the user activity. but i found that if i write metal code in the View of some DeviceActivityReportScene, the metal code wasn't working. (the same metal code works in other taget) i can switch to canvas, but the perform is bad compare with metal. can use metal? or it is just not working?

With the correct corner radius changing in iOS 26, I wondered if there is a way to get properly rounded corners inside containers like sheets without hard-coding a constant value. Here's the results of some experiments I did, example code below. The new in Beta 4 ConcentricRectangle seems nice. Notable here is that it doesn't pick up the larger corner radii from the device corners: If you want all the corners rounded, the isUniform parameter of ConcentricRectangle seems helpful. It doesn't apply the corners in a View in the middle though, not sure if this is an oversight or if this has some purpose: ContainerRelativeShape looks ... interesting ... as of Beta 4, with the larger bottom corners rounded according to the device corners, but the actual bottom corners not fitting the device corners. With ContainerRelativeShape one can also get the middle part to have proper rounded corners in this example ... if you set the outer .containerShape(RoundedRectangle(cornerRadius: 36)) yourself. Notable here is that it then actually adapts all corners of the last card to the larger device corner radius - why it does that even with the smaller radius being explicitly set as containerShape is beyond my imagination. ContainerRelativeShape and ConcentricRectangle both feel quite similar to me, but different in ways that are not clear to me after reading the documentation. I wouldn't know when to pick which / I am not sure if these two should really be two separate things... Any insights here? I was also hoping to find a way to read the cornerRadius (both device corner radius and sheet container radius) for more complex custom-shaped views, but currently there seems no way to do that. The new in iOS 26 Beta 4 GeometryReader containerCornerInsets sounded a bit like it, but it seems of no use here, it's always zero. docs talk about windowing controls and values can be seen on iPad when the red/yellow/green window buttons become visible, so it seems unrelated here. Example code AdaptiveCorners.swift import SwiftUI enum Experiment: String, CaseIterable, Identifiable { case form case concentricRect case uniformConcentricRect case containerRelative case containerRelativeWithContainerShape case containerCornerInsets var title: String { self.rawValue } var id: String { self.rawValue } } struct ContentView: View { @State var experiment : Experiment? = .concentricRect var body: some View { NavigationStack { Form { Picker("Experiment", selection: $experiment) { ForEach(Experiment.allCases, id: \.self) { experiment in Text(experiment.title).tag(experiment) } } .pickerStyle(.inline) } } .sheet(item: $experiment) { experiment in Group { switch(experiment) { case .form: Form { Section { Text("Form + Section") Text("Form + Section") } } case .concentricRect: ShapeView { ConcentricRectangle() } case .uniformConcentricRect: ShapeView { ConcentricRectangle(corners: .concentric, isUniform: true) } case .containerRelative: ShapeView { ContainerRelativeShape() } case .containerRelativeWithContainerShape: ShapeView { ContainerRelativeShape() } .containerShape(RoundedRectangle(cornerRadius: 36)) case .containerCornerInsets: GeometryReader { geometry in Form { Text(String(describing: geometry.containerCornerInsets)) } } } } .presentationDetents([.medium, .large]) } } } struct ShapeView<S : Shape> : View { @ViewBuilder let content: () -> S var body: some View { ScrollView([.vertical]) { VStack { HStack { content() .fill(Color.yellow) .frame(height: 80) .frame(maxWidth: .infinity) content() .fill(Color.orange) .frame(height: 80) .frame(maxWidth: .infinity) } content() .fill(Color.green) .frame(height: 80) .frame(maxWidth: .infinity) } .padding() } } } #Preview { ContentView() }

I have SwiftData models containing arrays of Codable structs that worked fine before adding CloudKit capability. I believe they are the reason I started seeing errors after enabling CloudKit. Example model: @Model final class ProtocolMedication { var times: [SchedulingTime] = [] // SchedulingTime is Codable // other properties... } After enabling CloudKit, I get this error logged to the console: 'NSKeyedUnarchiveFromData' should not be used to for un-archiving and will be removed in a future release CloudKit Console shows this times data as "plain text" instead of "bplist" format. Other struct/enum properties display correctly (I think) as "bplist" in CloudKit Console. The local SwiftData storage handled these arrays fine - this issue only appeared with CloudKit integration. What's the recommended approach for storing arrays of Codable structs in SwiftData models that sync with CloudKit?

(Using macOS 26 Beta 9 and Xcode 26 Beta 7) I am trying to support basic onDrop from a source app to my app. I am trying to get the closest "source" representation of a drag-and-drop, e.g. a JPEG file being dropped into my app shouldn't be converted, but stored as a JPEG in Data. Otherwise, everything gets converted into TIFFs and modern iPhone photos get huge. I also try to be a good app, and provide asynchronous support. Alas, I've been running around for days now, where I can now support Drag-and-Drop from the Finder, from uncached iCloud files with Progress bar, but so far, drag and dropping from Safari eludes me. My code is as follows for the onDrop support: Image(nsImage: data.image).onDrop(of: Self.supportedDropItemUTIs, delegate: self) The UTIs are as follows: public static let supportedDropItemUTIs: [UTType] = [ .image, .heif, .rawImage, .png, .tiff, .svg, .heic, .jpegxl, .bmp, .gif, .jpeg, .webP, ] Finally, the code is as follows: public func performDrop(info: DropInfo) -> Bool { let itemProviders = info.itemProviders(for: Self.supportedDropItemUTIs) guard let itemProvider = itemProviders.first else { return false } let registeredContentTypes = itemProvider.registeredContentTypes guard let contentType = registeredContentTypes.first else { return false } var suggestedName = itemProvider.suggestedName if suggestedName == nil { switch contentType { case UTType.bmp: suggestedName = "image.bmp" case UTType.gif: suggestedName = "image.gif" case UTType.heic: suggestedName = "image.heic" case UTType.jpeg: suggestedName = "image.jpeg" case UTType.jpegxl: suggestedName = "image.jxl" case UTType.png: suggestedName = "image.png" case UTType.rawImage: suggestedName = "image.raw" case UTType.svg: suggestedName = "image.svg" case UTType.tiff: suggestedName = "image.tiff" case UTType.webP: suggestedName = "image.webp" default: break } } let progress = itemProvider.loadInPlaceFileRepresentation(forTypeIdentifier: contentType.identifier) { url, _, error in if let error { print("Failed to get URL from dropped file: \(error)") return } guard let url else { print("Failed to get URL from dropped file!") return } let queue = OperationQueue() queue.underlyingQueue = .global(qos: .utility) let intent = NSFileAccessIntent.readingIntent(with: url, options: .withoutChanges) let coordinator = NSFileCoordinator() coordinator.coordinate(with: [intent], queue: queue) { error in if let error { print("Failed to coordinate data from dropped file: \(error)") return } do { // Load file contents into Data object let data = try Data(contentsOf: intent.url) Dispatch.DispatchQueue.main.async { self.data.data = data self.data.fileName = suggestedName } } catch { print("Failed to load coordinated data from dropped file: \(error)") } } } DispatchQueue.main.async { self.progress = progress } return true } For your information, this code is at the state where I gave up and sent it here, because I cannot find a solution to my issue. Now, this code works everywhere, except for dragging and dropping from Safari. Let's pretend I go to this web site: https://commons.wikimedia.org/wiki/File:Tulip_Tulipa_clusiana_%27Lady_Jane%27_Rock_Ledge_Flower_Edit_2000px.jpg and I try to drag-and-drop the image, it will fail with the following error: URL https://upload.wikimedia.org/wikipedia/commons/c/cf/Tulip_Tulipa_clusiana_%27Lady_Jane%27_Rock_Ledge_Flower_Edit_2000px.jpg is not a file:// URL. And then, fail with the dreaded Failed to get URL from dropped file: Error Domain=NSItemProviderErrorDomain Code=-1000 As far as I can tell, the problem lies in the opaque NSItemProvider receiving a web site URL from Safari. I tried most solutions, I couldn't retrieve that URL. The error happens in the callback of loadInPlaceFileRepresentation, but also fails in loadFileRepresentation. I tried hard-requesting a loadObject of type URL, but there's only one representation for the JPEG file. I tried only putting .url in the requests, but it would not transfer it. Anyone solved this mystery?

I want the gray view to have concentric corners with the device border. That works. Then I want the blue rectangle to have concentric corners with the gray view. That does not work. Instead the blue rectangle is also concentric with the device border. Once I add other content like a Text element, the corner radius breaks. How can I make this work? .containerShape does not take a ConcentricContainerShape. struct ContentView: View { var body: some View { List { Text("Content") } .overlay(alignment: .bottom) { content } .ignoresSafeArea(.all, edges: .bottom) } var content: some View { VStack(alignment: .leading) { Rectangle() .foregroundStyle(.blue) .frame(width: 100, height: 100) .clipShape(.rect(corners: .concentric, isUniform: true)) Text("Custom Container") } .padding(20) .frame(maxWidth: .infinity, alignment: .leading) .background(Color.gray, in: .rect(corners: .concentric, isUniform: true)) .padding(15) } }

Hi everyone, I’m running into a strange animation glitch when using a Menu inside a glassEffect container. Here’s a minimal example: import SwiftUI struct ContentView: View { @Namespace private var namespace var body: some View { ZStack { Image(.background) .resizable() .frame(maxWidth: .infinity, maxHeight: .infinity) .ignoresSafeArea() GlassEffectContainer { HStack { Button("b1") {} Button("b2") {} Button("b3") {} Button("b4") {} Button("b5") {} Menu { Button("t1") { } Button("t2") { } Button("t3") { } Button("t4") { } Button("t5") { } } label: { Text("Menu") } } } .padding(.horizontal) .frame(height: 50) .glassEffect() } } } What happens: The bar looks fine initially: When you open the Menu, the entire bar morphs into the menu: When dismissing, the bar briefly animates into a solid rectangle before reapplying the glass effect: Questions: Is there a way to prevent that brief rectangle animation when dismissing the menu? If not, is it possible to avoid the morphing altogether and have the menu simply overlay on top of the bar instead of replacing it? Any ideas or workarounds would be greatly appreciated!

On macOS 15.2, any Mac Catalyst project that does not support portrait iPad orientation will no longer be able to successfully show the contents of any popover controls. This does not appear to be a problem on earlier versions of macOS and it only affects Mac Catalyst builds, not "Designed for iPad" builds. STEPS TO REPRODUCE Create a project that utilizes Mac Catalyst. Create a simple button that shows a popover with simple content. Remove Portrait as a supported orientation. Run the project on macOS 15.2 as a Mac Catalyst build. Note that the content inside the popover is not shown the popover is shown. Run the project as Designed for iPad. Note that the popover content shows correctly.