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.

The sample code provided in "Building a document-based app with SwiftUI" (https://developer.apple.com/documentation/swiftui/building-a-document-based-app-with-swiftui) does not work as expected. The DocumentGroup/StoryView toolbar does not appear for documents opened in the App. By removing the DocumentGroupLaunchScene block from the App the toolbar does appear and works as expected - but of course the App's DocumentGroupLaunchScene customizations are lost. I've tested this on 18.0 devices, as well as production 18.0 and 18.1 beta 6 simulators. If I modify the StoryView by wrapping the content in a NavigationStack I can make some progress - but the results are unstable and hard to pin down - with this change the first time a document is opened in the WritingApp the toolbar appears as expected. When opening a document subsequently the toolbar is corrupted. Please is this a bug or is there a good example of incorporate both DocumentGroupLaunchScene customizations at the App level and retina the toolbar in documents presented via DocumentGroup?

I added gesture support to my app that supports iOS 16 and 17 and have never had issues with it. However, when I compiled my app with Xcode 16 I immediately noticed a problem with the app when I ran it in the simulator. I couldn't scroll up or down. I figured out it’s because of my gesture support. My gesture support is pretty simple. let myDragGesture = DragGesture() .onChanged { gesture in self.offset = gesture.translation } .onEnded { _ in if self.offset.width > threshold { ...some logic } else if self.offset.width < -threshold { ...some other logic } logitUI.debug("drag gesture width was \(self.offset.width)") self.offset = .zero } If I pass nil to .gesture instead of myDragGesture then scrolling starts working again. Here’s some example output when I’m trying to scroll down. These messages do NOT appear when I run my app on an iOS 16/17 simulator with Xcode 15. drag gesture width was 5.333328 drag gesture width was -15.333344 drag gesture width was -3.000000 drag gesture width was -24.333328 drag gesture width was -30.666656 I opened FB14205678 about this.

I'm currently integrating SwiftUI into an AppKit based application and was curious if the design pattern below was viable or not. In order to "bridge" between AppKit and SwiftUI, most of my SwiftUI "root" views have aViewModel that is accessible to the SwiftUI view via @ObservedObject. When a SwiftUI views need to use NSViewRepresentable I'm finding the use of a ViewModel and a Coordinator to be an unnecessary layer of indirection. In cases where it makes sense, I've just used the ViewModel as the Coordinator and it all appears to be working ok, but I'm curious if this is reasonable design pattern or if I'm overlooking something. Consider the following pseudo code: // 1. A normal @ObservedObject acting as the ViewModel that also owns and manages an NSTableView. @MainActor final class ViewModel: ObservedObject, NSTableView... { let scrollView: NSScrollView let tableView: NSTableView @Published var selectedTitle: String init() { // ViewModel manages tableView as its dataSource and delegate. tableView.dataSource = self tableView.delegate = self } func reload() { tableView.reloadData() } // Update view model properties. // Simpler than passing back up through a Coordinator. func tableViewSelectionDidChange(_ notification: Notification) { selectedTitle = tableView.selectedItem.title } } // 2. A normal SwiftUI view, mostly driven by the ViewModel. struct ContentView: View { @ObservedObject model: ViewModel var body: some View { Text(model.selectedTitle) // No need to pass anything down other than the view model. MyTableView(model: model) Button("Reload") { model.reload() } Button("Delete") { model.deleteRow(...) } } } // 3. A barebones NSViewRepresentable that just vends the required NSView. No other state is required as the ViewModel handles all interactions with the view. struct MyTableView: NSViewRepresentable { // Can this even be an NSView? let model: ViewModel func makeNSView(context: Context) -> some NSView { return model.scrollView } func updateNSView(_ nsView: NSViewType, context: Context) { // Not needed, all updates are driven through the ViewModel. } } From what I can tell, the above is working as expected, but I'm curious if there are some situations where this could "break", particularly around the lifecycle of NSViewRepresentable Would love to know if overall pattern is "ok" from a SwiftUI perspective.

It looks like I'm one of the rare developers dealing with CarPlay... I develop a CarPlay extension for my apps. A few things: especially when using the CarPlay I/O window in iOS Simulator, I get random selection highlightning for list items: I have three list templates in a tab template; once I reselect a list using the tab which has been selected before, the initial list item highlights / returns to normal every refresh of the list content; while this doesn't happen for my real world Sony CarPlay device, I'd rather not see such disturbing highlighting for my users. I do not update the template structs or items here, it is just content like text of detailText I update. Question: how to remove highlightning programmatically - especially for devices with touch screen? I have one user who reports auto-selection of UI elements while driving; I assume this is some problem with his touch screen, but it may be a general issue too. Question: anyone with similar observations connecting my iPhone to the stand-alone Car Play simulator doesn't work; I had it working before, so it might be related to a recent iOS beta... Any hints / observations are welcome. The CarPlay community really seems to be small and I'd like to hear other's experience on the named items.

In my CarPlay app, I am hiding the navigation bar by using the following: self.mapTemplate?.automaticallyHidesNavigationBar = true self.mapTemplate?.hidesButtonsWithNavigationBar = false I don't want the navigation bar to show unless a user interacts with the map by tapping it. Strangely, when I present a CPNavigationAlert the navigation bar will often appear and then disappear after the alert is dismissed. Is there a setting or reason that the navigation bar would be appearing when presenting this alert? I would like to keep the nav bar hidden during this time.

Is it actually possible to display animation (even a simple one) on Live Activity? But on these cases: The main app is terminated - of course, I know I can use the main app to keep updating the Live Activity to make simple animations work, but in this case, the main app is killed. Live Activity data is not updating - I also understand that the Live Activity can perform animations when its data is being update via push notification or other means, but the current case is the data is not being updated. I’ve tried several ways to achieve this, but nothing seems to work. Just when I was about to give up, I found this video from Apple’s official channel: https://www.youtube.com/watch?v=m6WMwSj_EbA At 4:14 in this video, you can see the text "Locating Driver" with the breathing animation. Could someone please help me understand how to implement that kind of animation in a Live Activity when: The main app is not running, and The Live Activity data is not updating?

I have a UILabel subclass showing NSAttributedString in which I need to draw a rounded rectangle background color around links: import UIKit class MyLabel: UILabel { private var linkRects = [[CGRect]]() private let layoutManager = NSLayoutManager() private let textContainer = NSTextContainer(size: .zero) private let textStorage = NSTextStorage() override func draw(_ rect: CGRect) { let path = UIBezierPath() linkRects.forEach { rects in rects.forEach { linkPieceRect in path.append(UIBezierPath(roundedRect: linkPieceRect, cornerRadius: 2)) } } UIColor.systemGreen.withAlphaComponent(0.4).setFill() path.fill() super.draw(rect) } override init(frame: CGRect) { super.init(frame: frame) setup() } required init?(coder: NSCoder) { super.init(coder: coder) setup() } private func setup() { numberOfLines = 0 adjustsFontForContentSizeCategory = true isUserInteractionEnabled = true lineBreakMode = .byWordWrapping contentMode = .redraw clearsContextBeforeDrawing = true isMultipleTouchEnabled = false backgroundColor = .red.withAlphaComponent(0.1) textContainer.lineFragmentPadding = 0 textContainer.maximumNumberOfLines = numberOfLines textContainer.lineBreakMode = lineBreakMode textContainer.layoutManager = layoutManager layoutManager.textStorage = textStorage layoutManager.addTextContainer(textContainer) textStorage.addLayoutManager(layoutManager) } override func layoutSubviews() { super.layoutSubviews() calculateRects() } private func calculateRects(){ linkRects.removeAll() guard let attributedString = attributedText else { return } textStorage.setAttributedString(attributedString) let labelSize = frame.size textContainer.size = labelSize layoutManager.ensureLayout(for: textContainer) let textBoundingBox = layoutManager.usedRect(for: textContainer) print("labelSize: \(labelSize)") print("textBoundingBox: \(textBoundingBox)") var wholeLineRanges = [NSRange]() layoutManager.enumerateLineFragments(forGlyphRange: NSRange(0 ..< layoutManager.numberOfGlyphs)) { _, rect, _, range, _ in wholeLineRanges.append(range) print("Whole line: \(rect), \(range)") } attributedString.enumerateAttribute(.link, in: NSRange(location: 0, length: attributedString.length)) { value, clickableRange, _ in if value != nil { var rectsForCurrentLink = [CGRect]() wholeLineRanges.forEach { wholeLineRange in if let linkPartIntersection = wholeLineRange.intersection(clickableRange) { var rectForLinkPart = layoutManager.boundingRect(forGlyphRange: linkPartIntersection, in: textContainer) rectForLinkPart.origin.y = rectForLinkPart.origin.y + (textContainer.size.height - textBoundingBox.height) / 2 // Adjust for vertical alignment rectsForCurrentLink.append(rectForLinkPart) print("Link rect: \(rectForLinkPart), \(linkPartIntersection)") } } if !rectsForCurrentLink.isEmpty { linkRects.append(rectsForCurrentLink) } } } print("linkRects: \(linkRects)") setNeedsDisplay() } } And I use this as such: let label = MyLabel() label.setContentHuggingPriority(.required, for: .vertical) label.setContentHuggingPriority(.required, for: .horizontal) view.addSubview(label) label.snp.makeConstraints { make in make.width.lessThanOrEqualTo(view.safeAreaLayoutGuide.snp.width).priority(.required) make.horizontalEdges.greaterThanOrEqualTo(view.safeAreaLayoutGuide).priority(.required) make.center.equalTo(view.safeAreaLayoutGuide).priority(.required) } let paragraphStyle = NSMutableParagraphStyle() paragraphStyle.alignment = .justified let s = NSMutableAttributedString(string: "Lorem Ipsum: ", attributes: [.font: UIFont.systemFont(ofSize: 17, weight: .regular), .paragraphStyle: paragraphStyle]) s.append(NSAttributedString(string: "This property controls the maximum number of lines to use in order to fit the label's text into its bounding rectangle.", attributes: [.link: URL(string: "https://news.ycombinator.com/") as Any, .foregroundColor: UIColor.link, .font: UIFont.systemFont(ofSize: 14, weight: .regular), .paragraphStyle: paragraphStyle])) label.attributedText = s Notice the paragraphStyle.alignment = .justified This results in: As you can see, the green rect background is starting a bit further to the right and also ending much further to the right. If I set the alignment to be .left or .center, then it gives me the correct rects: Also note that if I keep .justified but change the font size for the "Lorem Ipsom:" part to be a bit different, lets say 16 instead of 17, then it gives me the correct rect too: Also note that if we remove some word from the string, then also it starts giving correct rect. It seems like if the first line is too squished, then it reports wrong rects. Why is .justified text alignment giving me wrong rects? How can I fix it?

Hello, I am trying to match the font and the position of the date and time displayed. This is what it looks like: .font: NSFont.systemFont(ofSize: NSFont.systemFontSize, weight: .regular), .foregroundColor: NSColor.labelColor, .baselineOffset: 0.5 It looks great on built-in display, but on external 4K it is incorrect. The baselineOffest is unnecessary, and the font looks skinny in comparison. Can anyone comment on such issue?

Please has anyone found a workaround for duplicate back buttons appearing on the toolbar of a ContentView launched from a DocumentGroup? The problem occurs with Xcode 14.0 running a basic DocumentGroup App on iOS 16.0. To reproduce, simply build a new project using the "Document App" template. Build and run in the iOS/iPadOS simulator or on an iOS/iPadOS device. Two back buttons appear. Only one functions. I've not found a way to eliminate the dud. This problem has occurred throughout the Xcode 14.0 beta program.

I have a popover/sheet in iOS which allows users to search and add items to a list. When the sheet is shown, the search should always be active. I am using searchable on a NavigationStack inside the sheet. I am using the isPresented parameter to activate search. My issue is with the animation of the search activation. Even if I use... isPresented: .constant(true) ...the search isn't activated until the sheet has completed it's entrance animation, resulting in two stages of animation. I can't add a video here, but the two images below show the steps I am seeing. First a slide up animation, with the search in the navigation drawer, then a second animation, once the sheet is fully in place, as the search becomes active. Is it possible to merge these two animations, so search is in place when the sheet animates up?

QuickTime recording palette behaves in a way which I want to replicate in my desktop app - specifically the behaviour when switching spaces, it appears on top. Currently, my app appears on all spaces, and even over fullscreen applications BUT it already exists when I switch to the space, this feels disjointed. I can't find a solution to this behaviour. Here's the Window Collection Behaviours I've tried (on an NSPanel): FullScreenAuxiliary - appears over fullscreen apps. CanJoinAllSpaces - appears on all spaces. These two options make the dock show up on all spaces in the same position, but on each space they already exists. I've tried this behaviour too: MoveToActiveSpace - which as per docs would move the window into active space only when its reopened, mine stays open all the time. I can't find any more information on how QuickTime achieves this.

We're observing new crashes specifically on iOS 18.4 devices with this pattern: Exception Type: SIGTRAP Exception Codes: fault addr: 0x000000019bc0f088 Crashed Thread: 0 Thread 0 0 libsystem_malloc.dylib _xzm_xzone_malloc_from_tiny_chunk.cold.1 + 36 1 libsystem_malloc.dylib __xzm_xzone_malloc_from_tiny_chunk + 612 2 libsystem_malloc.dylib __xzm_xzone_find_and_malloc_from_tiny_chunk + 112 3 libsystem_malloc.dylib __xzm_xzone_malloc_tiny_outlined + 312 4 CoreGraphics CG::Path::Path(CG::Path const&) + 132 5 CoreGraphics _CGPathCreateMutableCopyByTransformingPath + 112 6 CoreGraphics _CGFontCreateGlyphPath + 144 7 CoreGraphics _CGGlyphBuilderLockBitmaps + 1112 8 CoreGraphics _render_glyphs + 292 9 CoreGraphics _draw_glyph_bitmaps + 1116 10 CoreGraphics _ripc_DrawGlyphs + 1464 11 CoreGraphics CG::DisplayList::executeEntries(std::__1::__wrap_iter<std::__1::shared_ptr<CG::DisplayListEntry const>*>, std::__1::__wrap_iter<std::__1::shared_ptr<CG::DisplayListEntry const>*>, CGContextDelegate*, CGRenderingState*, CGGStack*, CGRect const*, __CFDictionary const*, bool) + 1328 12 CoreGraphics _CGDisplayListDrawInContextDelegate + 340 13 QuartzCore _CABackingStoreUpdate_ + 612 14 QuartzCore ____ZN2CA5Layer8display_Ev_block_invoke + 120 15 QuartzCore -[CALayer _display] + 1512 16 QuartzCore CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 420 17 QuartzCore CA::Context::commit_transaction(CA::Transaction*, double, double*) + 476 18 QuartzCore CA::Transaction::commit() + 644 19 UIKitCore ___34-[UIApplication _firstCommitBlock]_block_invoke_2 + 36 20 CoreFoundation ___CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 21 CoreFoundation ___CFRunLoopDoBlocks + 352 22 CoreFoundation ___CFRunLoopRun + 868 23 CoreFoundation _CFRunLoopRunSpecific + 572 24 GraphicsServices _GSEventRunModal + 168 25 UIKitCore -[UIApplication _run] + 816 26 UIKitCore _UIApplicationMain + 336 27 app _main + 132 28 dyld __dyld_process_info_create + 33284 Key Observations: Crash occurs during font glyph path creation (CGFontCreateGlyphPath) Involves memory allocation in malloc's xzone implementation 100% reproducible on iOS 18.4, not seen in prior OS versions Occurs during standard CALayer rendering operations Not tied to any specific font family or glyph content Questions for Apple: Is this crash signature recognized as a known issue in iOS 18.4's CoreGraphics? Could changes to xzone memory management in iOS 18.4 interact poorly with font rendering? Are there specific conditions that might trigger SIGTRAP in CGPathCreateMutableCopyByTransformingPath? Any recommended mitigations for text rendering while awaiting system updates?

I'm trying to switch to UIKit's document lifecycle due to serious bugs with SwiftUI's version. However I'm noticing the template project from Xcode isn't compatible with Swift 6 (I already migrated my app to Swift 6.). To reproduce: File -> New -> Project Select "Document App" under iOS Set "Interface: UIKit" In Build Settings, change Swift Language Version to Swift 6 Run app Tap "Create Document" Observe: crash in _dispatch_assert_queue_fail Does anyone know of a work around other than downgrading to Swift 5?

Hi everyone, Something didn't work in my environment so I wrote some demo code: import SwiftUI @main struct DemoApp: App { var body: some Scene { WindowGroup { Color.accentColor.opacity(1/4) .frame(idealWidth: 800, idealHeight: 800) } .windowIdealSize(.fitToContent) } } I expected a 800*800 window (then +28pt top) using .windowIdealSize(.fitToContent). Otherwise I can't control these views that use up available space such as Color, Spacer, GeometryReader, etc. Was I missing something? Or this is a problem or intended framework design? Environments: macOS 15.4.1 (24E263) and 15.5 beta 4 (24F5068b) Xcode 16.3 (16E140)

In AppKit, NSSegmentedControl has various styles defined by NSSegmentStyle and various tracking modes defined by NSSegmentSwitchTracking. How can we set these properties in SwiftUI? I'm currently using a Picker with the view modifier .pickerStyle(.segmented) applied but this seems to produce a segmented control with tracking set to "select one". In particular I'm looking for momentary tracking so that I can create navigation-style buttons for backward/forward navigation. Under AppKit, the canonical way to do this is an NSSegmentedControl of style separated and tracking momentary. Is that possible under SwiftUI for macOS? (Using the latest versions of everything.)

In SwiftUI for macOS, how can I animate the transition from one Tab to another Tab within TabView when the selection changes? In AppKit, we can do the following: let tabViewController = NSTabViewController() tabViewController.transitionOptions = [.crossfade, .allowUserInteraction] How can I achieve the same crossfade effect when using TabView?

I am building a CarPlay navigation app and I would like it to be as hands free as possible. I need a better understanding of how Siri can work with CarPlay and if the direction I need to go is using Intents or App Shortcuts. My goal is to be able to have the user speak to Siri and do things like "open settings" or "zoom in map" and then call a func in my app to do what the user is asking. Does CarPlay support this? Do I need to use App Intents or App Shortcuts or something else?

I am trying to add custom scheme (CFBundleURLSchemes) to my App Clip. I launch the app clip via TestFlight to cache it to the device then i try to access the custom scheme URL to launch App Clip but nothing happened. May I know if it is something I did wrongly or just App Clip does not support Custom Scheme?

Im student, hobbyst on developing. i have a problem inserting a custom slidee PNG to control volume of an áudio file in an app. The slidee built in Swift, runs ok. When i try to use a custom png it show in the Gui but when move its button right it disappear beyond the maximum but when i move ir left the minimamente is at middle of the slider scale

Something func applicationWillEnterForeground is not getting called for specific iOS 18.3.2