I have attached 2 images of our Mac Apps user interface. The app is built for macOS 15.6 or newer. On macOS 15 and earlier everything looks fine. But the same App running on macOS 26 the controls disappear. We were able to temporarily resolve the problem by adding UIDesignRequiresCompatibility to the info.plist. This type of nonsense happens all over the app without the compatibility switch. Shouldn't all these legacy controls be backward compatible on Glass? This part of the app where the controls are disappearing is built in Swift (not swift ui) and uses standard programatic layout and visual constraints. On macOS 26, there are no Xcode warnings or layout errors on the console relative to the layout so we are confused as to how we would resolve this without the use of UIDesignRequiresCompatibility. Is this some kind of bug in NSControl glass compatibility? We are not likely to move the entire app into SwiftUI anytime soon. How would we resolve this?

I'm using a custom modifier called AutoSheetDetentModifier to automatically size a sheet based on its content. On iOS 26, it works as expected: the content height is measured correctly and the sheet shrinks to match that height. However, on iOS 16, 17 and 18, the same code doesn’t work. The content height is still measured, but the sheet does not reduce its height. Instead, the sheet remains larger and the content appears vertically centered. (Note that content() includes ScrollView) public struct AutoSheetDetentModifier: ViewModifier { @State private var height: CGFloat = 380 // default value to avoid bouncing public func body(content: Content) -> some View { content .modifier(MeasureHeightViewModifier(height: $height)) .presentationDetents([.height(height)]) } } public struct MeasureHeightViewModifier: ViewModifier { @Binding var height: CGFloat public func body(content: Content) -> some View { content .fixedSize(horizontal: false, vertical: true) .background( GeometryReader { geo -> Color in DispatchQueue.main.async { height = geo.size.height } return Color.clear } ) } } extension View { public func applyAutoSheetDetent() -> some View { self .modifier(AutoSheetDetentModifier()) } } public var body: some View { VStack { header() content() // includes ScrollView footer() } .background(Color.customGray) .applyAutoSheetDetent() } func content() -> some View { ScrollView { VStack { ForEach(items) { item in itemRow(item) } } } .frame(maxHeight: UIScreen.main.bounds.height * 0.7) } Screenshot from iOS 26 (working as expected): Screenshot from iOS 18 (not working): How can I make .presentationDetents(.height) shrink the sheet correctly on iOS 16–18, the same way it does on iOS 26?

I'm currently using the extension below to determine whether an iPhone has a notch so I can adjust my UI accordingly. extension UIDevice { var hasNotch: Bool { if userInterfaceIdiom == .phone, let window = (UIApplication.shared.connectedScenes .compactMap { $0 as? UIWindowScene } .flatMap { $0.windows } .first { $0.isKeyWindow }) { return window.safeAreaInsets.bottom > 0 } return false } } (Adapted from https://stackoverflow.com/questions/73946911/how-to-detect-users-device-has-dynamic-island-in-uikit) This no longer works in iOS 26, and I have yet to find a similar method that works. Does anyone have any fixes?

I’m not seeing Liquid Glass on any standard components. A month ago around July 17th I ran our app and saw Liquid Glass on our tab view and various standard components. Those components have not been changed and yet I’m no longer seeing Liquid Glass in our app at all. Components that were previously liquid glass but now are not include TabView and back navigation buttons. I set the UIDesignRequiresCompatibility key explicitly to false but no luck. I was seeing this in Beta 7 and Beta 8 on a real device and on a sim.

Starting with iOS 26 beta, I'm encountering an intermittent crash in production builds related to Auto Layout and background threading. This crash did not occur on iOS 18 or earlier and has become reproducible only on devices running iOS 26 betas. We have already performed a thorough audit of our code: • Verified that all UIKit view hierarchy and layout mutations occur on the main thread. • Re-tested with strict logging—confirmed all remaining layout/constraint/view updates are performed on the main thread. • No third-party UI SDKs are used in the relevant flow. Despite that, the crash still occurs and always from a background thread, during internal UIKit layout commits. Fatal Exception: NSInternalInconsistencyException Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread. 0 MyApp 0x7adbc8 FIRCLSProcessRecordAllThreads + 172 1 MyApp 0x7adfd4 FIRCLSProcessRecordAllThreads + 1208 2 MyApp 0x7bc4b4 FIRCLSHandler + 56 3 MyApp 0x7bc25c __FIRCLSExceptionRecord_block_invoke + 100 4 libdispatch.dylib 0x1b7cc _dispatch_client_callout + 16 5 libdispatch.dylib 0x118a0 _dispatch_lane_barrier_sync_invoke_and_complete + 56 6 MyApp 0x7bb1f0 FIRCLSExceptionRecord + 224 7 MyApp 0x7bbd1c FIRCLSExceptionRecordNSException + 456 8 MyApp 0x7badf4 FIRCLSTerminateHandler() + 396 9 Intercom 0x86684 IntercomSDK_sentrycrashcm_cppexception_getAPI + 308 10 libc++abi.dylib 0x11bdc std::__terminate(void (*)()) + 16 11 libc++abi.dylib 0x15314 __cxa_get_exception_ptr + 86 12 libc++abi.dylib 0x152bc __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 90 13 libobjc.A.dylib 0x3190c objc_exception_throw + 448 14 CoreAutoLayout 0x13a4 -[NSISEngine optimize] + 314 15 CoreAutoLayout 0x1734 -[NSISEngine _optimizeWithoutRebuilding] + 72 16 CoreAutoLayout 0x1404 -[NSISEngine optimize] + 96 17 CoreAutoLayout 0xee8 -[NSISEngine performPendingChangeNotifications] + 104 18 UIKitCore 0x27ac8 -[UIView(Hierarchy) layoutSubviews] + 136 19 UIKitCore 0xfe760 -[UIWindow layoutSubviews] + 68 20 UIKitCore 0x234228 -[UITextEffectsWindow layoutSubviews] + 44 21 UIKitCore 0x27674 -[UIImageView animationImages] + 912 22 UIKitCore 0x28134 -[UIView(Internal) _viewControllerToNotifyOnLayoutSubviews] + 40 23 UIKitCore 0x18c2898 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2532 24 QuartzCore 0xabd98 CA::Layer::perform_update_(CA::Layer*, CALayer*, unsigned int, CA::Transaction*) + 116 25 QuartzCore 0x8e810 CA::Layer::update_if_needed(CA::Transaction*, unsigned int, unsigned int) + 600 26 QuartzCore 0xad45c CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 200 27 QuartzCore 0x6e30c CA::Context::commit_transaction(CA::Transaction*, double, double*) + 540 28 QuartzCore 0x9afc4 CA::Transaction::commit() + 644 29 QuartzCore 0x16974c CA::Transaction::release_thread(void*) + 180 30 libsystem_pthread.dylib 0x4c28 _pthread_tsd_cleanup + 620 31 libsystem_pthread.dylib 0x4998 _pthread_exit + 84 32 libsystem_pthread.dylib 0x5e3c pthread_atfork + 54 33 libsystem_pthread.dylib 0x1440 _pthread_wqthread + 428 34 libsystem_pthread.dylib 0x8c0 start_wqthread + 8 Any ideas?

My use case is the following: Every user of my app can create as an owner a set of items.  These items are private until the owner invites other users to share all of them as participant. The participants can modify the shared items and/or add other items. So, sharing is not done related to individual items, but to all items of an owner. I want to use CoreData & CloudKit to have local copies of private and shared items. To my understanding, CoreData & CloudKit puts all mirrored items in a special zone „com.apple.coredata.cloudkit.zone“. So, this zone should be shared, i.e. all items in it. In the video it is said that NSPersistentCloudKitContainer uses Record Zone Sharing optionally in contrast to hierarchically record sharing using a root record. But how is this done? Maybe I can declare zone „com.apple.coredata.cloudkit.zone“ as a shared zone?

Hello. I have an 12 year old app that still has some objective-c code in it. I have a place where i have a flip animation between 2 view controllers that looks like this: [UIView transitionFromView:origView toView:newViewController.view duration:0.5 options:UIViewAnimationOptionTransitionFlipFromRight completion:nil]; It has looked like this since 2012 at least. In our production release, it works prior to 26.1, but in 26.1 and 26.2, the flip is off-center and looks weird. it's like both edges flip the same way. It's a little bit hard to explain. If seen at least 2 other app store apps that i have installed behave this way too, from 26.1 and onwards. Anyone else seen this? Is there anything that can be done about it? Thankful for thoughts.

In a SwiftUI lab, I was asking about setting the focus state down a view hierarchy. The answer I got was to pass the focus state down the views as a binding. Conceptually, that made sense, so I moved on to other questions. But now that I am trying to implement it, I am having problems. In the parent view, I have something like this: @FocusState private var focusElement: UUID? Then I am setting a property like this in the child view: @Binding var focusedId: UUID? When I try to create the detail view, I'm trying this: DetailView(focusedId: $focusElement) But this doesn't work. The error I get is: Cannot convert value of type 'FocusState<UUID?>.Binding' to expected argument type 'Binding<UUID?>' What is the right way to pass down the focus state to a child view so that it can update back up to the parent view? I am trying to update from one child view, and have a TextField in a sibling view get focus.