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.

Hello, I recently updated my app’s icon to use the new Liquid Glass style by adding an .icon file created with Icon Composer to my project. Previously, I had two image sets (light and dark versions of the app icon), and I’d implemented a settings option that let users either manually select their preferred icon, or let the app automatically switch between light/dark based on the system appearance. Is there a way to achieve the same behavior with the new Liquid Glass .icon file?Specifically, can I programmatically override the system-selected Liquid Glass dock icon and force a particular variant? Thank you.

Hi everyone, I’m running into a strange issue with UISearchController placement with iOS 26 SDK. In one of my view controllers, I was able to move the search bar to the top of the navigation bar by setting: navigationItem.searchController = searchController navigationItem.hidesSearchBarWhenScrolling = false navigationItem.preferredSearchBarPlacement = .stacked This works as expected — the search bar is placed at the top. However, in another view controller with almost identical configuration, the search bar always shows up at the bottom. If I delay the setup with DispatchQueue.main.async, it appears at the bottom; if I don’t, it doesn’t appear at all. Both VCs are wrapped in their own UINavigationController. So my questions are: Has anyone faced this issue where preferredSearchBarPlacement = .stacked is ignored? Are there hidden requirements or limitations for placing the search bar at the top? Why could the same setup behave differently in two controllers? Any help or ideas would be appreciated!

On iPad running iOS 26, UIKeyboardType.decimalPad sometimes appears as a floating keypad (compact panel) instead of the docked, full-width keyboard. Our app attaches a custom toolbar via inputAccessoryView, so the floating keypad hides the toolbar and breaks the flow. We’d like to opt out of the floating keypad or force the keyboard to remain docked when a toolbar is present. Environment Device: iPad (multiple models) OS: iPadOS 26.0 App type: UIKit Field: UITextField with keyboardType = .decimalPad We present a custom toolbar via inputAccessoryView Expected Docked (full-width) keyboard so the inputAccessoryView toolbar is visible and sized correctly. Actual A floating decimal keypad appears and covers content; our accessory toolbar isn’t visible/attached to it. Why this matters Our toolbar contains required domain actions (Done/Next, Previous). When the keypad floats, the user loses these controls. Questions Is there a supported way to opt out of the floating numeric keypad on iPad when using decimalPad? Is there an API/trait to prefer docked keyboard (e.g., when an inputAccessoryView is present)?

Environment: — Xcode Version: [Current version] — iOS Version: [Target iOS version] — Swift Version: 6.0.3 — Platform: iOS Summary: Direct assignment of new arrays to @State properties sometimes fails to trigger UI updates, even when the arrays contain different data. The assignment appears to succeed in code but the UI continues to display stale data. Presumably when lengths of both arrays are the same. Assigning first empty array and then the new array fixed the issue. Expected Behavior: When assigning a new array to a @State property (self.stateArray = newArray), SwiftUI should detect the change and update the UI to reflect the new data. Actual Behavior: The assignment self.stateArray = newArray executes without error, but the UI continues to display data from the previous array. Debugging shows that self._stateArray (the underlying property wrapper) retains the old data despite the assignment. Minimal Reproduction Case: struct ContentView: View { @State private var items: [String] = ["Old Item"] var body: some View { VStack { ForEach(items, id: \.self) { item in Text(item) } Button("Update Items") { // This assignment may not trigger UI update self.items = ["New Item", "Another Item"] // Workaround: Clear first, then assign // self.items = [] // self.items = ["New Item", "Another Item"] } } } } Workaround: Force the state update by clearing the array before assignment: self.items = [] // Clear first self.items = newArray // Then assign new data Additional Context: — This issue was discovered in a production app where item data loaded from cache wasn't updating the UI. — The same data loading pattern worked in one view (which is modal and doesn't reload data) but failed in another (which needs to be refreshed). — Console logs showed fresh data was loaded but UI displayed stale data. — Debugger showed self._items instead of self.items, which might suggest property wrapper issues. Impact: This causes significant user experience issues where the UI doesn't reflect the actual application state, leading to confusion and apparent data inconsistency. Request: Please investigate why direct @State array assignment sometimes fails and consider fixing the underlying cause, or at minimum document this behavior and recommended workarounds.

I am trying to create a Launch Screen for a new SwiftUI app built with Xcode 26. However, upon adding a UIImageView, the launch screen appears black and does not show anything. I have followed the typical steps to create a screen: New file from template -> Launch Screen Add image to xcassets, reference in UIImageView Set to initial view controller, add file name in general tab to Launch Screen File I have troubleshooted with the following sources: https://stackoverflow.com/questions/63978396/launch-screen-not-working-on-ios-14-with-xcode-12 https://developer.apple.com/forums/thread/665358 I have created a minimally reproducible example here: https://github.com/nickdebaise/launch-screen-bug

I can compile this #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate> @property (strong) NSWindow *window; @property (strong) NSSlider *slider; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)notification { // Window size NSRect frame = NSMakeRect(0, 0, 400, 300); NSUInteger style = NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable; self.window = [[NSWindow alloc] initWithContentRect:frame styleMask:style backing:NSBackingStoreBuffered defer:NO]; [self.window setTitle:@"Centered Slider Example"]; [self.window makeKeyAndOrderFront:nil]; // Slider size CGFloat sliderWidth = 200; CGFloat sliderHeight = 32; CGFloat windowWidth = self.window.frame.size.width; CGFloat windowHeight = self.window.frame.size.height; CGFloat sliderX = (windowWidth - sliderWidth) / 2; CGFloat sliderY = (windowHeight - sliderHeight) / 2; self.slider = [[NSSlider alloc] initWithFrame:NSMakeRect(sliderX, sliderY, sliderWidth, sliderHeight)]; [self.slider setMinValue:0]; [self.slider setMaxValue:100]; [self.slider setDoubleValue:50]; [self.window.contentView addSubview:self.slider]; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app run]; } return 0; } with (base) johnzhou@Johns-MacBook-Pro liquidglasstest % clang -framework Foundation -framework AppKit testobjc.m and get this neat liquid glass effect: https://github.com/user-attachments/assets/4199493b-6011-4ad0-9c9f-25db8585e547 However if I use pyobjc to make an equivalent import sys from Cocoa import ( NSApplication, NSApp, NSWindow, NSSlider, NSMakeRect, NSWindowStyleMaskTitled, NSWindowStyleMaskClosable, NSWindowStyleMaskResizable, NSBackingStoreBuffered, NSObject ) class AppDelegate(NSObject): def applicationDidFinishLaunching_(self, notification): # Create the main window window_size = NSMakeRect(0, 0, 400, 300) style = NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable self.window = NSWindow.alloc().initWithContentRect_styleMask_backing_defer_( window_size, style, NSBackingStoreBuffered, False ) self.window.setTitle_("Centered Slider Example") self.window.makeKeyAndOrderFront_(None) # Slider size and positioning slider_width = 200 slider_height = 32 window_width = self.window.frame().size.width window_height = self.window.frame().size.height slider_x = (window_width - slider_width) / 2 slider_y = (window_height - slider_height) / 2 self.slider = NSSlider.alloc().initWithFrame_(NSMakeRect(slider_x, slider_y, slider_width, slider_height)) self.slider.setMinValue_(0) self.slider.setMaxValue_(100) self.slider.setDoubleValue_(50) self.window.contentView().addSubview_(self.slider) if __name__ == "__main__": app = NSApplication.sharedApplication() delegate = AppDelegate.alloc().init() app.setDelegate_(delegate) app.run() I get a result shown at https://github.com/user-attachments/assets/7da022bc-122b-491d-9e08-030dcb9337c3 which does not have the new liquid glass effect. Why is this? Is this perhaps related to the requirement that you must compile on latest Xcode as indicated in the docs? Why, is the compiler doing some magic?

Seemingly innocuous contents passed to tabViewBottomAccessory can trigger inscrutable AttributeGraph cycles, which can then cause unexplained broken behavior of views that may be participating in these cycles. These cycles can be introduced by adding common elements to the tabViewBottomAccessory view hierarchy, like Slider, Button, Toggle, and even things simple if statements surrounding Text elements. These cycles can even also be triggered in a manner that causes the tabViewBottomAccessoryPlacement Environment value to be nil, which can then cause views that depend on this value to render incorrectly or not at all. The errors logged to the Xcode console are of the form: === AttributeGraph: cycle detected through attribute 29528 === === AttributeGraph: cycle detected through attribute 324264 === No further information about this attribute is available in any public Xcode tools. Environment XCode Version 26.0 (17A324) iOS 26.0 (23A343) Steps to reproduce Run the sample above in Simulator Observe no AttributeGraph cycles in Xcode console. Uncomment any of the commented out examples in SliderView.body Observe Xcode console for AttributeGraph cycle messages. Observe glitchy animation behavior Expected Behavior No AttributeGraph cycle diagnostics for ordinary state changes. tabViewBottomAccessoryPlacement always present (non-nil) while accessory is attached. Dependent views update consistently. Errors logged to the Console would help guide me towards a resolution Impact Undermines confidence in adopting tabViewBottomAccessory. Hard to debug: cycle traces are opaque and environment silently degrades (becomes nil) instead of asserting. Nearly shipped a UI where accessory layout fails sporadically. What would help Underlying fix to prevent cycles for ordinary accessory content mutations. Guarantee (or documented contract) that tabViewBottomAccessoryPlacement is never nil while accessory is active, or an assert if invariants break. Option to enable detailed environment propagation trace when a cycle is detected. Symbolic source identifiers in cycle backtraces. Documentation note on current limitations (if certain view types are not yet supported in accessory regions).

Summary: The minus.capsule and minus.capsule.fill SF Symbols do not render in my project. Other SF Symbols (e.g., plus.capsule and minus.circle) render correctly in the same context. Steps to Reproduce 1. Add an Image(systemName: "minus.capsule") or Image(systemName: "minus.capsule.fill") to a SwiftUI view. 2. Run the app on the latest macOS. Expected Result The minus capsule symbols should render consistently, similar to plus.capsule. Actual Result minus.capsule and minus.capsule.fill do not render at all. Additional Testing • Replaced minus.capsule with minus.circle: renders correctly. • Swapped the right-hand plus.capsule symbol in my slider with minus.capsule: the symbol fails to render in that position as well. That rules out clipping or layout issues.

As you can see in the image, scrollDismissesKeyboard(.interactively) has a bug while scrolling down. I want my textfield to follow keyboard just like in iMessage or WhatsApp or Instagram.

I wanted to set navigationTitle value to space symbol on my iOS app (Swift 6, iOS 26.0) (so that navigationBar opens in large mode initially before the actual value is being fetched). In my view I used this: .navigationTitle(" ") And on device I got unexpectedly two quote symbols: Not sure if there is space in between, and the symbols look like opening and closing quote (both quotes in code I think are the same symbols) - so probably it's not part of my code is visible in UI as one might think... . Is this a bug? Or undocumented feature?

In iOS 26, the Slider control no longer respects the step parameter. For example, import SwiftUI struct ContentView: View { @State private var sliderValue: CGFloat = 16 var body: some View { Slider( value: $sliderValue, in: 0...100, step: 5, onEditingChanged: { editing in print(sliderValue) } ) } } In iOS 18, this prints values like 5, 35, 60, 95, etc. In iOS 26.0 (release version), this prints floats that are not rounded to the nearest 5, and the slider does not snap to values ending in 5. Feedback report number: FB20320542

When I enable the Mergeable library in Xcode, SwiftUI preview will be not available, and the error is as follows. Cannot preview in this file Could not analyze the built target description for Demo to create the preview. arguments: -no_merge_framework: Failed parsing Mach-O file Assets Report

I'm having an issue where FetchRequest does not consistently reflect changes that are made in the CoreData model. Things seem to work fine if you create or delete any object before editing, but if you only edit an object, the changes will not be shown. Here is a minimal repro: https://github.com/literalpie/fetchrequest-bug/tree/main I have a workaround that involved adding a "noop" predicate that gets toggled whenever objectWillChange is emitted. This seems to force the FetchRequest to re-look at things. .onReceive(items.publisher.flatMap(\.objectWillChange), perform: { _ in items.nsPredicate = update ? NSPredicate(value: true) : NSPredicate(format: "1 == 1") update.toggle() })

Hi, I am looking for guidance on how to create a scrollable song list, such as the attachment. The song list was originally created in C#, using an RTF object and populated by about 43 lines of song criteria. What similar approach would I use in Swift and MacOS? By the way, I currently play music that resides on the Mac, no external streaming is required or desired. Thanks, Jim

I am trying to learn to write swift. I am very proficient MS VB, which I have been using for almost 20 years. The Book I am learning from is: SwiftUI for Masterminds. I have got to chapter 7 with no problem. The exercise I am having a problem with Listing 7-5. The error I am getting is: Thread 1: Fatal error: No Observable object of type ApplicationData found. A View.environmentObject(_:) for ApplicationData may be missing as an ancestor of this view. I have spent the last 2 days rechecking my code. The MacBook I am using was purchased in May this year, is 16 in, M4 Max chip, 128 G ram. Firstly I want to thank you for reading this post. Secondly is there a better book to learn SwiftUI. Regards Terry Harrison

Summary: When running our iPad app on macOS (“Designed for iPad”), invoking UIPrintInteractionController intermittently fails to show a working print sheet. The same code works reliably on iPad or iOS devices and also on macOS pre 26. This regression started after updating to macOS Tahoe Version 26.0 (25A354) Steps to Reproduce: Launch the attached minimal sample on macOS (Designed for iPad). Tap “Print plain text” Expected Results: The print panel should appear and discover AirPrint printers reliably, as on iPad/iOS or previous mac versions. Actual Results: On macOS, the panel fails to appear. Mac version: macOS Tahoe 26.0 (25A354) xCode version: 26.0 (17A324) Sample Reproduction Code: struct ContentView: View { var body: some View { Button("Print plain text") { printPlainText() } .buttonStyle(.borderedProminent) .padding() } func printPlainText() { let text = "This is just a sample print" guard UIPrintInteractionController.isPrintingAvailable else { NSLog("Printing not available on this device") return } let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "Plain Text" let formatter = UISimpleTextPrintFormatter(text: text) formatter.perPageContentInsets = UIEdgeInsets(top: 36, left: 36, bottom: 36, right: 36) let ctrl = UIPrintInteractionController.shared ctrl.printInfo = info ctrl.printFormatter = formatter DispatchQueue.main.async { ctrl.present(animated: true) { _, completed, error in if let error { NSLog("Print error: \(error.localizedDescription)") } else { NSLog(completed ? "Print completed" : "Print cancelled") } } } } } Also I have added the following values to info.plist: <key>NSLocalNetworkUsageDescription</key> <string>This app needs local network access to discover AirPrint printers.</string> <key>NSBonjourServices</key> <array> <string>_ipp._tcp.</string> <string>_ipps._tcp.</string> <string>_printer._tcp.</string> </array>

I'm using the simplified code below to create a window with 4 split view items, some of them collapsed. I would expect the title bar to be transparent since I'm using window.titlebarAppearsTransparent = true, but it seems that this particular view configuration causes the title bar to be visible until I collapse and expand the sidebar again. Removing any of the split view items, uncollapsing any of them, or changing the view of any of the view controllers, causes the title bar to be consistently visible or hidden, although I don't understand the logic, since I'm telling the window that it should be transparent. When launching the app in light mode, it's more difficult to notice the issue since the title bar background is equal to the content background and only the separator is visible (even though the code sets window.titlebarSeparatorStyle = .none): After collapsing and expanding the sidebar, the separator is gone: In dark mode the title bar is more visible: After collapsing and expanding the sidebar, the title bar background and separator are gone: I created FB20306872. @main class AppDelegate: NSObject, NSApplicationDelegate, NSToolbarDelegate { var splitViewController: NSSplitViewController! func applicationDidFinishLaunching(_ aNotification: Notification) { let splitViewItem1 = NSSplitViewItem(sidebarWithViewController: ViewController1()) let splitViewItem2 = NSSplitViewItem(viewController: ViewController2()) let splitViewItem3 = NSSplitViewItem(viewController: NSViewController()) splitViewItem3.isCollapsed = true let splitViewItem4 = NSSplitViewItem(viewController: NSViewController()) splitViewItem4.isCollapsed = true splitViewController = NSSplitViewController() splitViewController.splitViewItems = [splitViewItem1, splitViewItem2, splitViewItem3, splitViewItem4] let window = NSWindow(contentViewController: splitViewController) window.styleMask = [.titled, .closable, .miniaturizable, .resizable, .fullSizeContentView] window.titlebarAppearsTransparent = true let toolbar = NSToolbar(identifier: "") toolbar.delegate = self toolbar.displayMode = .iconOnly window.toolbar = toolbar window.titlebarSeparatorStyle = .none window.makeKeyAndOrderFront(nil) } func toolbarAllowedItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] { return [.space, .flexibleSpace, .sidebarTrackingSeparator, .init("item")] } func toolbarDefaultItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] { return [.init("item"), .sidebarTrackingSeparator] } func toolbar(_ toolbar: NSToolbar, itemForItemIdentifier itemIdentifier: NSToolbarItem.Identifier, willBeInsertedIntoToolbar flag: Bool) -> NSToolbarItem? { switch itemIdentifier.rawValue { case "item": let item = NSToolbarItem(itemIdentifier: itemIdentifier) item.image = NSImage(systemSymbolName: "sidebar.leading", accessibilityDescription: nil) item.action = #selector(toggleSidebar(_:)) item.target = self return item default: return nil } } @objc func toggleSidebar(_ sender: Any?) { splitViewController.splitViewItems[0].animator().isCollapsed = !splitViewController.splitViewItems[0].isCollapsed } } class ViewController1: NSViewController { override func loadView() { view = NSView(frame: CGRect(x: 0, y: 0, width: 300, height: 200)) } } class ViewController2: NSViewController { override func loadView() { let textView = NSTextView() let scrollView = NSScrollView(frame: CGRect(x: 0, y: 0, width: 400, height: 200)) scrollView.hasVerticalScroller = true scrollView.documentView = textView view = scrollView } }

Hi everyone, I’m testing my Catalyst SwiftUI project on iOS 26 / iPadOS 26 / macOS 26. I started with a NavigationSplitView (triple-column) inside a WindowGroup. On iPad it looks great: the toolbar items merge into the navigation bar, with the three traffic lights. But on Mac Catalyst, the app always reserves a blank safe area below the traffic lights, and places the toolbar on a separate line beneath the title bar. That leaves wasted vertical space I don’t want. What I expect (based on Apple’s WWDC session “Elevate the design of your iPad app”): The toolbar should merge into the title bar with the traffic lights, no separate row. Content should extend into the full height of the window. What I get on Mac Catalyst: Title bar + traffic lights at the top. Then a completely separate toolbar row below it. Safe area inset prevents my content from reaching the top of the window. What I’ve tried: .toolbarRole(.automatic), .editor, .browser → no effect. Hiding the title bar via titlebar?.titleVisibility = .hidden → removes the text but not the toolbar gap. Clearing titlebar?.toolbar → no difference. So far, I can’t find any way to get Catalyst to integrate toolbars into the window chrome the way native SwiftUI on macOS does. Is this a known limitation of Mac Catalyst, or is there a supported way to achieve the same “inline toolbar with window controls” layout? Switching to a Mac app vs. Catalyst fixes the issue, but I would have a lot more work to do to get the app ready for release, not ideal since it works near perfect on iPad. Thanks!

After iOS 26 was released to the public and our build began rollout, we started seeing a strange crash affect users immediately after the app goes to the background. According to the symbolication provided in Xcode, this appears to be the result of a UICollectionView potentially related to the keyboard and a UIAlertController. I’m not sure how an error somewhere else can cause a crash in our app which does not use UIKit in the background. The feedback associated with this post is: FB20305833. I will attach a sample of the crash report in my next comment.

We're building a UGC AR app and are leveraging App Clips to distribute AR experiences without app download. Since earlier this week, many of our users are reporting sharing experiences as App Clip doesn't work anymore. They are getting the message "AppClip unavailable" on a little card. We attached a QR code to try it yourself and a link to a different experience. We tried with multiple experiences and on multiple devices already. https://scenery.app/experience/1C925FDE-E49A-489B-BA14-58A4E532E645 Interestingly, we can't pinpoint the issue to an exact device or OS. We tested on many devices and on most, the AppClip is being displayed as unavailable, stating "App Clip unavailable", whereas it works on a few. It all worked fine last week (before September 12th). iPhone 13 Pro Max, iOS26: works iPhone SE, iOS 17: works iPhone 16 Pro, iOS 26: doesn't work iPhone 12 Pro Max, iOS 26: doesn't work iPhone 12 mini, iOS 18: does not work iPad 9th gen, iOS 26: doesn't work Please help. Our users are very dissatisfied as they expect this to work and it's a crucial feature. We already filed a radar via Feedback assistant: FB20303890