Hi, I am building an app that depends on multiple iOS devices connecting to a designated "coordinator" iOS device. I am using MPC, and it works great when the devices are connected to the same WiFi AP, with virtually 100% connection success. My definition of success is a near instant detection of available devices, >95% connection success rate, and a stable ongoing connection with no unexpected disconnects. The issue arises when the devices are not connected to the same WiFi network (or connected to no network with WiFi and bluetooth still on). Devices detect each other immediately, but when initiating a connection, both devices initiate a handshake, but the connection is not successful. In the few times where the connection succeeds, the connection quality is high, stable, and doesn't drop. Is this a known limitation of the framework? Could I be doing something wrong in my implementation?

I have installed the latest beta on my iPad , iPadOS 16.1 (20B5050f) On running in app in Playgrounds that has a TextField, external keyboard input do not seem to be working. Tapping on the Text field inserts the cursor but no text can be entered on my external keyboard. (TextEditor field also do not work) Tested with both a Smart Keyboard and a Magic Keyboard. The keyboard works to enter the code in playgrounds, so it is not a keyboard connection issue. Disconnecting the keyboard, the onscreen keyboard is displayed and works correctly. Is this a Playgrounds issue or an iPadOS 16.1 issue or a compatibility issue with Playgrounds & iPadOS 16.1 ? import SwiftUI struct ContentView: View {     @State var field: String = "Test input"          var body: some View {         VStack {             Image(systemName: "globe")                 .imageScale(.large)                 .foregroundColor(.accentColor)             Text("Hello, world!")             TextField("", text: $field)                 .frame(height: 100)         }     } }

I’m trying to understand the expected behavior of TabView when using .tabViewStyle(.page) on iPadOS with a hardware keyboard. When I place a TabView in page mode, swipe gestures correctly move between pages. However, left and right arrow keys do nothing by default, even when the view is made focusable. This feels a bit surprising, since paging with arrow keys seems like a natural keyboard interaction when a keyboard is attached. Right now, to get arrow-key navigation working, I have to manually: Make the view focusable Listen for arrow key presses Update the selection state manually This works, but it feels a little tedious for something that seems like it could be built-in. import SwiftUI struct PageTabsExample: View { @State private var selection = 0 private let pageCount = 3 var body: some View { TabView(selection: $selection) { Color.red.tag(0) Color.blue.tag(1) Color.green.tag(2) } .tabViewStyle(.page) .indexViewStyle(.page) .focusable(true) .onKeyPress(.leftArrow) { guard selection > 0 else { return .ignored } selection -= 1 return .handled } .onKeyPress(.rightArrow) { guard selection < pageCount - 1 else { return .ignored } selection += 1 return .handled } } } My questions: Is this lack of default keyboard paging for page-style TabView intentional on iPadOS with a hardware keyboard? Is there a built-in way to enable arrow-key navigation for page-style TabView, or is manual handling the expected approach? Does my approach above look like the “SwiftUI-correct” way to do this, or is there a better pattern for integrating keyboard navigation with paging? For this kind of behavior, is it generally recommended to use .onKeyPress like I’m doing here, or would .keyboardShortcut be more appropriate (for example, wiring arrow keys to actions instead)? Any guidance or clarification would be greatly appreciated. I just want to make sure I’m not missing a simpler or more idiomatic solution. Thanks!

When I try to validate my app I get the following error: Invalid bundle. Because your app supports Multitasking on iPad, you need to include the LaunchScreen.storyboard launch storyboard file in your com.augmentedReality.virtualTags bundle. Use UlLaunchScreen instead if the app's MinimumOSVersion is 14 or higher and you prefer to configure the launch screen without storyboards. For details, see: https:// developer.apple.com/documentation/bundleresources/information_property_list/ uilaunchstoryboardname (ID: 236f630a-a014-48e8-910a-77d9c0ff6f51) What should I do to fix it? In the previous Xcode version and on another app it did not appear. MacBook Pro M5, Tahow 26.1, Xcode 26.1.1

Number keys on iPadOS 26 register incorrect/random characters, making numeric input unreliable across all applications. Affected Versions iPadOS 26.0 through 26.1 (build 23B85) Platform-specific: Only iPadOS (iPhone doesn't present the full on-screen keyboard) Reproduction Steps Open any app with a numeric text field (For example, Apple's Contacts) Tap numeric text field - a small number-only pad appears Dismiss this small numpad (tap outside or hit return) Tap the field again - full keyboard with numbers appears Type numbers on this full keyboard Result: Numbers register as random/incorrect characters Scope Affects numeric keyboard types (.numberPad, .decimalPad ) Reproducible in Apple's native apps (Contacts or any apps that has numeric TextField) Impact Critical: Users cannot reliably enter phone numbers, passwords, financial data, or any numeric input. Other findings Keyboard starts to register correct keys when switch from the full on-screen keyboard to alphabetic page, and then back to the page with numeric keys

When utilizing Paperkit in its simplest form, PaperMarkupViewController does not show the option to add images. Furthermore, trying to add images directly to the PaperMarkup's insertNewImage() function does not display anything. It seems like image functionality is entirely broken on Xcode 26. This can be seen through the following example done by a fellow member here on the forums: https://gist.github.com/clarkezone/68eb3ee13b5607782ceb2e20cece4ab3

For what iPhone and iPad models under iOS 26 SpeechTranscriber.isAvailable is true

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.

Starting with iOS 18, UITabBarController no longer updates tab bar item titles when localized strings are changed or reassigned at runtime. This behavior worked correctly in iOS 17 and earlier, but in iOS 18 the tab bar titles remain unchanged until the app restarts or the view controller hierarchy is reset. This regression appears to be caused by internal UITabBarController optimizations introduced in iOS 18. Steps to Reproduce Create a UITabBarController with two or more tabs, each having a UITabBarItem with a title. Localize the tab titles using NSLocalizedString(): tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Run the app. Change the app’s language at runtime (without restarting), or manually reassign the localized titles again: tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Observe that the tab bar titles do not update visually.

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.

I have a custom input view in my app which is .focusable(). It behaves similar to a TextField, where it must be focused in order to be used. This works fine on all platforms including iPad, except when when an external keyboard is connected (magic keyboard), in which case it can't be focused anymore and becomes unusable. Is there a solution to this, or a workaround? My view is very complex, so simple solutions like replacing it with a native view isn't possible, and I must be able to pragmatically force it to focus. Here's a very basic example replicating my issue. Non of the functionality works when a keyboard is connected: struct FocusableTestView: View { @FocusState private var isRectFocused: Bool var body: some View { VStack { // This text field should focus the custom input when pressing return: TextField("Enter text", text: .constant("")) .textFieldStyle(.roundedBorder) .onSubmit { isRectFocused = true } .onKeyPress(.return) { isRectFocused = true return .handled } // This custom "input" should focus itself when tapped: Rectangle() .fill(isRectFocused ? Color.accentColor : Color.gray.opacity(0.3)) .frame(width: 100, height: 100) .overlay( Text(isRectFocused ? "Focused" : "Tap me") ) .focusable(true, interactions: .edit) .focused($isRectFocused) .onTapGesture { isRectFocused = true print("Focused rectangle") } // The focus should be able to be controlled externally: Button("Toggle Focus") { isRectFocused.toggle() } .buttonStyle(.bordered) } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center) } }

We are using three column split view as root of our app and wants to hide the supplementary column alone in some cases and behaves like two column split view. With the existing apis we are unable to achieve this since it hides primary column as well and not giving expected results. .hide(.supplementary) setViewController(nil, for: .supplementary) But seen this behavior in Native Notes app when using the View as List and Gallery option. is there any way to achieve this with maintaining three column split view itself ?

Hi everyone I'm experiencing an issue with iPadOS 26 regarding multi-touch gesture detection. When performing a quick four-finger gesture (tap and swipe), the system often fails to recognize the input. This especially affects multi-touch gestures, such as rhythm games with difficult levels. Steps to Reproduce: Place four fingers on the screen. Perform a quick tap or a quick horizontal swipe (like the one used to switch apps). Observe whether the gesture is ignored or detected inconsistently. Expected Behavior: 4-finger multitouch gestures should be recognized regardless of gesture speed, just like previous iPadOS versions. Actual Behavior: Gestures fail to be detected when executed quickly—same gestures still work, and miss notes in rhythm games. You can check out my posts on Twitter/x and Facebook: [https://x.com/kokona_fwa/status/1978131164104728949?s=61] Facebook: [https://m.facebook.com/groups/idipad/permalink/24438964899058806/?]

With macOS Tahoe, Launchpad has been replaced by an App Library–style mode within Spotlight. While the alleged intention is UX consistency across the Apple ecosystem, the result is both a catastrophic usability regression and a radical break in consistency with iOS and iPadOS. Predefined App Library categorization is functionally incoherent: On iOS and now macOS, Apple’s predefined App Library categories place apps with seemingly identical functionality into unrelated groups—for example, 3D scanning tools scattered across Education, Utilities, and Productivity. Instead of making apps easier to find, this effectively creates a labyrinth that users must traverse to locate apps whose names and icons they may not recall. However Apple defines its app categories, they are not only inconsistent but also hopelessly inadequate for the long tail of real-world applications and user workflows. Loss of user control: Launchpad enabled users to group and organize applications according to their workflows. This aligns with Apple’s own Human Interface Guidelines, which emphasize user control, discoverability, and predictable behavior. The new Spotlight interface removes that flexibility, locking users into predefined categories that both impede and mislead—and cannot be overridden. Consistency across platforms is broken: If the goal was to unify iOS, iPadOS, and macOS, this approach actually undermines consistency. On iOS and iPadOS, users can still rely on a customizable Home Screen—a Launchpad-like experience—as their primary way of launching apps. In Tahoe, that option has been removed. macOS now forces users to depend exclusively on Spotlight with App Library categories, while eliminating the very feature that was consistent across platforms. Catastrophic impact on my workflow: As an interdisciplinary artist working in 2D, 3D, and time-based media, as well as coding, I make extensive use of a constantly changing array of AI tools and experiment with many new apps and web services, which I often turn into Web Apps. I cannot possibly recall the names of every native and web app on my system. I need predictable access to groups of related tools. Tahoe’s new auto-categories split those apps apart arbitrarily, slowing me down and interrupting established workflows, forcing me to navigate the aforementioned labyrinth just to find what I need. Proposal: A constructive way forward High-level objective: Simply restore Launchpad—or restore the ability to customize app categories/folders and manually assign apps to them, overriding or augmenting the predefined categories. This ensures users can launch apps according to their workflow, without needing to remember exact names or icons. Possible solutions: Allow manual subfolders within Applications, represented hierarchically in Spotlight. Provide a fullscreen Launchpad-like organizer (with uninstall via long-click, etc.), either as a replacement or toggleable option. Retain Apple’s auto-categories for those who prefer them, but let users override or augment them with their own. In summary: Tahoe eliminates a working, consistent paradigm (Launchpad/Home Screen) and forces reliance on an App Library system that categorizes poorly and cannot be customized. This is both a step backwards in functionality and a break in cross-platform consistency. A constructive solution is to restore Launchpad—or at least restore the ability for users to organize apps in ways that fit their workflows.

I’m experiencing a strange issue with the App Switcher on my iPad. When I swipe up from the bottom to open the App Switcher, the apps that should be running sometimes don’t appear — they briefly flash for a split second and then disappear. The App Switcher itself stays open, but it shows no app cards. Here are some details: Device: iPad Pro (11-inch, 2nd generation) iPadOS version: 26.0.1 Reproducibility: Happens intermittently Steps to reproduce: Open several apps. Swipe up from the bottom and pause to show the App Switcher. Sometimes, the app cards flash for a moment and then disappear, leaving the App Switcher empty. Expected behavior: The App Switcher should display all running apps consistently. Actual behavior: The App Switcher appears, but the app cards briefly flash and disappear, leaving a blank screen. I’ve seen a few similar reports on the Apple Support Community, but I’m not sure if this is a known issue in iPadOS 26.0.1. Has anyone else encountered this problem? Any confirmations or workarounds would be appreciated. Thank you in advance!

Hi, I’m using the latest iPad Pro (13-inch) and I can see that Metal offers an rgb10a2unorm texture for rendering, but when I render a grey ramp and measure the actual luminance, I get a pattern that I would expect from an 8-bit texture (see below). Before I start ripping apart all my code, is there anything else I need to do to convince iOS to render my texture in 10-bit? I already tried setting the PixelFormat in my CMetalLayer to rgb10a2unorm, but that didn’t change anything.

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?

The app icon of my iPad app appears as a placeholder/template instead of the correct app icon when viewed through the App Store. It is correctly displayed on the website version of the App Store, in App Store Connect, and when running the app. I noticed that another app with the same issue is "Things 3 for iPad." This might be related to the fact that both apps are iPad-only. I implemented a new app icon using the new Icon Composer. Since users can switch between different icons, some are created with Icon Composer and others are still included traditionally within the asset folder. This is my app (Bubbles' Journal): https://apps.apple.com/app/id1547297023

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?