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!

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

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.

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?

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

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)         }     } }

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?

App builds fine locally on iPad. Once released to TestFlight, the app crashes on startup. Can't even release previous builds to TestFlight that worked fine before iOS 26. Using .net Maui 8.0.413 and Xcode 16.4. IpadOS 18.6 Crash log: Incident Identifier: 2183463F-CAFD-4E0C-95FB-8E56876118E9 Distributor ID: com.apple.TestFlight Hardware Model: iPad15,7 Process: VS_NASCO_Auscultation [3576] Path: /private/var/containers/Bundle/Application/062FE418-9CD6-4509-B368-5FD6465FF1F9/VS_NASCO_Auscultation.app/VS_NASCO_Auscultation Identifier: com.NASCO.Auscultation Version: 2.8.04 (20) AppStoreTools: 17A323 AppVariant: 1:iPad15,7:18 Beta: YES Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.NASCO.Auscultation [2590] Date/Time: 2025-09-22 14:31:29.9710 -0500 Launch Time: 2025-09-22 14:31:27.7714 -0500 OS Version: iPhone OS 18.6 (22G86) Release Type: User Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: VS_NASCO_Auscultation [3576] Triggered by Thread: 0 Thread 0 Crashed: 0 libsystem_kernel.dylib 0x00000001df60f1dc __pthread_kill + 8 1 libsystem_pthread.dylib 0x0000000218bf0c60 pthread_kill + 268 (pthread.c:1721) 2 libsystem_c.dylib 0x0000000196e9a0ac abort + 124 (abort.c:122) 3 VS_NASCO_Auscultation 0x0000000105157294 0x102e5c000 + 36680340 4 VS_NASCO_Auscultation 0x00000001050cb930 mono_runtime_setup_stat_profiler + 0 (mini-posix.c:690) 5 libsystem_platform.dylib 0x0000000218b40a68 _sigtramp + 56 (sigtramp.c:116) 6 libsystem_pthread.dylib 0x0000000218bf0c60 pthread_kill + 268 (pthread.c:1721) 7 libsystem_c.dylib 0x0000000196e9a0ac abort + 124 (abort.c:122) 8 VS_NASCO_Auscultation 0x0000000104f91170 mono_log_write_os_log + 408 (mono-log-darwin.c:0) 9 VS_NASCO_Auscultation 0x0000000104f8644c monoeg_g_logv + 172 (goutput.c:173) 10 VS_NASCO_Auscultation 0x0000000104f86594 monoeg_g_log + 28 (goutput.c:184) 11 VS_NASCO_Auscultation 0x00000001050a5f84 load_aot_module + 3172 (aot-runtime.c:2365) 12 VS_NASCO_Auscultation 0x0000000104fe4f48 mono_assembly_request_load_from + 1104 (assembly.c:2020) 13 VS_NASCO_Auscultation 0x0000000104fe4a68 mono_assembly_request_open + 472 (assembly.c:1625) 14 VS_NASCO_Auscultation 0x0000000104fe5cec mono_assembly_open + 80 (assembly.c:1828) 15 VS_NASCO_Auscultation 0x0000000104e1a0ac xamarin_assembly_preload_hook + 884 (monotouch-main.m:157) 16 VS_NASCO_Auscultation 0x0000000104fe6800 invoke_assembly_preload_hook + 64 (assembly.c:1283) 17 VS_NASCO_Auscultation 0x0000000104fe41e4 mono_assembly_request_byname + 1060 (assembly.c:2786) 18 VS_NASCO_Auscultation 0x00000001050af2e0 load_image + 280 (aot-runtime.c:325) 19 VS_NASCO_Auscultation 0x00000001050a5f1c load_aot_module + 3068 (aot-runtime.c:2358) 20 VS_NASCO_Auscultation 0x00000001050aa71c mono_aot_get_method + 292 (aot-runtime.c:4920) 21 VS_NASCO_Auscultation 0x000000010509e924 mono_jit_compile_method_with_opt + 472 (mini-runtime.c:2759) 22 VS_NASCO_Auscultation 0x000000010509cd10 mono_jit_runtime_invoke + 572 (mini-runtime.c:3525) 23 VS_NASCO_Auscultation 0x0000000105044b74 mono_runtime_invoke_checked + 148 (object.c:2792) 24 VS_NASCO_Auscultation 0x0000000105001720 create_exception_two_strings + 592 (exception.c:177) 25 VS_NASCO_Auscultation 0x00000001050014a4 mono_exception_from_name_two_strings_checked + 148 (exception.c:236) 26 VS_NASCO_Auscultation 0x0000000104fe0ab0 mono_runtime_init_checked + 708 (appdomain.c:288) 27 VS_NASCO_Auscultation 0x000000010509c64c mini_init + 6648 (mini-runtime.c:4889) 28 VS_NASCO_Auscultation 0x00000001050a3ad8 mono_jit_init_version + 20 (driver.c:2823) 29 VS_NASCO_Auscultation 0x0000000104e157ac xamarin_bridge_initialize + 216 (monovm-bridge.m:88) 30 VS_NASCO_Auscultation 0x0000000104e1a968 xamarin_main + 1784 (monotouch-main.m:438) 31 VS_NASCO_Auscultation 0x00000001051033ec main + 72 (main.arm64.mm:236) 32 dyld 0x00000001b58e5f08 start + 6040 (dyldMain.cpp:1450) Thread 1: 0 libsystem_pthread.dylib 0x0000000218be9aa4 start_wqthread + 0 Thread 2: 0 libsystem_kernel.dylib 0x00000001df60a438 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x0000000218beae50 _pthread_cond_wait + 984 (pthread_cond.c:862) 2 VS_NASCO_Auscultation 0x0000000104fdde4c thread_func + 412 (sgen-thread-pool.c:195) 3 libsystem_pthread.dylib 0x0000000218bec344 _pthread_start + 136 (pthread.c:931) 4 libsystem_pthread.dylib 0x0000000218be9ab8 thread_start + 8 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0xffffffff9838bfdf x5: 0x0000000000000018 x6: 0x000000016cfa0730 x7: 0x000000016cf9fe20 x8: 0x9b8f66cd52cb42ec x9: 0x9b8f66ccab4b5cec x10: 0x00000000000003ff x11: 0x000000016cf9fe98 x12: 0x0000000000000000 x13: 0x00000001031e01a0 x14: 0x00000001a960913c x15: 0x00000001a960be20 x16: 0x0000000000000148 x17: 0x00000001f9801e00 x18: 0x0000000000000000 x19: 0x0000000000000006 x20: 0x0000000000000103 x21: 0x00000001f9801ee0 x22: 0x0000000000000010 x23: 0x000000000000000b x24: 0x0000000000002788 x25: 0x0000000105687624 x26: 0x000000010553ea10 x27: 0x000000010a6a0880 x28: 0x00000000000003c8 fp: 0x000000016cfa0740 lr: 0x0000000218bf0c60 sp: 0x000000016cfa0720 pc: 0x00000001df60f1dc cpsr: 0x40001000 esr: 0x56000080 Address size fault Binary Images: 0x102e5c000 - 0x10535bfff VS_NASCO_Auscultation arm64 <9b9a7de8b40b303bbc3d1a11686bb1dc> /var/containers/Bundle/Application/062FE418-9CD6-4509-B368-5FD6465FF1F9/VS_NASCO_Auscultation.app/VS_NASCO_Auscultation 0x109498000 - 0x1099fbfff libSkiaSharp arm64 /private/var/containers/Bundle/Application/062FE418-9CD6-4509-B368-5FD6465FF1F9/VS_NASCO_Auscultation.app/Frameworks/libSkiaSharp.framework/libSkiaSharp 0x196e23000 - 0x196ea26c3 libsystem_c.dylib arm64e <335cd87d234b3fc182db943350d31a88> /usr/lib/system/libsystem_c.dylib 0x1b58a7000 - 0x1b594187b dyld arm64e /usr/lib/dyld 0x1df604000 - 0x1df63debf libsystem_kernel.dylib arm64e /usr/lib/system/libsystem_kernel.dylib 0x218b3e000 - 0x218b458cf libsystem_platform.dylib arm64e /usr/lib/system/libsystem_platform.dylib 0x218be9000 - 0x218bf53f3 libsystem_pthread.dylib arm64e <1ee1922008593cbcbdebdf37ca2e8e4f> /usr/lib/system/libsystem_pthread.dylib EOF

Using the floating keyboard extensively. Often It starts to jump up and down. I have to pinch out to see the large version and pinch in again to restore the floating version. Sometimes just touching a key sets it off. Sometimes returning to a window from which the keyboard is displayed starts the issue. This was never a problem in ipad os 18.

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.

Hi , I have a requirement like, Develop an app for iPad and app uses .net core apis. App will be in kiosk mode, and app doesn't have any type of authentication even OTP also. As the apis will be publishing to all over internet, how can we achieve security to apis? Kindly provide suggestions for this implementation

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.

Hello In my app code (in flutter) but you can remain if you code in other langages, maybe you can help in other ways, I have a file called: project.pbxproj I am wondering about this line: ARGETED_DEVICE_FAMILY = "1,2"; Is it true that the 1 is for Iphone and 2 for Ipad? Would that mean that if I wrote "1" and removed 2, then in my app page in developer store side I would not see a tab for Ipad where the store requires from me to post screenshots for ipad? For instance (see image below) I know you guys use XCODE and it handels it itself, but can you open your .ipa files and check "project.pbxproj" to confirm differences between these files when the app is targeting Iphone Vs targeting Ipad? Thanks