We're preparing our SDK and host applications for iOS 27 and would like to understand the mandatory requirements for supporting the new Liquid Glass design. Beyond building with the iOS 27 SDK, are there any required implementation or migration steps (UIKit or SwiftUI) that developers must adopt to ensure full compatibility? Are there any behaviors or APIs that require explicit changes, or does the system automatically handle Liquid Glass for standard controls? We're specifically interested in the minimum required changes for compliance and compatibility, rather than optional design enhancements. Thanks in advance for any guidance.

I am seeing a weird crash from Xcode 27 Beta 3 when building a variadic type DynamicProperty that also needs SwiftUI.State. This does not crash from Xcode 26. Here is a repro: import SwiftUI struct Repeater<each Input>: DynamicProperty { @State private var storage = Storage() private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } } extension Repeater { final class Storage { } } @main struct CrashDemoApp: App { private var repeater = Repeater(1) var body: some Scene { WindowGroup { EmptyView() } } } Here is the crash: Thread 1 Queue : com.apple.main-thread (serial) #0 0x000000019a93aec0 in swift::TargetMetadata<swift::InProcess>::isCanonicalStaticallySpecializedGenericMetadata () #1 0x000000019a946b38 in performOnMetadataCache<swift::MetadataResponse, swift_checkMetadataState::CheckStateCallbacks> () #2 0x000000019a8c85f0 in swift_checkMetadataState () #3 0x00000001004a2c78 in type metadata completion function for Repeater () #4 0x000000019a94cfe4 in swift::GenericCacheEntry::tryInitialize () #5 0x000000019a94c870 in swift::MetadataCacheEntryBase<swift::GenericCacheEntry, void const*>::doInitialization () #6 0x000000019a94f820 in swift::LockingConcurrentMap<swift::GenericCacheEntry, swift::LockingConcurrentMapStorage<swift::GenericCacheEntry, (unsigned short)14>>::getOrInsert<swift::MetadataCacheKey, swift::MetadataRequest&, swift::TargetTypeContextDescriptor<swift::InProcess> const*&, void const* const*&> () #7 0x000000019a93c714 in _swift_getGenericMetadata () #8 0x00000001004a4190 in __swift_instantiateGenericMetadata () #9 0x00000001004a2a5c in type metadata accessor for Repeater () #10 0x00000001004a5094 in type metadata accessor for Repeater<Pack{Int}> () #11 0x00000001004a4fcc in type metadata completion function for CrashDemoApp () #12 0x000000019a9543bc in swift::MetadataCacheEntryBase<(anonymous namespace)::SingletonMetadataCacheEntry, int>::doInitialization () #13 0x000000019a8d2ae0 in swift_getSingletonMetadata () #14 0x00000001004a479c in type metadata accessor for CrashDemoApp () #15 0x00000001004a473c in static CrashDemoApp.$main() () #16 0x00000001004a4a34 in main () #17 0x0000000186e47e00 in start () Here is a repo to demo: https://github.com/vanvoorden/2026-07-17 Please let me know if you have any ideas about that. Thanks!

This is UIKit app, in Xcode 26.3 (but same issue in 16.4). I create (in IB) a segmentedControl, with 2 segments. I set the images that are stored in assets. They show properly in Xcode. But when running (26.1 simulator), they just show a black image. In Xcode                                                                           On simulator at runtime I've tried to set background to clear as well as tint, to no avail. What am I missing ?

I am having a root TabView with tabs. One of the tabs has a TabBar with page style as the root view and each Page has a ScrollView. Unfortunately the scroll view get's clipped by the parent TabView size. But I want to make the ScrollView content to go behind the root TabView's tab bar like it would work if I would have the ScrollView as direct child to the root TabBar I tried using ignoreSafeArea on the page style TabView and there are other weird bugs, it stops reacting to the Binding pageIndex I am having as a State. The custom page index view disappears Sample code: https://github.com/BProg/TabViewScrollViewBug.git

Can somebody tell me if I'm doing something wrong or SwiftUI's scrollTo(id:anchor:) just doesn't work if the ScrollView is scrolling? I have a trivial example that demonstrates the issue: import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct Item: Identifiable { let id = UUID() let timestamp: Date let text: String } struct ContentView: View { @State private var items: [Item] = (0...10_000).map{ .init(timestamp: Date(), text: "Row \($0)") } @State private var scrollPosition = ScrollPosition(idType: Item.ID.self) @State private var newMessage: String = "" var body: some View { ScrollView { LazyVStack { ForEach(items) { item in ItemView(item: item) } }.scrollTargetLayout() } .defaultScrollAnchor(.bottom, for: .initialOffset) .scrollPosition($scrollPosition, anchor: .bottom) .safeAreaBar(edge: .bottom) { HStack { TextField("Type here", text: $newMessage, axis: .vertical) .textFieldStyle(.roundedBorder) Button("Send", action: { let trimmed = newMessage.trimmingCharacters(in: .whitespacesAndNewlines) guard !trimmed.isEmpty else { return } newMessage = "" items.append(.init(timestamp: .now, text: trimmed)) withAnimation(.smooth) { scrollPosition.scrollTo(id: items.last!.id, anchor: .bottom) } }) }.padding() } } } struct ItemView: View { let item: Item var body: some View { VStack(alignment: .leading) { Text(item.text) Text(item.timestamp.formatted()) }.padding() .frame(maxWidth: .infinity, alignment: .leading) .background(Color(red: .random(in: 0...1), green: .random(in: 0...1), blue: .random(in: 0...1))) } } #Preview { ContentView() }

I'm just not getting it. My app adds a custom Import menu item to the File menu. I want to have it tell the sole ContentView to run the fileImporter. Here's how I have it set up. Changing the showFileImporter variable to supposed to make stuff happen, but it doesn't change. @main struct Blah: App { @State public var contentView = ContentView(); var body:some Scene { WindowGroup { // ContentView() // It started out defining the content like normal, but I saw somewhere that if I declared it as a var up top, then I'd have an actual object that I could tell to do things, like calling the importTerms() method below. self.contentView } .commands { CommandGroup(after:.newItem) { Button("Import…") { contentView.importTerms(); } } } } struct ContentView: View { @State private var showFileImporter = false; var body: some View { VStack { ...stuff... } } .fileImporter(isPresented:$showFileImporter, allowedContentTypes:[.text], allowsMultipleSelection:false) { result in } public func importTerms() { print("\(showFileImporter)"); // ->false showFileImporter = true; print("\(showFileImporter)"); // ->yep, still false } } But it doesn't work. It calls importTerms(), and a breakpoint inside that method does get hit. But it doesn't change the value of showFileImporter and the fileImporter never appears. What kind of weird world has Swift made where setting a variable to true doesn't set it to true and there's no error at build or runtime?

We are currently having an issue with our app hanging for some (not all) of our iOS 26.x users. The hang lasts long enough for the system to kill the app after a while. As of now we are unable to reproduce the issue on our own test devices, yet users dealing with the issue can produce it consistently. Looking at the stack traces we managed to retrieve, the hangup seems to occur in the layout rendering cycle of the navigation bar in the UINavigationController. The hangup doesn't happen at the exact same stack trace every time. But it always seems to be in the rendering cycle. Stack trace 1 Stack trace 2 Stack trace 3 Since the issue not reproducable in our own test environment it's hard to properly debug. The only adjustments to the navigationbar/navigationitem in our code is setting the title and a few bar buttons: self.navigationItem.title = NSLocalizedString("main_list_title", comment: "") let cancelItem = UIBarButtonItem(barButtonSystemItem: .stop, target: self, action: #selector(cancelListSelection)) let addPostItem = UIBarButtonItem(image: UIImage(named: "AddButton"), style: .plain, target: self, action: #selector(addItemTapped)) let extraMenuItem = UIBarButtonItem(image: UIImage(named: "ExtraButton"), style: .plain, target: self, action: #selector(extraItemTapped)) self.navigationItem.setLeftBarButton(cancelItem, animated: true) self.navigationItem.setRightBarButtonItems([addPostItem, extraMenuItem], animated: true) let previousButton = UIBarButtonItem(image: UIImage(named: "LeftArrow"), style: .plain, target: self, action: #selector(openPrevious)) let nextButton = UIBarButtonItem(image: UIImage(named: "RightButton"), style: .plain, target: self, action: #selector(openNext)) self.setToolbarItems([previousButton, nextButton], animated: true) And for one or two controllers the title is replaced by a UISegmentControl: let segControl = UISegmentedControl(items: ["1", "2", "3"]); segControl.selectedSegmentIndex = 0 segControl.addTarget(self, action: #selector(segmentValueChanged), for: .valueChanged) self.navigationItem.titleView = segControl Is anyone familiar with hangs at these particular stack traces and their cause?

Hi, We have found a nasty issue with SwiftUI List and Equatable reference types. In such scenarios List might resurface stale objects from some internal cache when inserting new equal instances, which can lead to outdated cells on screen. Detailed information can be found in our bug report (FB23923342). Since List is quite a widespread component we thought dropping a few lines here in addition to our report could be helpful, especially if you have been bitten by this issue in the past.

previously, setting accessoryImage would display the image on the far right. Now, it appears right next to the detailText, and the image is extremely small. I am already using the latest beta, but the problem still exists.

I have a question about NSSplitViewItemAccessoryViewController, introduced with the new design since macOS 26, and how it interacts with NSScrollView content insets. My app has a typical three-pane window whose content view controller is an NSSplitViewController subclass. The sidebar contains a tab view with a segmented control, similar to Xcode, for switching between different sidebar panes. Each pane contains an NSScrollView whose content can be scrolled. Before macOS 26, I placed the segmented control directly inside the sidebar view. To adopt the new scroll-edge effect and allow the sidebar content to extend visually into the window title bar, I moved the segmented control into an NSSplitViewItemAccessoryViewController. However, with this layout, the scroll view starts immediately below the segmented control, which feels visually cramped. I'd like to add a few points of top inset before the document view begins. Previously, I achieved this by setting: scrollView.additionalSafeAreaInsets.top However, this now causes the accessory view's scroll-edge effect to extend into the additional safe-area inset, producing an awkward blurred region underneath the segmented control. Ideally, I'd like the scroll view to begin directly below the segmented control while still having a small inset before the document content, with the scroll-edge effect ending exactly at the bottom of the accessory view. In addition to additionalSafeAreaInsets, I tried the following approaches, but neither produced the desired result: Set scrollView.automaticallyAdjustsContentInsets to false and specify scrollView.contentInsets.top. This disables the automatic safe-area adjustment, causing the entire scroll view to move upward underneath the accessory view. Set scrollView.contentView.automaticallyAdjustsContentInsets to false and specify scrollView.contentView..contentInsets.top. This produces the same result as above. Set the accessory view's preferredScrollEdgeEffectStyle to .soft. The segmented control becomes too transparent, making its unselected labels difficult to read. Xcode's sidebar appears to achieve the behavior I'm looking for. What is the recommended way to implement this layout on macOS 26 and 27? Xcode's sidebar (macOS 26) My app's sidebar (macOS 26, work in develop) with additionalSafeAreaInsets

I have a SwiftUI view with: @State var url: URL? @State var isShowingBrowser: Bool func displayURL(url: URL) { self.url = url self.isShowingBrowser = true } var body: some View { Group { // ...... } .sheet(isPresented: $isShowingBrowser) { // browser view } } The first time I call displayBrowser, an empty browser sheet appears, with no URL. The second time, it works. It doesn't matter if I reorder the assignments in displayURL. It's like the view refreshes once with a nil URL and isShowingBrowser true, then refreshes again with the URL value. If I move both variable to an @Observable view model class then it works fine - that update seems to happen atomically. For my own project, the view model is the right way to do this, but I was confused by this behavior. What am I missing about SwiftUI?

As insane as this may sound, I'm trying to write a spreadsheet app. I'm retired with 40+ years of mostly C device driver, networking type development and support. The model I'm using is Apple's Numbers and I'm currently experimenting with Table trying to mimic the look and feel of Numbers' "sheet". I believe I have two choices: I can have one Table with the first row and first column different / special and this would imply that the very first element is also special. Numbers has a circle as the top leftmost element. The top row and first column are the identifiers of the rows and columns initially starting out as A, B, C ... and 1, 2, 3 .... The advantage of this method is Table would take care that the size of the top row (the width of the columns) would match the width and position of the rest of the cells of the table. Likewise, the height of the cells in the first column would always match and align with the cells of the table. The downside with this approach is that things like sorting and selecting would need special attention. The alternative would be to have separate elements: an element in the top left corner followed by a spacer followed by a row of cells with the column identifiers A, B, C, .... Then a spacer across the entire structure. Then the there would be a column of cells for the names of the rows, a spacer, and then the actual Table of cells containing the spreadsheet itself. I am assuming that the top row with the identifiers of the columns would be a Table with one row and the first column with the identifiers of the rows would also be a Table with one column. The difficulty with this approach would be getting everything to line up correctly. I don't know if that would be hard or easy. Sometimes getting things to align is very hard, platform specific, etc. But I haven't used SwiftUI any so I don't know how hard this would be. Structurally I would prefer to take this approach. I just seems more logical and natural. Thank you for your time

When switching to a SwiftUI app (built with Xcode 26.5) from an app with an active keyboard, the target app's tab bar incorrectly floats above the keyboard safe area. This layout issue occurs even though the target app does not display a keyboard and contains only a tab bar and scroll views.

I'm using PDFKitView: NSViewRepresentable to present the pdf page in SwiftUI. Seems we already have some useful built-in functions in the context menu. However, the highlight manipulation functions are not functional - I can neither delete the highlight annotation nor change the color/type of the current pointed highlight annotation. The "Add Note" and other page display changing functions work well.

I am not sure if this is an iOS 27 beta bug or if I should be able to see the accept/deny/'maybe' UI when using the EKEventViewController in my app.

It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.

Hey All! Curious if others are seeing this where UIAlertController style action sheets (and to some extent Alert type) in iPad OS 27.0 B1 seem to be very buggy. By that i mean if you have an action sheet that has 20 items or some, half of them are not visible until you scroll or move the mouse over them (in simulator), and when tapping on them its a hit or miss if it triggers the delegate, sometimes it triggers on the first tap (click) or sometimes it takes 2 to 3 taps (clicks) to the delegate to trigger and the actioinsheet to dismiss. On initial look it seems iOS 27.0 B1 is working just fine, seems iPad Specific. While the list of the items not showing is only for action sheets, the 'sometimes' takes 2 to 3 taps (clicks) to select and item happens in both type ActionSheet and Alert. Sometimes it takes 2 to 3 taps to tigger an alert button etc. Both the above described issues happen on both device and simulator. Ive attached a video and a sample Proj to FB22998239. Hoping one of the UIKit Engineers can take a look, thanks for everything!

Here is a simple class that implements a timer: import AsyncAlgorithms final class Timer { private var task: Task<Void, Never>? init() { let id = ObjectIdentifier(self) print(id, "init") } deinit { let id = ObjectIdentifier(self) print(id, "deinit") self.task?.cancel() } func start() { if let _ = self.task { return } let id = ObjectIdentifier(self) self.task = Task.immediate { print(id, "start") defer { print(id, "stop") } for await _ in AsyncTimerSequence.repeating(every: .seconds(1.0)) { let now = Date.now print( id, now.formatted( date: .omitted, time: .standard ) ) } } } } And here is a simple SwiftUI app to start a timer: import SwiftUI @main struct StateDemoApp: App { @State private var timer = Timer() init() { self.timer.start() } var body: some Scene { WindowGroup { EmptyView() } } } Launching the app from Xcode 26.6 runs correctly: ObjectIdentifier(0x0000000c0c96c020) init ObjectIdentifier(0x0000000c0c96c020) start ObjectIdentifier(0x0000000c0c96c020) 10:40:19 PM ObjectIdentifier(0x0000000c0c96c020) 10:40:20 PM ObjectIdentifier(0x0000000c0c96c020) 10:40:21 PM ... ... ... Launching the app from Xcode 27 Beta 3 breaks: ObjectIdentifier(0x0000000a22c245a0) init ObjectIdentifier(0x0000000a22c245a0) start ObjectIdentifier(0x0000000a22c245a0) deinit ObjectIdentifier(0x0000000a22a2ca80) init ObjectIdentifier(0x0000000a22c245a0) stop This makes no sense to me. Why did my Task stop? Why was my Timer deallocated? Here is a repro: https://github.com/vanvoorden/2026-07-16 Please let me know if you have any ideas why this happened. Thanks!

Hello, Could someone from Apple clarify the support and behavior of the UIDesignRequiresCompatibility property? The UIDesignRequiresCompatibility documentation states that this property will be ignored for builds targeting iOS 27 or later. I have a couple of questions: Does "builds targeting iOS 27 or later" refer to an app that was built using Xcode 27 or later? iOS 27 is expected to be released in Fall 2026. Suppose that after iOS 27 is released, I create a new build using Xcode 26, with UIDesignRequiresCompatibility set to true, and install that build on an iOS 27 device. Will UIDesignRequiresCompatibility still be honored in this scenario, or will it be ignored and the app will use the Liquid Glass UI? Thanks!

NSTrackingSeparatorToolbarItem adds a white band over the top of the leading split view panes when in full screen mode on macOS 27. That white band appears to have the height of the toolbar. I filed FB23827858 with a sample project and a video demonstrating the issue. I also wrote about it at: https://virtualsanity.com/202607/nstrackingseparatortoolbaritem-causes-problems-when-putting-a-window-in-full-screen-on-golden-gate-macos-27/ I am hoping this is addressed before macOS 27 ships.