Navigation Title no longer showing for first Tab in iOS/iPadOS 26 (Directives) in my app Starship SE Corps when running is Xcode 26 simulator and on iPad device itself running iPadOS 26 beta. Launch app Notice Navigation Title “Directives” is missing from top tab in Sidebar and Floating Tab View (iPad) and TabView (iOS). Navigate to other tabs and Navigation Titles appear as expected. Worked fine (as expected) in iOS/iPadOS 18.5, but broken in iOS/iPadOS 26. Reference Feedback: FB17987650

Hi, I’m seeing a crash when running my app on iOS 18 simulators or devices using Xcode 26 beta 3. My app’s minimum deployment target is iOS 17, and the crash does not happen when running from Xcode 16.4. The crash occurs specifically at this line: return UIStoryboard(name: storyboard.rawValue, bundle: nil) .instantiateViewController(withIdentifier: view.rawValue) Crash Details: ** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ because no class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' *** First throw call stack: (0x191c3321c 0x18f0cdabc 0x191c91ea0 0x19d740774 0x19d740a18 0x19d740cac 0x194626680 0x194dbc784 0x19d740890 0x19d740cac 0x1949aadd8 0x19d740890 0x19d740a18 0x19d740cac 0x194802e24 0x1945f008c 0x194ed1808 0x107a8bfa0 0x107a8c05c 0x1945ec128 0x19d740890 0x19d740cac 0x1945eba60 0x19d740890 0x19d740a18 0x19d740cac 0x1945f07dc 0x1945eaea4 0x19492ee80 0x10763de00 0x1076e56fc 0x1076e5674 0x1076e5e04 0x19496108c 0x194f9b9a0 0x1949072c4 0x194f998cc 0x194f9af04 0x19445139c 0x19445ac28 0x194467508 0x1079afaec 0x1079aff5c 0x1944189a0 0x194417be4 0x1944114e4 0x194411404 0x194410ab4 0x19440c1e4 0x191b28a8c 0x191b288a4 0x191b28700 0x191b29080 0x191b2ac3c 0x1ded09454 0x19453d274 0x194508a28 0x1073564f4 0x1b89fff08) terminating due to uncaught exception of type NSException The crash occurs immediately at app launch, when attempting to load a storyboard-based UITabBarController. Works as expected on: Xcode 16.4 + iOS 18 (simulator/device) Xcode 26 beta 3 + iOS 26 (simulator/device) Running from Xcode 26 beta 3 onto iOS 18 simulators or devices and it immediate crash from the particular storyboard Setup: Xcode: 26 beta 3 macOS: 15.5 iOS Simulators: iOS 18.5 Minimum deployment target: iOS 17 UIKit-based app (not using SwiftUI) No custom toolbars or host views in use explicitly Is this a known compatibility issue when building with the iOS 26 SDK and running on iOS 18? Are there any workarounds or recommendations for running apps targeting iOS 17+ on iOS 18 simulators when using Xcode 26?

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?

Following on from this thread: https://developer.apple.com/forums/thread/805037 my list of items is now correctly maintaining state (no more disappearing rows), but I'm now hitting a really annoying issue: Every time something changes - even just changing the dark mode of the device - the entire list of items is refreshed, and the list jumps back to the top. A simple representation: // modelData.filteredItems is either all items or some items, depending on whether the user is searching List { ForEach(modelData.filteredItems) { item in ItemRow(item: item) } } When the user isn't searching, filteredItems has everything in it. When they turn on search, I filter and sort the data in place: // Called when the user turns on search, or when the searchString or searchType changes func sortAndFilterItemsInModelData() { modelData.filteredItems.removeAll() // Remove all items from the filtered array modelData.filteredItems.append(contentsOf: modelData.allItems) // Add all items back in let searchString: String = modelData.searchString.lowercased() switch(modelData.searchType) { case 1: // Remove all items from the filtered array that don't match the search string modelData.filteredItems.removeAll(where: { !$0.name.lowercased().contains(searchString) }) ... } // Sorting switch(modelData.sortKey) { case sortKeyDate: modelData.sortAscending ? modelData.filteredItems.sort { $0.date < $1.date } : modelData.filteredItems.sort { $0.date > $1.date } // Sorts in place ... } } The method doesn't return anything because all the actions are done in place on the data, and the view should display the contents of modelData.filteredItems. If you're searching and there are, say 10 items in the list and you're at the bottom of the list, then you change the search so there are now 11 items, it jumps back to the top rather than just adding the extra ItemRow to the bottom. Yes, the data is different, but it hasn't been replaced; it has been altered in place. The biggest issue here is that you can simply change the device to/from Dark Mode - which can happen automatically at a certain time of day - and you're thrown back to the top of the list. The array of data hasn't changed, but SwiftUI treats it as though it has. There's also a section in the List that can be expanded and contracted. It shows or hides items of a certain type. When I expand it, I expect the list to stay in the same place and just show the extra rows, but again, it jumps to the top. It's a really poor user experience. Am I doing something wrong (probably, yes), or is there some other way to retain the scroll position in a List? The internet suggests switching to a LazyVStack, but I lose left/right swipe buttons and the platform-specific styling. Thanks.

The following code only ever causes shouldDrawInsertionPoint to be printed (no drawInsertionPoint), but even if that method returns false, the blinking insertion point is still drawn. On the other hand, with TextKit 1 it works as expected. Is there a way to hide the default insertion point in TextKit 2? My app draws its own. I've filed FB13684251. class TextView: NSTextView { override var shouldDrawInsertionPoint: Bool { print("shouldDrawInsertionPoint") return false } override func drawInsertionPoint(in rect: NSRect, color: NSColor, turnedOn flag: Bool) { print("drawInsertionPoint", flag) } } ``

I have noticed that in iOS 14 the UIPickerView has by default a light grey background on the selected Row like shown here. https://developer.apple.com/design/human-interface-guidelines/ios/controls/pickers/ I noticed also that pickerView.showsSelectionIndicator is deprecated on iOS 14. Is there a way to change the background color to white and add separators to achieve a pre iOS 14 UIPickerView style? Thank you

I'm running into a persistent problem with the iOS 18.5 simulator in Xcode 26 beta 2. I have built a very simple test app with a storyboard that includes only a toolbar added to the ViewController scene in the storyboard. The test app runs fine in iOS 26 simulators.When I try to run it in the iOS 18.5 simulator for iPhone Pro or iPad (16), it fails while unarchiving the storyboard (as far as I can tell) with this error message in the Xcode console: *** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView because no class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' terminating due to uncaught exception of type NSException CoreSimulator 1043 - Device: iPad (A16) (3E70E25F-8434-4541-960D-1B58EB4037F3) - Runtime: iOS 18.5 (22F77) - DeviceType: iPad (A16) I'd love a simple workaround for this.

UITextView crash when setting attributed text that contains substring ffi and attributedText contains NSFontAttributeName, NSForegroundColorAttributeName Reproducible case: UITextView *textView = [[UITextView alloc] init]; textView.attributedText = [[NSAttributedString alloc] initWithString:@"ffi" attributes:@{ NSParagraphStyleAttributeName: [self createParagraphOfLineHeight:20], NSFontAttributeName: [UIFont systemFontOfSize:fontSize weight:UIFontWeightRegular], NSForegroundColorAttributeName: UIColor.black }];

I work on a universal app that targets both iPhone and iPad. Our iPad app currently requires full screen. When testing on the latest iPadOS 26 beta, we see the following warning printed to the console: Update the Info.plist: 1) `UIRequiresFullScreen` will soon be ignored. 2) Support for all orientations will soon be required. It will take a fair amount of effort to update our app to properly support presentation in a resizable window. We wanted to gauge how urgent this change is. Our testing has shown that iPadOS 26 supports our app in a non-resizable window. Can someone from Apple provide any guidance as to how soon “soon” is? Will UIRequiresFullScreen be ignored in iPadOS 26? Will support for all orientations be required in iPadOS 26?

In beta 2 using layer.cornerRadius on a UIEffectView with the UIGlassEffect allowed you to change the corner radius of the view. In beta 3, this no longer works. WWDC videos indicate the right way to do this is to set the cornerConfiguration on the UIEffectView, but that API doesn't seem to be available yet. At this time it doesn't seem like theres a way to have a glass view that isn't pill shaped.

I have added a UICollectionViewCell to my storyboard, and I added a UILabel to my UICollectionViewCell in storyboard. I have created a cell registration using UICollectionView.CellRegistration and have implemented the cellProvider closure for the datasource which dequeue a collection view cell of type TapLabelCollectionViewCell(I have subclassed the cell in my storyboard to this class). In my TapLabelCollectionViewCell, I am trying to set the tap gesture recogniser on the label, but the label appears nil, which I've connected using an @IBOutlet. Why is this and how can I fix it? My code : // UI View Controller: class TapGridViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. tapGridCollectionView.collectionViewLayout = createLayout() configureDataSource() applySnapshot() } func configureDataSource() { let cellRegistration = UICollectionView.CellRegistration<TapLabelCollectionViewCell, CellItem>(handler: { (cell: TapLabelCollectionViewCell, indexPath: IndexPath, item: CellItem) in cell.taplabel.text = String(item.labelCount) }) dataSource = UICollectionViewDiffableDataSource(collectionView: tapGridCollectionView, cellProvider: { (collectionView: UICollectionView, indexPath: IndexPath, item: CellItem) in let cell = collectionView.dequeueConfiguredReusableCell(using: cellRegistration, for: indexPath, item: item) cell.delegate = self cell.index = indexPath.row return cell }) } } // UI Collection View Cell: protocol TapLabelCollectionViewCellDelegate: AnyObject { func incrementNumberOfTaps(index: Int) } class TapLabelCollectionViewCell: UICollectionViewCell { @IBOutlet var taplabel: UILabel! var delegate: TapLabelCollectionViewCellDelegate? var index: Int! static let identifier = "tapLabelCellIdentifier" override init(frame: CGRect) { super.init(frame: frame) setUpTapGestureRecognizer() } required init?(coder: NSCoder) { super.init(coder: coder) } func setUpTapGestureRecognizer() { let tapGestureRecognizer = UITapGestureRecognizer(target: self, action: #selector(incrementNumberOfTaps)) print("tap Label,", taplabel) taplabel.addGestureRecognizer(tapGestureRecognizer) } @objc func incrementNumberOfTaps() { delegate?.incrementNumberOfTaps(index: index) } }

After two types of objects correctly inserted as nodes in an augmented reality setting, I replicated exactly the same procedure with a third kind of objects that unfortunately refuse to show up. I checked the flow and it is the same as the other objects as well the content of the LocationAnnotation, but there is surely something that escapes me. Could someone help with some ideas? This is the common code, apart of the class: func appendInAR(ghostElement: Ghost){ let ghostElementAnnotationLocation=GhostLocationAnnotationNode(ghost: ghostElement) ghostElementAnnotationLocation.scaleRelativeToDistance = true sceneLocationView.addLocationNodeWithConfirmedLocation(locationNode: ghostElementAnnotationLocation) shownGhostsAnnotations.append(ghostElementAnnotationLocation) }

We're seeing sporadic crashes on devices running iOS 18.1 - both beta and release builds (22B83). The stack trace is always identical, a snippet of it below. As you can tell from the trace, it's happening in places we embed SwiftUI into UIKit via UIHostingController. Anyone else seeing this? 4 libobjc.A.dylib 0xbe2c _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 30 5 libobjc.A.dylib 0xb040 weak_register_no_lock + 396 6 libobjc.A.dylib 0xac50 objc_storeWeak + 472 7 libswiftCore.dylib 0x43ac34 swift_unknownObjectWeakAssign + 24 8 SwiftUI 0xeb74c8 _UIHostingView.base.getter + 160 9 SwiftUI 0x92124 _UIHostingView.layoutSubviews() + 112 10 SwiftUI 0x47860 @objc _UIHostingView.layoutSubviews() + 36

Is the Cancel button intentionally removed from UISearchBar (right side)? Even when using searchController with navigationItem also. showsCancelButton = true doesn’t display the cancel button. Also: When tapping the clear ("x") button inside the search field, the search is getting canceled, and searchBarCancelButtonClicked(_:) is triggered (Generally it should only clear text, not cancel search). If the search text is empty and I tap outside the search bar, the search is canceled. Also when I have tableview in my controller(like recent searches) below search bar and if I try to tap when editing started, action is not triggered(verified in sample too). Just cancellation is happening. In a split view controller, if the search is on the right side and I try to open the side panel, the search also gets canceled. Are these behaviors intentional changes, beta issues, or are we missing something in implementation?

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' becomes 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?

Hi all, After upgrading to the iOS 26 beta, the scrolling in my SwiftUI chat view is completely broken. The exact same code works perfectly on iOS 18. Context: I have a chat view using ScrollViewReader and a vertically-reversed ScrollView (with .rotationEffect(.degrees(180))). Each message row (MessageBubble) uses multiple simultaneousGesture handlers: Horizontal drag for swipe-to-reply (and other actions: pin, delete) Long press for showing popover/actions Vertical scroll for normal chat scrolling This was working great on iOS 18. In iOS 26 beta, the vertical scroll is either completely disabled, jittery, or hijacked by the message row’s drag gestures, even though .simultaneousGesture is used (see code below). Minimal Repro Sample MessageListView.swift swift Copy Edit ScrollViewReader { proxy in ScrollView(.vertical, showsIndicators: false) { LazyVStack(spacing: 0) { // ... grouped messages ForEach(...) { ... MessageBubble(...) // see below } Color.clear.frame(height: 8).id("BOTTOM_ANCHOR") } .padding(.horizontal, 4) .rotationEffect(.degrees(180)) } .rotationEffect(.degrees(180)) } MessageBubble.swift struct MessageBubble: View { // ... var body: some View { // horizontal swipe-to-reply gesture let dragGesture = DragGesture(minimumDistance: 10) // ... ZStack { // ... HStack { ... } // ... .simultaneousGesture( DragGesture(minimumDistance: 0) // for long press // ... ) .simultaneousGesture(dragGesture) // for horizontal swipe } // ... } }

My app has the following UI layout: NSSplitViewController as the windows contentViewController NSPageController in the content (right) split item NSTabViewController as the root items of the NSPageController NSViewController with a collection view in the first tab of that NSTabViewController The collection view is using a NSCollectionViewCompositionalLayout in which the sections are set up to have a header using NSCollectionLayoutBoundarySupplementaryItem with pinToVisibleBounds=true and alignment=top With macOS 26, the pinned supplementary item automatically gets a blurred/semi-transparent background that seamlessly integrates with the toolbar. When the window's title bar has a NSTitlebarAccessoryViewController added, the said semi-transparent background gets a bottom hard edge and a hairline to provide more visual separation from the main content. During runtime, my NSPageController transitions from the NSTabViewController to another view controller. When transitioning back, the semi-transparent blur bleeds into the entire section. This happens no matter if there's a NSTitlebarAccessoryViewController added or not. It doesn't happen 100% of the cases, it seems to depend on section size, header visibility and/or scroll position. But it happens more often than not. Most of the time, a second or so after the back transition - shortly after pageControllerDidEndLiveTransition: of the NSPageControllerDelegate is called - the view updates and the supplementary views are back to normal. Sometimes, the issue also appears not when transitioning using NSPageController, but simply by scrolling through the collection view. Anyone has an idea what is happening here? Below are two screenshots of both the "ok" and "not ok" state I'm on macOS 26.0.1 and I'm using XCode 26.0.1

I have an existing Mac app which has evolved through over twenty years of development. It is currently written in a mixture of C++ and Objective-C, with a bit of C and Swift in a few places. For a few years now, I have been tinkering with replacing the UI with SwiftUI. The model has been completely rewritten in Swift and works fine. After a few tries, no version has been working acceptably, so I'm thinking that I need to rethink the architecture. The UI consists of a window with a master-detail view. The detail view is what users spend most of their time with. It contains a lot of subviews, around 100 typically. Keyboard events affect the display, so I've had a dedicated data structure to hold the state that is needed for displaying all the subviews. Using Instruments, I see that the view seems to recreate the subviews three times per keyboard event, so I'm clearly doing something wrong. A second factor is that there are a couple of dozen commands that are applicable to the detail view, driven either by menu items, keyboard shortcut, or toolbar button. Adding all of those to the view makes for a massive SwiftUI View, which seems unlikely to be good practice. The current implementation has the controller class broken up with categories, but still they are big classes. Most SwiftUI stuff on the web is iOS-oriented, and typically has a focus on fairly simple apps, so the whole topic of dealing with menu commands doesn't get a lot of coverage, so I've been doing all that through my own solutions, which are probably nothing like optimal. What I've been able to find is not particularly helpful for a full-fledged application like mine, so I'm looking for advice on how to structure the app. The existing one is largely MVC, but I've tried a similar approach and a shot at MVVM, but I'm not getting good results so far. So, pointers, places I can read more, or samples of real-world apps is what I'm after. Anyone?

In one of my apps, i am using .glassEffect(_:In) to add glass effect on various elements. The app always crushes when a UI element with glassEffect(_in:) modifier is being rendered. This only happens on device running iOS 26 public beta. I know this for certain because I connected the particular device to xcode and run the app on the device. When i comment out the glassEffect modifier, app doesn't crush. Is it possible to check particular realeases with #available? If not, how should something like this be handled. Also how do i handle such os level erros without the app crushing. Thanks.

When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. A scroll jump seems to happen directly after letting go of a scroll flick using a trackpad/mouse. Right at that moment the scroll turns into a momentum scroll, slowly decreasing the speed. But the first frame after the gesture the content jumps forward, more than what is expected. Observations: Counterintuitively, scrolling appears to be smoother when disabling NSScrollView.isCompatibleWithResponsiveScrolling. If disabled using a custom NSScrollView subclass there is no large jump anymore. Scrolling also appears to be smoother using a SwiftUI ScrollView. I assume that has the same behaviour as a disabled isCompatibleWithResponsiveScrolling Ironically a WKWebView scrolls much smoother. No sudden jump is observable. It also seems to scroll with faster acceleration, but the individual frames do appear smoother. Why is this better than a native NSScrollView? Elastic scrolling at the bounds of the scroll view also appears much smoother for WKWebViews. When pulling to refresh there is a jump for NSScrollView/SwiftUI, but not for WKWebView. When using an NSScrollView with isCompatibleWithResponsiveScrolling disabled, scrolling appears just as smooth as WKWebView on macOS 13 Ventura and below. On macOS 14 Sonoma scrolling behaviour is suddenly different. Please see a sample project with 4 different scroll views side by side: https://github.com/floorish/ScrollTest Screen recordings show the sudden jumps when scrolling and when elastic scrolling. Tested on Intel & Arm Macs, macOS 11 Big Sur through 15 Sequoia, built with Xcode 16. Should isCompatibleWithResponsiveScrolling be disabled on Sonoma+? Are there any drawbacks? There is also no overdraw anymore since Monterey, as described in https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes/#10_9Scrolling Even with responsive scrolling disabled, why is WKWebView scrolling much smoother than NSScrollView?