When I compiled my legacy project with Tahoe's macOS 26 SDK, NSRulerViews are showing a very different design: Under prior macOS versions the horizontal and verrical ruler's background were blurring the content view, which was extending under the rulers, showing through their transparency. With Tahoe the horizontal ruler is always reflecting the scrollview's background color, showing the blurred content view beneath. And the vertical ruler is always completely transparent (without any blurring), showing the content together with the ruler's markers and ticks. It's difficult to describe, I'll try to replicate this behavior with a minimal test project, and probably file a bug report / enhancement request. But before I take next steps, can anyone confirm this observation? Maybe it is an intentional design decision by Apple?

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

If the cell is expandable in List View, it will show slowly after deletion swipe. the image shows how it looks like when this issue happens and it should be easy to reproduce with this sample codes // Model for list items struct ListItem: Identifiable { let id = UUID() let title: String let createdDate: Date let description: String } struct ExpandableListView: View { // Sample constant data private let items: [ListItem] = [ ListItem( title: "First Item", createdDate: Date().addingTimeInterval(-86400 * 5), description: "This is a detailed description for the first item. It contains two lines of text to show when expanded." ), ListItem( title: "Second Item", createdDate: Date().addingTimeInterval(-86400 * 3), description: "This is a detailed description for the second item. It provides additional information about this entry." ), ListItem( title: "Third Item", createdDate: Date().addingTimeInterval(-86400 * 1), description: "This is a detailed description for the third item. Tap to expand and see more details here." ), ListItem( title: "Fourth Item", createdDate: Date(), description: "This is a detailed description for the fourth item. It shows comprehensive information when tapped." ) ] // Track which item is currently selected/expanded @State private var selectedItemId: UUID? = nil var body: some View { NavigationView { List { ForEach(items) { item in ExpandableCell( item: item, isExpanded: selectedItemId == item.id ) { // Handle tap - toggle selection withAnimation(.easeInOut(duration: 0.3)) { if selectedItemId == item.id { selectedItemId = nil } else { selectedItemId = item.id } } } } .onDelete { indexSet in for index in indexSet { print("delete \(items[index].title)") } } } .navigationTitle("Items") } } } struct ExpandableCell: View { let item: ListItem let isExpanded: Bool let onTap: () -> Void private var dateFormatter: DateFormatter { let formatter = DateFormatter() formatter.dateStyle = .medium formatter.timeStyle = .short return formatter } var body: some View { VStack(alignment: .leading, spacing: 8) { // Always visible: Title and Date HStack { VStack(alignment: .leading, spacing: 4) { Text(item.title) .font(.headline) .foregroundColor(.primary) Text(dateFormatter.string(from: item.createdDate)) .font(.caption) .foregroundColor(.secondary) } Spacer() // Chevron indicator Image(systemName: isExpanded ? "chevron.up" : "chevron.down") .foregroundColor(.secondary) .font(.caption) } // Expandable: Description (2 lines) if isExpanded { Text(item.description) .font(.body) .foregroundColor(.secondary) .lineLimit(2) .fixedSize(horizontal: false, vertical: true) .transition(.opacity.combined(with: .move(edge: .top))) .padding(.top, 4) } } .padding(.vertical, 8) .contentShape(Rectangle()) .onTapGesture { onTap() } } } #Preview { ExpandableListView() }

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?

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 have an iPad app with a classic sidebar. It's been working fine for years. Now with iPadOS 26 the sidebar sometime gets this fake transparency that makes it really hard to quickly grok. A part of Liquid Glass seems to be to sometimes (but not always) take whatever is in the secondary area (the main big content), blur it, mirror it and then use as the background for the sidebar. This is silly and does not work at all for an app like mine. It maybe looks decent if your background is a photo or similar, but not for an app that manages data. Not all views cause the sidebar to get this ugly unreadable background. In most of the cases the sidebar keeps its normal opaque background that it has always had. See this example for how it looks when it's really bad: This is how it should look. Notice that the content of the "main view" is pretty similar to the case where it gets the ugly background. The difference is the segmented thing at the top, ie. a different "root view". Is there some good way for me to force the sidebar to always have an opaque background? I guess I could make a ZStack and put a solid color as the background behind the sidebar, but those kinds of hacks are better to avoid. This can not be how some UI designer envisioned that apps should look? Maybe I'm missing some new modifier or setting somewhere that would led me opt out from this aspect of Liquid Glass? Apart from this it looks pretty nice. There are some bugs where the contents of the main area gets clipped when the sidebar is shown, hidden and then shown again, but that's for another time (and it's surely known already (if the bug tracking system allowed me to search I could verify)). So, any way to make my app look nice again?

Hi, I was wondering if it's possible (and advisable) to use the new glass effects available in iOS 26 in Swift Charts? For example, in a chart like the one in the image I've attached to this post, I was looking to try adding a .glassEffect modifier to the BarMarks to see how that would look and feel. However, it seems it's not available directly on the BarMark (ChartContent) type, and I'm having trouble adding it in other ways too, such as using in on the types I supply to modifiers like foregroundStyle or clipShape. Am I missing anything? Maybe it's just not advisable or necessary to use glass effects within Charts?

We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered odd behavior of [UIDocumentPickerViewController initForOpeningContentTypes: asCopy:YES] when reading large archive files from a USB drive. We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with bleeding edge iPadOS 18. Here's our Objective-C code which presents the picker: NSArray* contentTypeArray = @[UTTypeAppleArchive]; UIDocumentPickerViewController* docPickerVC = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypeArray asCopy:YES]; docPickerVC.delegate = self; docPickerVC.allowsMultipleSelection = NO; docPickerVC.shouldShowFileExtensions = YES; docPickerVC.modalPresentationStyle = UIModalPresentationPopover; docPickerVC.popoverPresentationController.sourceView = self.view; [self presentViewController:docPickerVC animated:YES completion:nil]; The UIDocumentPickerViewController remains visible until the selected external archive file has been copied from the USB drive to the app's local tmp sandbox. This may take several seconds due to the slow access speed of the USB drive. During this time the UIDocumentPickerViewController does NOT disable its tableview rows displaying files found on the USB drive. Even the most patient user will tap the desired filename a second (or third or fourth) time since the user's initial tap appears to have been ignored by UIDocumentPickerViewController, which lacks sufficient UI feedback showing it's busy copying the selected file. When the user taps the file a second time, UIDocumentPickerViewController apparently begins to copy the archive file once again. The end result is a truncated copy of the selected file based on the time between taps. For instance, a 788 MB source archive may be copied as a 56 MB file. Here, the UIDocumentPickerDelegate receives a 56 MB file instead of the original 788 MB of data. Not surprisingly, AppleArchive fails to decrypt the local copy of the archive because it's missing data. Instead of failing gracefully, AppleArchive crashes in AAArchiveStreamClose() (see forums post 765102 for details). Does anyone know if there's a workaround for this strange behavior of UIDocumentPickerViewController?