In iOS 26, the mini keyboard bar does not consistently appear when typing with a hardware keyboard. This behavior differs from iOS 18, where the bar was always visible. See screenshots:

Is there a way to change the resolution in View Areas? It only has 800 x 480 but this is a small screen, there are much larger screens for CarPlay. What I'm missing? This is the CarPlay Simulator app from the Additional Tools for Xcode I'm aware of the Xcode Simulator where you can test different screen sizes but I wonder if CarPlay Simulator app supports that too Thank you

We use a single AVCaptureSession with AVCaptureVideoPreviewLayer and AVCaptureVideoDataOutput (preview-sized buffers, BGRA). When we increase videoZoomFactor, beyond a certain zoom level the image from AVCaptureVideoDataOutput no longer zooms further, while AVCaptureVideoPreviewLayer continues to zoom with the same zoom control. The preview and the video-data output therefore diverge. This behavior appears when the active camera is a physical lens device — wide, ultra-wide, or telephoto (e.g. builtInWideAngleCamera, builtInUltraWideCamera, builtInTelephotoCamera, or similar). It does not appear when the active input is a virtual / multi-camera (e.g. triple camera, dual-wide, or other system multi-camera). Are there known conditions under which this mismatch between preview and video-data output is expected? Thank you.

My application was initially coded to be macOS only so I focused on SwiftUI and AppKit. I am now wanting to add support for iOS. I still envision the core work to be done on macOS but I think there is value to having the ability to do simple tasks on iOS. My question is for anyone who has gone through this previously. How difficult and time consuming is adding iOS support?

On macOS 26.5.2 (25F84), the built-in "Select the previous input source" shortcut (Control+Space) switches the input source and then reverts it roughly 100-500 ms later. The net effect is that the shortcut appears to do nothing. The trigger is the timing of the two key-up events, not their order. I reproduced this with synthetic events (CGEvent posted to .cghidEventTap), varying how long Space is held and the delay between the two key-up events. 15 trials per condition. "reverted" means the input source changed and then changed back, leaving the original source selected. Space hold Key release persisted reverted no response 30 ms simultaneous 14 1 0 60 ms simultaneous 7 8 0 100 ms simultaneous 3 11 1 150 ms simultaneous 1 14 0 200 ms simultaneous 0 15 0 250 ms simultaneous 0 15 0 300 ms simultaneous 2 12 1 600 ms simultaneous 1 13 1 60 ms 20 ms apart, Space first 15 0 0 60 ms 20 ms apart, Control first 15 0 0 300 ms 20 ms apart, Space first 15 0 0 300 ms 20 ms apart, Control first 15 0 0 "simultaneous" means the two key-up events are posted back to back with no delay between them, so they land in the same event batch. A 20 ms gap between the two key-up events makes it completely reliable: 60/60 trials across four conditions. Which key is released first makes no difference. A separate monitor process polling TISCopyCurrentKeyboardInputSource recorded two input source changes per failing trial - the switch, then a revert 104-588 ms later - and exactly one change per trial in the four 20 ms-gap conditions. Other things I checked: Not the input source machinery. Selecting the same two sources 25 times via TISSelectInputSource, with no keyboard involved, never reverted (0/25). The fault is in the hotkey path. Not key auto-repeat. Holding Control+Space does not cycle through input sources. No duplicate binding. AppleSymbolicHotKeys ID 60 is the only enabled system hotkey bound to keycode 49 with Control alone. Not specific to one IME. I see it with ABC and a third-party Japanese input method; Apple Community thread 256254361 reports the same behaviour with English and Russian, 16 "Me too", across multiple keyboards and applications. That reporter also confirms the Globe/Fn key is unaffected. In a week of normal use a background monitor recorded 733 input source changes, of which 6.5-13.4% were a switch immediately followed by a revert (the range depends on the reversal threshold used: 250 ms to 1000 ms). Real-world reversal intervals were 135-433 ms, median 247 ms - inside the range seen in the synthetic reproduction. One caveat on reproducibility: the 600 ms simultaneous-release condition varies between runs. An earlier run of the same matrix had it persisting 14/15 while the run above had it reverting 13/15. The 150-300 ms band failed in both runs. Filed as FBxxxxxxxxx with a self-contained reproducer (single Swift file, ~170 lines, needs Accessibility permission and two or more enabled keyboard input sources). Questions: Is the simultaneous-release behaviour intentional in any way, or is this simply a race in the hotkey handler? Is there a supported way for a user to make Control+Space reliable, short of moving to the Globe/Fn key or a third-party remapper? For anyone hitting this: does the 20 ms release gap also fix it on your machine? I would like to know whether the threshold is machine-dependent.

Is there a way to let users disable this notification in CarPlay, please? I’ve had a few users report that it interrupts their screen. I’ve tried every single setting I can think of to figure out how to disable it for them, but it still comes through. Thanks

My apps are legacy codebases still using AppDelegate instead of SceneDelegate. According to TN3187: Migrating to the UIKit scene-based life cycle, apps should migrate to the scene-based lifecycle. I have the following questions: Is there a specific timeline or deadline for when this migration will be enforced? Will there be deprecation warnings before the assert is triggered? I've tested my app with Xcode 27 beta, and it's not showing any errors or warnings related to this requirement. Based on this, I'm assuming this scene delegate migration may not be relevant for Apple's yearly requirement to submit new apps with the latest iOS SDK, and won't be enforced in April when "apps uploaded to App Store Connect must be built with Xcode 27 or later using an SDK for iOS 27." Can someone confirm if this understanding is correct?

Central talking to one custom peripheral, CoreBluetooth state restoration enabled. Behavior I understand: iOS kills the app for memory pressure, peripheral does something, restoration relaunches into the background. Documented, and I have watched it work. Behavior I do not: I force-quit from the app switcher. The device had been unplugged and off for about a week. Plugged it back in and within a minute it had fresh data that only my app could have sent. So the app ran, and I never opened it. Everything I have read says force-quit is a hard opt-out until the user launches again. The only theory I have is that this is not the same event class as what I tested before. Earlier tests were all notifications from an already-connected peripheral. This time there was a connect request outstanding from before the force-quit, and it completed when the device came back. Possibly a pending connection completing is handled differently than traffic on a live link. I do not have instrumentation on this yet, so I cannot say whether it relaunched or was still resident, and I cannot rule out that the phone rebooted sometime during the week. Adding logging before I try to reproduce. Has anyone characterized this properly? Specifically whether a connectPeripheral pending from before a force-quit survives, and whether its completion can trigger relaunch. The docs do not draw that distinction.

We are currently building a kiosk system that displays an indoor map built using the Apple Maps Toolkit and have encountered a challenge regarding the required link to the Apple legal information page. In a standard web application this is straightforward, but in our kiosk environment following the link opens a new webpage and effectively takes users out of the map application, which disrupts the kiosk experience. Our preferred approach would be to intercept the link and display the legal information in a modal window within the application. However, we've not yet found a way to make this possible. Has Apple got any recommended approach or best practice for handling the mandatory legal link in kiosk deployments? Has anyone seen other kiosk implementations address this requirement in a supported way? Thanks for the support!

As demonstrated in the second screenshot, the reported interface orientation is Landscape‑Left, rather than Portrait. Could this be a bug?

When I toggle on the personal hotspot from control center it turns off in mobile data section and when I toggle it on in the mobile data section the control center shows it as turned off

Hello， We’re seeing an iPad-specific Launch Screen issue related to multitasking window sizes. Environment Device: iPad (iPadOS 26) Device orientation: Landscape App is launched in a small window where the app window is portrait-shaped (width < height) Issue When the iPad is in landscape but the app is launched as a portrait-shaped small window, the LaunchScreen.storyboard appears to be rendered/layouted as landscape, not matching the actual window geometry. As a result, the Launch Screen content is clipped / partially missing (we see blank/empty area at the bottom during launch). After the app finishes launching, our first view controller uses the correct window size and the UI looks fine — the problem is mainly during the Launch Screen phase. What we checked LaunchScreen.storyboard uses Auto Layout and is expected to adapt to screen/window size. This only reproduces when the device orientation and the app window aspect ratio don’t match (landscape device + portrait-shaped app window, or vice versa). When device orientation and window shape are aligned, the Launch Screen displays correctly. Question Is it expected that iPadOS renders LaunchScreen.storyboard based on the interface orientation / size class rather than the actual window bounds in multitasking scenarios? If not expected, what is the recommended way to ensure the Launch Screen matches the app’s actual window size/aspect ratio at launch (without using code, since Launch Screen is static)? Are there any additional diagnostics or recommended steps to help us investigate and confirm the root cause (e.g., specific logs, APIs/values to capture at launch such as UIWindowScene bounds, interfaceOrientation, size classes, or any guidance on how Launch Screen snapshots are chosen/cached in multitasking)? Thank you.

We are experiencing issues during extended automated test executions on iOS devices. During long-duration test runs that involve a high volume of interactions with the device under test, the socket connection is unexpectedly terminated. When this occurs, the automation session is disrupted and the test run fails. We would like to better understand the root cause of this behavior and determine whether it is related to the automation framework, the underlying iOS platform, or another system-level constraint. We have the following questions: Are there any iOS security mechanisms or system protections that may be triggered after a high number of automated interactions, resulting in the termination of an active socket connection? Does iOS impose any runtime limitations, session timeouts, resource restrictions, or inactivity thresholds that could impact long-running automation sessions? Are there any known conditions under which iOS may terminate or reset socket connections during extended periods of intensive device interaction? Any guidance on troubleshooting steps, relevant system logs, or known platform limitations would be greatly appreciated.

I've found a repeatable difference in input-to-display latency on macOS depending only on how an application is launched. Launching an application normally: open -n /Applications/App.app consistently produces higher latency than directly running the exact same bundled executable: /Applications/App.app/Contents/MacOS/App I've reproduced this with a minimal Qt QPlainTextEdit application as well as Koi, Xcode, BBEdit, Sublime Text, and Zed. It reproduces across: Mac mini M2 Pro, macOS Sequoia 15.7.9 MacBook Air M4, macOS Tahoe 26.6.1 Minimal reproduction The Qt application is essentially just: import sys from PyQt6.QtWidgets import QApplication, QPlainTextEdit app = QApplication(sys.argv) editor = QPlainTextEdit() editor.resize(1200, 800) editor.show() sys.exit(app.exec()) I package this as a normal .app and compare: open -n dist/QtLaunchTest.app with: dist/QtLaunchTest.app/Contents/MacOS/QtLaunchTest Input-to-display latency is measured externally from generated keyboard input through to the corresponding visible pixel change on the display, with 200 measurements per run. Results (Launch method, avg, p95, p99) At 60 Hz: Open normally, 29.676 ms, 37.742 ms, 43.080 ms Direct Mach-O, 16.404 ms, 20.500 ms, 24.882 ms The p95 difference is 17.242 ms, compared with a 60 Hz frame interval of 16.667 ms. At 100 Hz: Open normally, 24.687 ms, 31.182 ms, 33.797 ms Direct Mach-O, 16.295 ms, 20.623 ms, 23.286 ms The p95 difference is 10.559 ms, compared with a 100 Hz frame interval of 10.000 ms. That relationship is what makes me suspect this is related to presentation/frame scheduling rather than application processing. This also happens with Xcode The same effect occurs when comparing normal and direct launches of Xcode. (Launch method avg p95 p99) On macOS Sequoia 15.7.9: Open normally, 23.433 ms, 29.886 ms, 31.877 ms Direct Mach-O, 15.787 ms, 19.494 ms, 20.480 ms On macOS Tahoe 26.6.1 on an M4 MacBook Air: Open normally, 35.830 ms, 40.122 ms, 53.996 ms Direct Mach-O, 23.639 ms, 27.233 ms, 37.855 ms Koi, BBEdit, Sublime Text, and Zed show the same direction of effect. Things I’ve ruled out so far The difference does not appear to be caused by Terminal. Direct execution remains fast after detaching the process, and using open on the Mach-O itself is also fast. Different LaunchServices forms (open -n, open -na, open -nb, open -b) all produce the slower behavior. I've also compared process QoS and final AppKit activation state, which are the same. Most importantly, application-side instrumentation does not show the additional latency. Input processing and painting complete quickly in both cases. The difference appears only when measuring through to the actual pixel change on the display. Question Is there some presentation, WindowServer, Core Animation, RunningBoard, or application-lifecycle state established when an application is launched through LaunchServices that could affect when completed rendering reaches the display? The refresh-rate result makes it look as though the normally launched application is reaching the display approximately one presentation opportunity later: Direct: input → update → paint → presentation N Normal: input → update → paint → presentation N+1 That's only a model based on the measurements. I haven’t directly observed the presentation sequence. I'm particularly interested in what APIs or Instruments traces could expose the difference between these two processes after they’ve reached the same active AppKit state. I've documented the full investigation, including additional measurements and tests, here: https://hackerman.ai/research/investigating-macos-input-to-display-latency/ Any pointers on what to instrument next would be appreciated.

Hello. Some users of my app experience crashes that mention PDFKit. I managed to find out what specific PDF file caused the crash and created a sample that demonstrates the issue and created a bug report in Feedback Assistant (FB22409977). Unfortunately I didn't get any answer for over a month, hence I'm writing it here so others can see that this is a known issue. The crash repro sample is very simple, it's just a PDFView that opens a bundled PDF file upon application lanunch. To cause the crash it is only needed to zoom-in and move around the page that has a table. The crash happens when the system tries to do some sort of OCR. The original crash report came from iPhone 11 user running iOS 26.3.1. Recently another user with iPhone 16 Pro Max running 26.5 experienced the same crash. Thread 12 Queue : PDFKWit.PDFDocument.formFillingQueue (serial) #0 0x000000018d320bd8 in PageLayout::GetBoundsForRangeWithinLine () #1 0x000000018d320c88 in PageLayout::GetBoundsForTextRange () #2 0x000000018d393028 in CGPDFTaggedNodeCreateCopyWithStringRange () #3 0x000000018d316630 in invocation function for block in TaggedParser::InsertLinkAnnotationsIntoStructureTree(CGPDFTaggedNode*, CGPDFPage*, PageLayout&) () #4 0x000000018d104f00 in CGPDFPageEnumerateAnnotations () #5 0x000000018d106968 in CGPDFPageCopyRootTaggedNode () #6 0x000000018d106710 in CGPDFPageInsertTableDescriptions () #7 0x00000001957a65b8 in +[PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:] () #8 0x00000001957a3030 in +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] () #9 0x000000019584c018 in __31-[PDFView visiblePagesChanged:]_block_invoke () When CG_PDF_VERBOSE env variable is set, "New text range needs to be within the original node's text range." warning is printed to console several times before the crash happens.

Dear Apple, I am sending feedback regarding the desktop management of macOS to improve the user experience. Mission Control currently only has a “+” button to the right, meaning that all new desktops are forced to the right side of the line. Adding an identical “+” button to the left will increase ease of using the OS, as I don’t necessarily need every new desktop to be on the right side. This will increase usability and make using desktops significantly easier than manually dragging them into the needed positions every time I add a desktop. Another thing is that when I maximize apps, all desktops go to the left by one spot. There should be a setting where you can control where desktops go when maximizing screens, either you want every desktop to go to the right or the left. This makes things easier as sometimes I have my main app on the right, with all the multi-tasking on the left. If desktops move to the right instead of the left, no open apps will be interfered with. (Please put this setting in the “Desktop and Dock” section). I have been using macOS for a year now, and those details were quite clear. Please consider this as a software update for over 100 million Macbook users, increasing usability without changing the OS so much people barely know how to use it. I have been concentrating significantly on macOS lately, noticing an upgrade followed by another, and is how I noticed this. Please consider this a fresh start for my feedback. I apologize for my previous un-trained replies. I am not a trained professional, but I genuinely care about improving the user experience and wanted to share these layout ideas. I promise to keep my interactions respectful of the forum guidelines from now on. May these desktop management ideas be considered? Thanks, Alyaman

Heya, Been struggling with getting a 3 column NavigationSplitView hide both the Sidebar and Content column to only show the Detail view and back to 3 columns in the same window. Basically applying the hide sidebar when pressing the toggle to both the sidebar and the content view. On iOS I could use .displaydetail but on macOs it seems impossible to do as one or the other shows up. I was able to force it to a width of 0 but that gives other issues such as the need to disable the animates otherwise things start flying. Any ideas on how to solve this? ideally we would have something as a double sidebar or a split view that does not extend that nav to all columns as thats a pain to deal with.

Is there currently an option to make generated asset symbols public? If not, would it be possible to set the generated asset symbol so they are public. It's quite common to have an apps design system implemented in a separate framework. Currently the generate assets symbols is useless for this as they can't be access in the framework consumer. It would be great to add it to this new dropdown in Xcode 16 or along side it. (113704993 in the release notes) So the options would be Internal, Public and Off. This should affect the symbols, the extensions and the framework support. (There's a post on the swift forums about this as well here: https://forums.swift.org/t/generate-images-and-colors-inside-a-swift-package/65674)

We're preparing our SDK and host applications for iOS 27 and would like to understand the mandatory requirements for supporting the new Liquid Glass design. Beyond building with the iOS 27 SDK, are there any required implementation or migration steps (UIKit or SwiftUI) that developers must adopt to ensure full compatibility? Are there any behaviors or APIs that require explicit changes, or does the system automatically handle Liquid Glass for standard controls? We're specifically interested in the minimum required changes for compliance and compatibility, rather than optional design enhancements. Thanks in advance for any guidance.

Hello, Could someone from Apple clarify the support and behavior of the UIDesignRequiresCompatibility property? The UIDesignRequiresCompatibility documentation states that this property will be ignored for builds targeting iOS 27 or later. I have a couple of questions: Does "builds targeting iOS 27 or later" refer to an app that was built using Xcode 27 or later? iOS 27 is expected to be released in Fall 2026. Suppose that after iOS 27 is released, I create a new build using Xcode 26, with UIDesignRequiresCompatibility set to true, and install that build on an iOS 27 device. Will UIDesignRequiresCompatibility still be honored in this scenario, or will it be ignored and the app will use the Liquid Glass UI? Thanks!