We got an app for iPad which has two targets one for the App itself (MainApp target ) and another one for the Driver ( Driver Target ) using DriverKit. The app works fine in Development, but I'm trying to distribute it with adhoc. I've requested the Distribution Entitlement to Apple, after getting it, the App Id for the Driver has the following Capabilities: DriverKit, DriverKit (development), DriverKit USB Transport (development), DriverKit USB Transport - VendorID, In-App Purchase Now in the profile section, I've created a adhoc profile for the Driver AppId (Identifier). Obviously I've also created an Adhoc profile for the Main AppId Finally in the Signing & Capabilities Section I set up the profiles for MainApp target, int the Debug one I set up the Development one and int the Release one I set up the adhoc one. I do the same in the Driver Target, but when I set up the Adhoc one in the Release, I've got a warning: Xcode 14 and later requires a DriverKit development profile enabled for iOS and macOS. Visit the developer website to create or download a DriverKit profile Also interestingly the Signing Certificate section says: None I also set up the Capabilities for the Driver Target: DriverKit USB Transport - VendorID DriverKit USB Transport ( Development ) Inside these capabilities I set up the vendor ID as dictionary The problem is, if I try to Archive the app I will get the previous Warning message as error: Xcode 14 and later requires a DriverKit development profile enabled for iOS and macOS. Visit the developer website to create or download a DriverKit profile. Any idea what I'm missing? Thanks

Since iPadOS 26.1 I notice a new annoying bug when changing the dark mode option of the system. The appearance of the UI changes, but no longer for view controllers which are presented as Popover. For these view controllers the method "traitCollectionDidChange()" is still called (though sometimes with a very large delay), but checking the traitCollection property of the view controller in there does no longer return the correct appearance (which is probably why the visual appearance of the popover doesn't change anymore). So if the dark mode was just switched on, traitCollectionDidChange() is called, but the "traitCollection.userInterfaceStyle" property still tells me that the system is in normal mode. More concrete, traitCollection.userInterfaceStyle seems to be set correctly only(!) when opening the popover, and while the popover is open, it is never updated anymore when the dark mode changes. This is also visible in the standard Apps of the iPad, like the Apple Maps App: just tap on the "map" icon at the top right to open the "Map mode" view. While the view is open, change the dark mode. All of the Maps App will change its appearance, with the exception of this "Map mode" view. Does anyone know an easy workaround? Or do I really need to manually change the colors for all popup view controllers whenever the dark mode changes? Using dynamic UIColors won't help, because these rely on the "userInterfaceStyle" property, and this is no longer correct. Bugreport: FB20928471

I have following code and made it invoke every time when a UIViewController presents another UIViewController through method swizzling. When I try to access the Password management app while input password, these code will be invoked and the presenting VC is instance of UITrackingElementWindowController. It will crash [presentingVC beginAppearanceTransition:NO animated:NO]; [presentingVC endAppearanceTransition];

I'm attempting to install a previously downloaded .xcappdata to my running application on the iPadOS Simulator (running iPadOS 26.1), but the app data won't transfer to the simulator. I've created the Xcode basic iPadOS app template, without any code modifications - adding some items to the list and downloading the .xcappdata from an attached iPad (running iPadOS 26.1). I can remove the app from the iPad and re-attach the .xcappdata to the physical iPad - no issues there. The issues I'm having is when trying to attach the app data on a simulator. Steps I've tried: Manually drag and dropping the .xcappdata file to the simulator. I get a popup saying "Simulator device failed to install application data container." Attaching the .xcappdata through Xcode in the "Edit Schemes"->Options->App Data App starts fresh without any errors or items from the .xcappdata file Installing the .xcappdata file through the command line through xcrun simctl install_app_data <SIM_DEVICE_ID> <MY_XCAPPDATA> This gives an error: Simulator device failed to install application data container. Could not get the existing data container location for the app. Container manager error code: 55 Underlying error (domain=com.apple.containermanager, code=55): Failed to install the requested app data package Could not get the existing data container location for the app. Container manager error code: 55 I can however reach the "data container location" through the xcrun simctl get_app_container command, leading me to think there are some issues with underlying permissions?

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

This is really odd. If you setup a UISearchController with a preferredSearchBarPlacement of .stacked and you setup the search bar with scope buttons, then when the view controller is initially displayed, the currently hidden scope buttons block touch events from reaching the main view just below the search bar. But once the search is activated and dismissed, then the freshly hidden scope buttons no longer cause an issue. This is easily demonstrated by putting a UITableViewController in a UINavigationController. Setup the table view to show a few simple rows. Then setup a search controller using the following code: func setupSearch() { // Setup a stacked search bar with scope buttons // Before the search is ever activated, the hidden scope buttons block any touches in the main view controller // in the area just below the search bar. // Once the search is activated and dismissed, the problem goes away. It seems that displaying and hiding the // scope buttons at least once fixes the issue that exists beforehand. // This issue only exists in iOS/iPadOS 26, not iOS/iPadOS 18 or earlier. let search = UISearchController(searchResultsController: UIViewController()) search.hidesNavigationBarDuringPresentation = true search.obscuresBackgroundDuringPresentation = true search.scopeBarActivation = .onSearchActivation // Ensure button appear immediately let searchBar = search.searchBar searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] self.navigationItem.searchController = search self.navigationItem.hidesSearchBarWhenScrolling = false // Issue appears even if this is true self.navigationItem.preferredSearchBarPlacement = .stacked } When first shown, before any attempt is made to activate the search, any attempt to tap on the upper 2/3 of the first row in the table view (which is just below the search bar) fails. If you tap on the lower 1/3 of the first row it works fine. If you then activate the search (now the scope buttons appear) and then dismiss the search (now the scope buttons are hidden again), then there is no issue tapping anywhere on the first row of the table. But if you restart the app, the problem starts over again. This problem happens on any iPhone or iPad, real or simulated, running iOS/iPadOS 26 RC. This is a regression from iOS 18 or earlier.

I’m using a 9th gen iPad, updated iPadOS 26 a few weeks ago, but I can’t use the 3D background, can’t find any way to use the 3D background. Is it a system issue or is it my iPad’s issue?

I’m trying to figure out how to extend PaperKit beyond a single fixed-size canvas. From what I understand, calling PaperMarkup(bounds:) creates one finite drawing region, and so far I have not figured out a reliable way to create multi-page or infinite canvases. Are any of these correct? Creating multiple PaperMarkup instances, each managed by its own PaperMarkupViewController, and arranging them in a ScrollView or similar paged container to represent multiple pages? Overlaying multiple PaperMarkup instances on top of PDFKit pages for paged annotation workflows? Or possibly another approach that works better with PaperKit’s design? I mean it has to be possible, right? Apple's native Preview app almost certainly uses it, and there are so many other notes apps that get this behavior working correctly, even if it requires using a legacy thing other than PaperKit. Curious if others have been able to find the right pattern for going beyond a single canvas.

On iOS 26.1, this throws on the 2020 iPad Pro (4th gen) but works fine on an M4 iPad Pro or iPhone 15 Pro: guard let device = AVCaptureDevice.default(.builtInLiDARDepthCamera, for: .video, position: .back) else { throw ConfigurationError.lidarDeviceUnavailable } It's just the standard code from Apple's own sample code so obviously used to work: https://developer.apple.com/documentation/AVFoundation/capturing-depth-using-the-lidar-camera Does it fail because Apple have silently dumped support for the older LiDAR sensor used prior to the M4 iPad Pro, or is there another reason? What about the 5th and 6th gen iPad Pro, does it still work on those?

I have an iPad app that supports multiple scenes. I discovered some issues with my app's user interface that I would like to tweak based on whether the user has setup multitasking (in iPadOS 26) as "Full Screen Apps" or "Windowed Apps". Is there any API or way to determine the current iPadOS 26 multitasking setting? I've looked at UIDevice.current.isMultitaskingSupported and UIApplication.shared.supportsMultipleScenes. Both always return true no matter the user's chosen multitasking choice. I also looked at UIWindowScene isFullScreen which was always false. I tried to look at UIWindowScene windowingBehaviors but that was always nil.

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?

My app is a SwiftUI document based app using DocumentGroupLaunchScene. In iOS(iPadOS) 18.4, when it launches, it has duplicate toolbar items, and when I close the current document and open other documents, it adds more duplicates. It also shows a wrong document name, which shows the first opened document name. This issue can be reproduced in the sample code (Building a document-based app with SwiftUI). I have submitted Feedback (FB17025216), but not sure if this is a known bug or if I'm missing anything.

Hello, I'm experiencing a navigation bar positioning issue with my UIKit iPad app on iPadOS 26 (23A340) using Xcode 26 (17A321). The navigation bar positions under the status bar initially, and after orientation changes to landscape, it positions incorrectly below its expected location. This occurs on both real device (iPad mini A17 Pro) and simulator. My app uses UIKit + Storyboard with a Root Navigation Controller. A stack overflow post has reproduce the bug event if it's not in the same configuration: https://stackoverflow.com/questions/79752945/xcode-26-beta-6-ipados-26-statusbar-overlaps-with-navigationbar-after-presen I have checked all safe areas and tried changing some constraints, but nothing works. Have you encountered this bug before, or do you need additional information to investigate this issue?

I'm trying to create a UI with two button bars (top and bottom) inside the detail view of a NavigationSplitView, instead of using the built-in .toolbar() modifier. I'm using .ignoresSafeArea(.container, edges: .vertical) so the detail view can reach into that area. However, in macOS and iOS 26 the top button is not clickable/tappable because it is behind an invisible View created by the non-existent toolbar. Interestingly enough, if I apply .buttonStyle(.borderless) to the top button it becomes clickable (in macOS). On the iPad the behavior is different depending on the iPad OS version. In iOS 26, the button is tappable only by the bottom half. In iOS 18 the button is always tappable. Here's the code for the screenshot: import SwiftUI struct ContentView2: View { @State private var sidebarSelection: String? @State private var contentSelection: String? @State private var showContentColumn = true @State private var showBars = true var body: some View { NavigationSplitView { // Sidebar List(selection: $sidebarSelection) { Text("Show Content Column").tag("three") Text("Hide Content Column").tag("two") } .navigationTitle("Sidebar") } detail: { VStack(spacing: 0) { if showBars { HStack { Button("Click Me") { withAnimation { showBars.toggle() } } .buttonStyle(.borderedProminent) } .frame(maxWidth: .infinity, minHeight: 50, idealHeight: 50, maxHeight: 50) .background(.gray) .transition(.move(edge: .top)) } ZStack { Text("Detail View") } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .init(horizontal: .center, vertical: .center)) .border(.red) .onTapGesture(count: 2) { withAnimation { showBars.toggle() } } if showBars { HStack { Button("Click Me") { withAnimation { showBars.toggle() } } } .frame(maxWidth: .infinity, minHeight: 50, idealHeight: 50, maxHeight: 50) .background(.gray) .transition(.move(edge: .bottom)) } } .ignoresSafeArea(.container, edges: .vertical) .toolbarVisibility(.hidden) } .toolbarVisibility(.visible) } } I'm confused by this very inconsistent behavior and I haven't been able to find a way to get this UI to work across both platforms. Does anybody know how to remove the transparent toolbar that is preventing clicks/taps in this top section of the view? I'm hoping there's an idiomatic, native SwiftUI way to do it.

Since the beta releases of iPadOS 26 we have been having some crashes about Invalid parameter not satisfying: parentEnvironment != nil We got to contact a couple of users and we found out that the crash appears when entering a screen in a UINavigationController with the iPad device connected to a Magic Keyboard. If the device is not connected to the keyboard then nothing happens and everything works ok. From our end we haven't managed to reproduce the crash so I am pasting part of the stacktrace if it can be of any help. 3 UIKitCore 0x19dfd2e14 -[_UIFocusContainerGuideFallbackItemsContainer initWithParentEnvironment:childItems:] + 224 (_UIFocusContainerGuideFallbackItemsContainer.m:23) 4 UIKitCore 0x19dae3108 -[_UIFocusContainerGuideImpl _searchForFocusRegionsInContext:] + 368 (_UIFocusGuideImpl.m:246) 5 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 6 UIKitCore 0x19db28900 -[_UIFocusMapSnapshot addRegionsInContainers:] + 160 (_UIFocusMapSnapshot.m:545) 7 UIKitCore 0x19d1313dc _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 632 (_UIFocusRegion.m:143) 8 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 9 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 10 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 11 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 12 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 13 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 14 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 15 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 16 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 17 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 18 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 19 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 20 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 21 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 22 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 23 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 24 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 25 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 26 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 27 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 28 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 29 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 30 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 31 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 32 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 33 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 34 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 35 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 36 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 37 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 38 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 39 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 40 UIKitCore 0x19d132e08 -[_UIFocusMapSnapshot _capture] + 424 (_UIFocusMapSnapshot.m:403) 41 UIKitCore 0x19db2675c -[_UIFocusMapSnapshot _initWithSnapshotter:mapArea:searchArea:] + 476 (_UIFocusMapSnapshot.m:171) 42 UIKitCore 0x19d130dcc -[_UIFocusMapSnapshotter captureSnapshot] + 192 (_UIFocusMapSnapshotter.m:137) 43 UIKitCore 0x19db2045c -[_UIFocusMap _inferredDefaultFocusItemInEnvironment:] + 136 (_UIFocusMap.m:168) 44 UIKitCore 0x19daffd2c -[_UIFocusEnvironmentPreferenceEnumerationContext _inferPreferencesForEnvironment:] + 140 (_UIFocusEnvironmentPreferenceEnumerator.m:313) 45 UIKitCore 0x19d127ab4 -[_UIFocusEnvironmentPreferenceEnumerationContext _resolvePreferredFocusEnvironments] + 104 (_UIFocusEnvironmentPreferenceEnumerator.m:250) 46 UIKitCore 0x19d127394 -[_UIFocusEnvironmentPreferenceEnumerationContext preferredEnvironments] + 36 (_UIFocusEnvironmentPreferenceEnumerator.m:184) 47 UIKitCore 0x19d126e94 _enumeratePreferredFocusEnvironments + 400 (_UIFocusEnvironmentPreferenceEnumerator.m:503)

When using the SoftwareUpdateEnforcementSpecific to target an update to iPad OS 18.7.1, will the update be triggered to be downloaded immediately after the iPad has an active Internet connectivity? Or, if the SoftwareUpdateSettingsAutomaticActionsObject download string is set to AlwaysOff, will this mean that the update enforced will not start downloading automatically, but only when the user decides? I am trying to understand how these two can be combined together or if they work independently, as while trying to enforce a specific version, we need to eliminate the possibility to download an iPad OS version using cellular data, as our devices have an eSIM installed and the cost of using that for the iOS updates will be quite high. Maybe there is a setting to only allow the iOS updates to be downloaded via Wi-Fi. Thanks!

Under iPadsOS 26.0 and 26.1, if a view controller is presented with a presentation style of fullScreen or pageSheet, and the view controller is setup with a UISearchController that has obscuresBackgroundDuringPresentation set to true, then when cancelling the search the view controller is being dismissed when it should not be. To replicate, create a new iOS project based on Swift/Storyboard using Xcode 26.0 or Xcode 26.1. Update ViewController.swift with the following code: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground title = "Root" navigationItem.rightBarButtonItems = [ UIBarButtonItem(title: "Full", primaryAction: .init(handler: { _ in self.showModal(with: .fullScreen) })), UIBarButtonItem(title: "Page", primaryAction: .init(handler: { _ in self.showModal(with: .pageSheet) })), UIBarButtonItem(title: "Form", primaryAction: .init(handler: { _ in self.showModal(with: .formSheet) })), ] } private func showModal(with style: UIModalPresentationStyle) { let vc = ModalViewController() let nc = UINavigationController(rootViewController: vc) // This triggers the double dismiss bug when set to either pageSheet or fullScreen. // If set to formSheet then it works fine. // Bug is only on iPad with iPadOS 26.0 or 26.1 beta 2. // Works fine on iPhone (any iOS) and iPadOS 18 as well as macOS 26.0 (not tested with other versions of macOS). nc.modalPresentationStyle = style self.present(nc, animated: true) } } Then add a new file named ModalViewController.swift with the following code: import UIKit class ModalViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() title = "Modal" view.backgroundColor = .systemBackground setupSearch() } private func setupSearch() { let sc = UISearchController(searchResultsController: UIViewController()) sc.delegate = self // Just for debugging - being set or not does not affect the bug sc.obscuresBackgroundDuringPresentation = true // Critical to reproducing the bug navigationItem.searchController = sc navigationItem.preferredSearchBarPlacement = .stacked } // When the search is cancelled by tapping on the grayed out area below the search bar, // this is called twice when it should only be called once. This happens only if the // view controller is presented with a fullScreen or pageSheet presentation style. // The end result is that the first call properly dismisses the search controller. // The second call results in this view controller being dismissed when it should not be. override func dismiss(animated flag: Bool, completion: (() -> Void)? = nil) { print("dismiss ViewController") // Set breakpoint on the following line super.dismiss(animated: flag, completion: completion) } } extension ModalViewController: UISearchControllerDelegate { func willDismissSearchController(_ searchController: UISearchController) { print("willDissmissSearchController") } func didDismissSearchController(_ searchController: UISearchController) { print("didDismissSearchController") } } Build and run the app on a simulated or real iPad running iPadOS 26.0 or 26.1 (beta 2). A root window appears with 3 buttons in the navbar. Each button displays the same view controller but with a different modalPresentationStyle. Tap the Form button. This displays a modal view controller with formSheet style. Tap on the search field. Then tap on the grayed out area of the view controller to cancel the search. This all works just fine. Dismiss the modal (drag it down). Now tap either the Page or Full button. These display the same modal view controller with pageSheet or fullScreen style respectively. Tap on the search field. Then tap on the grayed out area of the view controller to cancel the search. This time, not only is the search cancelled, but the view controller is also dismissed. This is because the view controller’s dismiss(animated:completion:) method is being called twice. See ViewController.swift for the code that presents the modal. See ModalViewController.swift for the code that sets up the search controller. Both contain lots of comments. Besides the use of fullScreen or pageSheet presentation style to reproduce the bug, the search controller must also have its obscuresBackgroundDuringPresentation property set to true. It’s the tap on that obscured background to cancel the search that results in the double call to dismiss. With the breakpoint set in the overloaded dismiss(animated:completion:) function, you can see the two stack traces that lead to the call to dismiss. When presented as a formSheet, the 2nd call to dismiss is not being made. This issue does not affect iPadOS 18 nor any version of iOS on iPhones. Nor does it affect the app using Mac Catalyst on macOS 26.0 (untested with macOS 15 or 26.1). In short, it is expected that cancelling the search in a presented view controller should not also result in the view controller being dismissed. Tested with Xcode 26.1 beta 2 and Xcode 26.0. Tested with iPadOS 26.1 beta 2 (real and simulated) and iPadOS 26.0 (simulated). A version of this post was submitted as FB20569327

My app worked correctly using iOS 18. I tried to down grade back to iOS 18, but there are no signed ipsw file available. How can I down grade my iphone back to iOS 18?

Hello, my iOS apps are exiting right after launch on a few of our iOS devices. I tried a couple of my apps that are deployed to our fleet and they do the same thing. If I run the app(s) in the Simulator it works fine and if I run the app(s) on the offending devices it works fine as well. Once I stop the run in Xcode the app on the device will not launch. I'm thinking something is missing like a certificate etc. Just not sure. Any ideas on how to troubleshoot this? I would really like to get this fixed.

We've identified a regression in iOS 26.0 and 26.1 Beta 4 where AVSpeechSynthesisVoice(language:) no longer respects user-selected voices from Accessibility settings. Issue: When users select a specific voice in Settings → Accessibility → Spoken Content → Voices, calling AVSpeechSynthesisVoice(language:) returns the system default voice instead of the user's selection. This worked correctly in iOS 18.6.2. Particularly affects: Third-party speech synthesis voices (CereProc, Grammatek, etc.) Apps relying on automatic voice selection based on user preferences Example: // User selected CereProc Heather for en-GB in Accessibility settings let voice = AVSpeechSynthesisVoice(language: "en-GB") print(voice?.name) // iOS 18.6.2: "HEATHER", iOS 26: "Daniel" (system default) Interesting observation: The new Accessibility Reader feature in iOS 26 correctly uses the user-selected voice, but Tap to Speak and the API both ignore the setting. Tested methods: AVSpeechSynthesisVoice(language:) AVSpeechUtterance auto-selection Reflection for new APIs All return the system default voice, not the user's preference. Filed: FB[20271264] Has anyone else encountered this? Any known workarounds to programmatically access the user's preferred voice selection?