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 Design. Can you expand on how Liquid Glass helps with navigation and focus in the UI? Liquid Glass clarifies the navigation layer by introducing a single, floating pane that acts as the primary navigation area. Buttons within this pane seamlessly morph as you move between sections, and controls can temporarily lift into the glass surface. While avoiding excessive use of glass (like layering glass on glass), this approach simplifies navigation and strengthens the connection between menus, alerts, and the elements that trigger them. What should I do with customized bars that I might have in my app? Reconsider the content and behavior of customized bars. Evaluate whether you need all the buttons and whether a menu might be a better solution. Instead of relying on background colors or styling, express hierarchy through layout and grouping. This is a good opportunity to adopt the new design language and simplify your interface. What are scroll edge effects, and what options do we have for them? Scroll edge effects enhance legibility in controls by lifting interactive elements and separating them from the background. There are two types: a soft edge effect (a subtle blur) and a hard edge effect (a more defined boundary for high-legibility areas like column sorting). Scroll edge effects are designed to work seamlessly with Liquid Glass, allowing content to feel expansive while ensuring controls and titles remain legible. How can we ensure or improve accessibility using Liquid Glass? Legibility is a priority, and refinements are ongoing throughout the betas. Liquid Glass adapts well to accessibility settings like Reduce Transparency, Increase Contrast, and Reduce Motion. There are two variants of glass: regular glass, designed to be legible by default, and clear glass, used in places like AVKit, which requires more care to ensure legibility. Use color contrast tools to ensure contrast ratios are met. The Human Interface Guidelines (HIG) are a living document offering best practices. The colors and materials pages are key resources. Do you have any recommendations for convincing designers concerned with consistency across Android and Web to use Liquid Glass? Start small and focus on high-utility controls that don't significantly impact brand experience. Native controls offer familiarity and predictability to users. Using the native controls makes sure your app feels at home on the device. Using native frameworks provides built-in accessibility support (dynamic type, reduce transparency, increase contrast). Native controls come with built-in behaviors and interactions. Can ScrollViews include Liquid Glass within them? You can technically put a glass layer inside a scroll view, but it can feel heavy and doesn't align with the system's intention for Liquid Glass to serve as a fixed layer. Think of the content layer as the scrolling layer, and the navigational layer as the one using Liquid Glass. If there is glass on the content layer it will collide into the navigational layer. What core design philosophy guided the direction of iOS 26, beyond the goal of unification? The core design philosophy involved blurring the line between hardware and software, separating UI and navigation elements from content, making apps adaptable across window sizes, and combining playfulness with sophistication. It was about making the UI feel at home on rounded screens. Can we layer Liquid Glass elements on top of each other? Avoid layering Liquid Glass elements directly on top of each other, as it creates unnecessary visual complexity. The system will automatically convert nested glass elements to a vibrant fill style. Use vibrant fills and labels to show control shapes and ensure legibility. Opaque grays should be avoided in favor of vibrant colors, which will multiply with the backgrounds correctly. What will happen to apps that use custom components? Should they be adapted to the new design within the next year? The more native components you use, the more things happen for free. Standard components will be upgraded automatically. Look out for any customizations that might clash. Think about what is the minimum viable change, where your app still feels and looks very similar to what it did. Prioritize changes in core workflows and navigational areas. There are a number of benefits to using native components including user familiarity, built-in accessibility support, and built-in behaviors and interactions. Will Apple be releasing Figma design templates? Sketch kits were published on Monday and can be referenced. The goal is to ensure the resources are well-organized, well-named, and easy to use. It's a high priority.

I would like to propose a design enhancement for future iPhone models: using the existing bottom-right antenna line (next to the power button area) as a capacitive “volume control zone” that supports swipe gestures. Today this line is a structural antenna break, but it is also located exactly where the thumb naturally rests when holding the phone in one hand. With a small embedded capacitive/force sensor, the user could slide their finger along this zone to control volume without reaching for the physical buttons. Why this makes sense: • Perfect ergonomic thumb position in both portrait and landscape • One-handed volume adjustment becomes easier for large-screen devices • Silent and frictionless vs. clicking buttons (useful in meetings / night mode) • Consistent with Apple’s recent move toward contextual hardware input (Action Button, Capture Button, Vision Pro gestures) The interaction model would be: • Swipe up → increase volume • Swipe down → decrease volume • (Optional) long-press haptic = mute toggle This could also enhance accessibility, especially for users with reduced hand mobility who struggle to press mechanical buttons on tall devices. Technically, this would be similar to the Capture Button (capacitive + pressure layers), but linear instead of pressure-based. It does not replace physical buttons, it complements them as a silent gesture-based alternative. Thank you for considering this as a future interaction refinement for iPhone hardware design.

We use SwiftUI's .tabViewBottomAccessory in our iOS apps for displaying an Audio MiniPlayer View (like in the Apple Music App). TabView(selection: $viewModel.selectedTab) { // Tabs here } .tabViewBottomAccessory { if viewModel.showAudioMiniPlayer { MiniPlayerView() } } The Problem This code works perfectly on iOS 26.0. When 'viewModel.showAudioMiniPlayer' is 'false', the accessory is completely hidden. However, on iOS 26.1 (23B5059e), when 'viewModel.showAudioMiniPlayer' is 'false', the MiniPlayerView disappears, but an empty container remains, leaving a blank space above the tab bar. Is this a known Bug in iOS 26.1 and are there any effective workarounds or should I just wait until Apple fixed it?

I'm using a NavigationSplitView on macOS which needs to show 2 or 3 columns depending on the selection of the sidebar. Column 1 has a list of main activities. Some of these just have some data to show and some have a sublist. Currently, when an item that has no sublist is selected, I set the 2nd column (content:) to: Spacer() .navigationSplitViewColumnWidth(0) This works, although it started hitting bugs requiring a workaround on macOS 26, which got me wondering, what is the correct approach here? NavigationSplitViewVisibility.doubleColumn is not the solution, as this hides column 1, not column 2.

Hello everyone, In the current iOS version, changes in the "liquid glass" light shining effects can repeatedly be observed on older iPhone devices (12/13/14). This change is often seen after the device is rebooted or after a SystemMemoryReset.ips (System Analysis Data). It changes very often... I'm not currently working on apps myself, but perhaps someone has ideas for the upcoming updates involving Liquid Glass. (please also check the screenshots)

Prior to iOS 26, this successfully gave me a modal view with a transparent background: let settingsVC = MySettingsViewController() settingsVC.modalPresentationStyle = .automatic //settingsVC.modalPresentationStyle = .overCurrentContext self.present(settingsVC, animated: true, completion: { } MySettingsViewController: self.view.backgroundColor = UIColor(white: 0, alpha: 0.5) Now in iOS 26, modal view is presented in a opaque grey background.

I've seen a few older posts claiming the same behavior I'm seeing which is my cloudkit/core data app only syncs to iOS when the iOS app is reloaded. Can someone clarify if this is a bug, or the expected behavior. I have an iOS app which the entire purpose of it is to view synced data from MacOS, and I have a refresh button which does nothing because the data only syncs when the app is closed and reopened. Am I supposed to tell users to close and reopen the app to see fresh data? that seems like a terrible UI behavior, and I know apple does not accept this as all of their apps sync without needing to be reloaded. For example the notes app does not need to be reloaded for the MacOS -> iOS data to be synced.

let glassView = UIVisualEffectView(effect: UIGlassEffect(style: .clear)) glassView.frame = CGRect(x: 100, y: 200, width: 200, height: 400) self.view.addSubview(glassView) Though UIGlassEffect has two variants: .regular and .clear, even the clear one has some blur on the background. Is there a way to do get absolute no blur? Edges still have the glass effect. Apple does this in two places: Camera app: Text magnifier:

I'm in the process of add some swift code that is all objective-c. I have trouble with my actual app so I have worked on a prototype. There is what I have done Created a new Xcode project, selecting App and Objc Added a blank Swift file and accepted the generation of the -Bridging-Header. In project build setting, Yes for Defines Modules, Yes for Always Embed Swift Libraries Add appropriate .h file to Bridging header In Build Settings, in Swift Compiler - General, Bridging Header has correct path to the bridging header file Setup the single swift file in this was using @objc like this: @objcmembers class MySwiftClass: NSObject { func myMethod() { let output = ... } } When the project runs I execute in the objc ViewController: MySwiftClass *swiftObject = [[MySwiftClass alloc] init]; and get Use of undeclared identifier 'MySwiftClass'

Ever since Xcode Version 26.0.1 I cannot for the life of me make my buttons rectangular. They are all capsule (or oval) shaped. My interface was designed for square buttons but no matter what I do the issue stays the same. This is what I have (it's fairly barebones but would have worked before I believe): @IBOutlet weak var PagesInterface: UIButton! override func viewDidLoad() { super.viewDidLoad() PagesInterface.layer.cornerRadius = 0 PagesInterface.layer.masksToBounds = true }

Looking at the UIDesignRequiresCompatibility documentation, watchOS is not listed among the supported platforms. When added to the project, it is also being ignored, resulting in Liquid Glass design. It is possible to opt-out from Liquid Glass design temporarily. Is that just an oversight for Apple Watch please?

I am trying to resize a Window Form after it loads and have done quite a bit of searching for code to do it. Here is one code snippet that works to size the form during the design phase. self.view.window?.contentMinSize = CGSize(width: 1100, height: 310) I have tried code like below to increase the window size after the Form loads if let myWindow = self.view.window ?? NSApplication.shared.mainWindow { // Increase window size and position after it loads let newRect = NSRect(x: 100, y: 100, width: 1400, height: 900) } It seems that this code not only changes the Form size after loading, but also changes the size of the Form in Main.swift, which is something I don't want. I read elsewhere that I had to disable constraints to resize the Form, so I tried code below. let tableView = NSTableView() tableView.translatesAutoresizingMaskIntoConstraints = false let newRect = NSRect(x: 100, y: 0, width: 1100, height: 600) myWindow?.setFrame(newRect, display: true) That code did not seem to do anything as well. Also, the Form displays in the lower left of the screen. Note that main reason I want to resize the Form after loading is to keep it smaller during design development. The same goes for the NSTableView, which I have not gotten to yet.

The system provided liquid glass background looks terrible with my companies navigation bar background color. The navigation background color is not up for discussion and cannot be changed. The clear liquid glass style looks great and I can apply that to buttons I add to the navigation bar, but that doesn't effect the system provided back button. I would prefer to maintain the default back button functionality. Please make it possible to set the liquid glass style that the system provides for navigation bar items.

I'm using .glassEffect(.clear) on a transparent circle over a gradient background. While it's closer to clear than the plain glass effect, it't not really clear, like clear glass. Here is the code. Is there a glass effect that really looks like clear glass? Circle() .fill(.clear) .frame(width: 180, height: 180) .glassEffect(.clear)

Why? Why stop there? (Why not ipod.and.imacg3? applenewton.and.vision.pro?) I get why the older ipod symbols exist but these new pairings are odd. If anyone ever sees these restricted symbols in the wild, or even just someone using a Vision Pro and an iPod (Touch) together in a way that's not contrived, please do let me know!

Why my app icon doesn't have effect liquid glass on ios26. My team dev still not upgrade to xcode26, so I have to export icon for them. And I don't see the effect like stroke of the detail.

Dear Apple Developer Relations Team, We are currently reviewing the documentation for the UIDesignRequiresCompatibility Info.plist key. In the documentation, there is a warning that states: "Temporarily use this key while reviewing and refining your app’s UI for the design in the latest SDKs." However, in the adoption guide for Liquid Glass: Adopting Liquid Glass, we did not see any explicit requirement to force adoption of the Liquid Glass design. We have the Gojek app, which currently uses the UIDesignRequiresCompatibility key. To ensure long-term stability, we would like clarification on the following points: Future Support of the Key: Is it safe to continue using the UIDesignRequiresCompatibility key? Can you confirm whether this key will remain supported or if there are plans for it to be deprecated/removed in future iOS versions? Liquid Glass Adoption: Our app’s design guidelines do not align with the Liquid Glass style. Can you confirm that adoption of Liquid Glass is not mandatory, and that apps can continue to use their existing custom design guidelines without any restrictions? Compatibility with iOS 26: Are there any required changes we need to make to our existing views to ensure that the UI will continue to render as it does today on iOS 26 and beyond? We want to make sure we provide the best user experience while remaining compliant with Apple’s guidelines. Your clarification would help us plan our design and development roadmap accordingly. Thank you for your support and guidance.

Hi, in the Human Interface Guidelines, Apple writes: Avoid using a segmented control in a toolbar. Toolbar items act on the current screen — they don’t let people switch contexts like segmented controls do. Along with this image: Source I'm confused by this example. The screenshot seems to be showing a segmented control in a toolbar. Is this saying that the Phone app's All/Missed toggle is different from a segmented control? Under iOS 26 it seems to take a different style compared to a regular segmented control. If so, which component is used to create this filter? Could you please clarify the guidelines? Thank you.

I think in the next updates of IOS 26 that Apple should add a setting to enable/disable Liquid Glass because we all know that everybody doesnt like the new update.

I just discover that feature (a folder lost in the middle of others desktop folder ). so with each updates: -/usr/local is emptied -somes apps in the Application folder, are deleted, even paid apps .. -i lost : Docker, python 3.13, latexlive2025, Apache NetBeans, java install, Affinity Publisher 2, all my 3D slicers ... github desktop, Epic Games Launcher, ........ 296go of apps Franckly : c'est la merde !!! I am using a MacBook Pro 16" 2019 any way to stop this behavior ? thank you !!!

Hello everyone, I'm very impressed with the Liquid Glass design introduced in iOS 26, especially how native app icons automatically adapt to the system's display mode (dark or light). This brings me to a question: Is it possible to make a website shortcut icon created via Safari's "Add to Home Screen" feature adapt to Dark Mode in the same way? For native apps, we can use tools like Icon Composer and asset catalogs (Assets.xcassets) to provide different icons for each mode. It would be a huge improvement for web clips if we could achieve the same with existing web technologies like apple-touch-icon or the Web App Manifest. If anyone has figured out a way to do this, I would greatly appreciate it if you could share your knowledge. Thanks in advance! 日本語の原文： iOS 26から導入されたLiquid Glassデザインについて。 ネイティブアプリのアイコンがシステムの表示モード（ダークモード/ライトモード）に合わせて自動で最適化されるようになりました。 そこで疑問に思ったのですが、Safariから「ホーム画面に追加」機能を使って作成するWebサイトのショートカットアイコンは、ネイティブアプリと同じようにダークモードに対応できないのでしょうか？ ネイティブアプリの場合は、Icon Composerなどのツールでアセットカタログ（Assets.xcassets）を使い、モードごとのアイコンを用意できますよね。 Web側でも、apple-touch-iconやWeb App Manifestといった既存の仕組みを使って、アイコンを動的に切り替えられるようになると、Webクリップの使い勝手がさらに向上すると思うのですが もし、すでに何らかの方法で対応されている方がいらっしゃれば、ぜひその知見を共有していただけると嬉しいです。