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?
Posts under iPadOS tag
164 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
My apps are using UIRequiresFullScreen = YES in the info.plist. Now that this is deprecated for iPadOS 26+, I'm updating my apps and using the UIWindowScene's sizeRestriction property to ensure a certain minimum size of the window.
I've enabled all orientations support for iPads in the plist as well as the supportedInterfaceOrientations property of the ViewController.
On iPadOS 26, the following line works -
windowScene.sizeRestrictrions?.minimumSize = CGSize(480,720)
The window does not resize below the above threshold and everything works as expected.
However on the iPad simulators for 18.x (with Stage Manager enabled), the above sizeRestrictions property is never set. It shows up as nil even after the views have been laid out.
The simulator allows me to drag the window handle and shrink the window to well below the specified threshold, all the way down to a width of 375.
Is there anyway I can set the sizeRestrictions for iPadOS 18.x and lower?
are there an api to know this feature is on/off
In iOS Background Execution limits, I see this:
When the user ‘force quits’ an app by swiping up in the multitasking UI, iOS interprets that to mean that the user doesn’t want the app running at all. iOS also sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually.
However, I see that when I close an app on iPadOS 26 with the red X, the app doesn't appear in the multitasking UI. So are they treated as force closes and prevented from running background tasks?
Please excuse my lack of understanding of what are probably fundamental concepts in iOS/iPadOS development but I have searched far and wide for documentation and haven't had much luck so far. I am not sure that what I want to do is even possible with an iPad iPadOS app.
Goals: Develop a Swift iPadOS app that can digitally sign a
file using a PIV SmartCard/Token (Personal Identity Verification Card):
Insert a PIV SmartCard/Token (such as a Yubikey 5Ci) into the lightning port of an iPadOS device iPad (NOT MacOS)
Interface with the SmartCard/Token to access the user's PIV certificate/signature and "use it" to sign a file
Question 1: How to get the PIV Certificate from
SmartCard/Token/Yubikey into iPadOS keychain?
* Do we need to get the PIV certificate into the
iOS keychain? Is there another way to interact with a SmartCard directly?
* This should prompt the user for their PIN?
Question 2: How to get our Swift app to hook into the event
that the SmartCard/Token is inserted into the device and then interface with
the user's certificate?
* When is the user prompted to enter their PIN for
SmartCard/Token/Yubikey?
* Do we need to use CyrptoTokenKit to interface with
a smartcard inserted into the lightning port of an iOS device?
When trying to use a UISearchController setup with a UISearchBar that has scope buttons, the search controller's scopeBarActivation property is set to .onSearchActivation, the navigation item's preferredSearchBarPlacement property is set to .integrated. or .integratedButton, and the search bar/button appears in the navigation bar, then the scope buttons never appear. But space is made for where they should appear.
Some relevant code in a UIViewController shown as the root view controller of a UINavigationController:
private func setupSearch() {
let sc = UISearchController(searchResultsController: UIViewController())
sc.delegate = self
sc.obscuresBackgroundDuringPresentation = true
// Setup search bar with scope buttons
let bar = sc.searchBar
bar.scopeButtonTitles = [ "One", "Two", "Three", "Four" ]
bar.selectedScopeButtonIndex = 0
bar.delegate = self
// Apply the search controller to the nav bar
navigationItem.searchController = sc
// BUG - Under iOS/iPadOS 26 RC, using .onSearchActivation results in the scope buttons never appearing at all
// when using integrated placement in the nav bar.
// Ensure the scope buttons appear immediately upon activating the search controller
sc.scopeBarActivation = .onSearchActivation
// This works but doesn't show the scope buttons until the user starts typing - that's too late for my needs
//sc.scopeBarActivation = .automatic
if #available(iOS 26.0, *) {
// Under iOS 26 put the search icon in the nav bar - same issue for .integrated and .integratedButton
navigationItem.preferredSearchBarPlacement = .integrated // .integratedButton
// My toolbar is full so I need the search in the navigation bar
navigationItem.searchBarPlacementAllowsToolbarIntegration = false // Ensure it's in the nav bar
} else {
// Under iOS 18 put the search bar in the nav bar below the title
navigationItem.preferredSearchBarPlacement = .stacked
}
}
I need the search bar in the navigation bar since the toolbar is full. And I need the scope buttons to appear immediately upon search activation.
This problem happens on any real or simulated iPhone or iPad running iOS/iPadOS 26 RC.
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.
Hi, it seems like using Table on iPadOS 26 results in the table header not applying a background. When comparing the same code on iPadOS 18, the table header applies a blur behind the header to ensure legibility when the user scrolls the content.
Is there a way to ensure Table applies a background effect to the header so that content remains legible during scrolling?
Here is a minimal example:
struct TablePreviewContent: Identifiable {
var id: Int { text.hashValue }
var text: String
}
#Preview {
let content = [TablePreviewContent(text: "Hello"), TablePreviewContent(text: "World")]
Table(content) {
TableColumn("Title", value: \.text)
}
}
I've attached screenshots of the behavior on iPadOS 26 compared to iPadOS 18 to illustrate the issue.
Hello,
I’m seeing a layout issue where the system window controls overlap the navigation bar’s right-side buttons when the app window is resized on iPadOS 26.
Environment
Xcode: 16.4
Simulator: iPadOS 26.0, device profile iPad Pro 13-inch
Physical device: iPad updated to iPadOS 26 (same behavior)
UI stack: UIKit + Storyboards (no SwiftUI)
App structure: Root UINavigationController
Summary
Since iPadOS 26 introduced freely resizable app windows, the system’s window management controls (close/minimize/resize at the top-right) begin to overlap the navigation bar buttons as the window size becomes smaller. At maximum window size there’s no issue. Additionally, the navigation bar buttons themselves appear to scale down visually when the window gets smaller.
Steps to Reproduce
Build with Xcode 16.4 and run on iPadOS 26.0 (simulator or device).
Open a screen embedded in a UINavigationController with right-side bar button items.
Resize the app window to a smaller size.
Observe the top-right system window controls overlapping the navigation bar buttons.
Expected Result
System window controls should not overlap app content; the navigation bar should remain usable and properly spaced at all supported window sizes.
Actual Result
When the window is small, the system window controls overlap the right-side navigation bar buttons. The bar button items also appear to shrink as the window size decreases.
Notes
Reproducible on both simulator and a real device updated to iPadOS 26.
Project uses UIKit + Storyboards only (no SwiftUI).
Safe areas and basic constraints look fine, so the root cause is unclear.
Questions
Is this a known issue with iPadOS 26 resizable windows?
Any recommended workaround (e.g., API to reserve space near the window controls, UINavigationBar configuration, or trait/size-class handling)?
I can provide a minimal sample project and screenshots if helpful.
Thank you!
We’ve encountered an issue while developing with SwiftUI: when using the inspector on iPadOS, if the inspector is placed inside a NavigationStack, and both the view attached to the inspector and the content inside the inspector itself are scrollable, scrolling them to the top may cause abnormal jitter.
We suspect this issue might be related to NavigationTitle. However, if we place the inspector outside the NavigationStack, tapping any NavigationLink while the inspector is expanded will cause problems with the View.matchedTransitionSource(id:in:) animation.
A reproducible project can be found here:
https://github.com/ThreeManager785/Inspetor-Issue
We’ve tried many approaches but haven’t been able to resolve it. Is there any way to fix this issue?
The iPad Pro on iPadOS 26 now operates on the same class of silicon as Apple’s entry-level Macs. It ships with M-series processors, 8GB of unified memory, support for multiple resizable windows, a menu bar, and proper external display connections. The device already has the foundation required for professional software development. The only gap is the absence of Xcode.
Making the full version of Xcode available on iPad Pro would not take away from the Mac. Large and resource-intensive projects will still require the power of MacBook Pro and Mac Studio. What it would do is allow smaller and mid-sized projects to be developed directly on iPad Pro, which the hardware is fully capable of handling. That dynamic is complementary, not cannibalizing. Developers would continue to buy Macs but would also buy iPad Pros for portability and flexibility.
The revenue upside is clear. Lowering the entry barrier means more developers enrolling in the Apple Developer Program at $99 per year, creating predictable recurring subscription income. A wider developer base leads to more apps reaching the App Store. Even if many are small, Apple benefits from every transaction through its revenue share. This strengthens the services business, which already delivers the company’s highest margins.
There is also a direct hardware impact. Once Xcode is available, iPad Pro will be recognized as a legitimate professional development device. That drives more unit sales of a high-margin product line and increases attachment rates for accessories like the Magic Keyboard, Apple Pencil, and external monitors. Instead of eroding Mac sales, the effect is expansion. Developers will own both devices.
The case is straightforward. The hardware is ready. The operating system is ready. Enabling full Xcode on iPad Pro would expand the developer funnel, grow recurring subscription revenue, increase App Store volume, and boost high-margin hardware and accessory sales. It is a decision that benefits developers, strengthens the ecosystem, and maximizes profit.
Hi, I have a ninth generation iPad updated to iPados 26 beta 3 but now it no longer updates to the latest version of iPados 26, what can I do?
My app controls the cursor movement in a text view on iPhone and iPads.
On screen touch, the IOS cursor position is out of sync with the app cursor position.
Is there a way to find out, on screen touch, where the ios cursor positition is and update the app cursor to the ios cursor position?
When they are out of sync, the user has to move the cursor to the startIndex and navigate from there. Frustating!
I have looked at many programming books, forums, and internet search with nothing to no avail.
Any help will be greatly appreciated. The app names are SummaGramPhonex and SummaGramIPAD11 and SummaGramIPAD13.
Thanks. Charlie
3Sep25
When changing a camera's exposure, AVFoundation provides a callback which offers the timestamp of the first frame captured with the new exposure duration: AVCaptureDevice.setExposureModeCustom(duration:, iso:, completionHandler:).
I want to get a similar callback when changing frame duration.
After setting AVCaptureDevice.activeVideoMinFrameDuration or AVCaptureDevice.activeVideoMinFrameDuration to a new value, how can I compute the index or the timestamp of the first camera frame which was captured using the newly set frame duration?
How can we receive the iPadOS 18.6.1 update on an iPad? We have configured the MDM update days policy to receive recent, but not the latest, iPadOS updates; however, we are only able to get versions 18.6.2 and 18.6. Is the availability of iPadOS updates dependent on the iPad's region?
Thank you in advance for your assistance.
In iPadOS 26, Apple introduced macOS-style window control buttons (close, minimize, fullscreen) for iPad apps running in a floating window. I'm working on a custom toolbar (UIView) positioned near the top of the window, and I'd like to avoid overlapping with these new controls.
However, I haven't found any public API that exposes the frame, layout margins, or safe area insets related to this new UI region. I've checked the window's safeAreaInsets, additionalSafeAreaInsets, and UIWindowSceneDelegate APIs, but none of them seem to reflect the area occupied by these buttons.
Is there an officially supported way to:
Get the layout information (frame, insets, or margins) of the window control buttons on iPadOS 26?
Or, is there a system-defined guideline or padding value we should use to avoid overlapping this new UI?
Any clarification or guidance would be appreciated!
In our app we have a UICollectionView with Drag&Drop functionality enable and collection view is covering the entire screen. When we drag a collection view item to the edge of the screen it does not scroll the UICollectionView instead that our item turns into the app icon and scrolling blocked. It is happening only if Stage Manager is enabled in the device and if Stage Manager is disabled it is working fine.
This issue we are facing after iOS 18.6 release, before 18.6 it was working fine i.e, collection view was scrolling to next items when we dragging an item to edge of the screen, similar to the iOS calendar app when we drag an event to edge it starts scrolling the date.
And in iOS 26 if we drag an item to edge, Springboard is getting crashed.
Hi,
I'm updating my iPhone app (iPhone only) to be ready with iOS 26.
I'm building my app using Xcode 26.0 beta 6 (17A5305f) and testing it on an iPad running iPadOS 26 (23A5326a).
I found an issue with my new app icon updated using Icon Composer and I was able to find the issue.
An iPhone only app running on iPadOS 26 doesn't use the provided app icon. It always displays the "standard" light icon.
I just added iPad in Supported Destinations and the app icon now respect light/dark/translucent/tinted modes on the Home Screen.
I submitted feedback FB19768667
How can I remove the "recents" section from long-pressing on my app icon?
I've added the following to my AppDelegate, which removes it from the top MenuBar, but not from the app icon context menu.
My app has registered a custom filetype, but it is not a document based app. Opening files imports them into the app's user library, and so does not make sense to have a "recents" list.
override func buildMenu(with builder: any UIMenuBuilder) {
super.buildMenu(with: builder)
builder.remove(menu: .openRecent)
}
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