I found that the failing corner in native macOS window tiling changes with the Dock position. With the Dock on the right, the upper-right corner produces the right half instead of a quarter. With the Dock on the left, the upper-left corner produces the left half instead of a quarter. With the Dock at the bottom, all four corners produce quarters. Apple's macOS Tahoe guide describes dragging to any corner as a way to tile a window there. Configuration Mac mini Mac14,12, Apple M2 Pro macOS Tahoe 26.7 (25G229) One external iiyama PL4071UH (ProLite X4071UHSU) display, with a [native panel resolution of 3840 × 2160]; no adjacent display and mirroring off. A 3840 × 2160 mode is available in macOS, but it was not the mode used for these measurements. Active macOS display mode reported by CGDisplayMode and System Information: 3008 × 1692 pixels at 60 Hz; the interface “looks like” 1504 × 846 points (2× backing scale). This is a scaled configuration on the 4K display. NSScreen.frame: 1504 × 846 points. NSScreen.visibleFrame with the Dock on the right: approximately 1456 × 816 points (about 48 points removed at the right for the Dock and 30 at the top for the menu bar). macOS reports Television: Yes for this display and exposes an Underscan control in Displays settings. The slider appeared at the “No” end during inspection; its effect on this tiling behavior has not been tested. Dock position changed between right, left, and bottom for the comparison below Dock auto-hide is currently off (com.apple.dock autohide = 0) Native drag-to-edge tiling and the Option-key tiling accelerator enabled; tiled window margins disabled Upper-right Hot Corner configured without a modifier key during the right-Dock measurement Steps to reproduce Open a blank, resizable TextEdit window and enable native drag-to-edge tiling. Set the Dock position to Right in System Settings → Desktop & Dock. Drag the window by its title bar to each screen corner and release after the tiling preview appears. Set the Dock position to Left and repeat. Set the Dock position to Bottom and repeat. Dock-position comparison Dock position Upper-left corner Upper-right corner Lower corners Right quarter right half quarters Left left half quarter quarters Bottom quarter quarter quarters The left- and bottom-Dock comparisons are direct user observations. The right-Dock case was also measured programmatically as described below. This pattern points to a side-Dock interaction with detection of the adjacent upper corner; the internal cause is not yet established. The display's scaled mode and its classification as a television are additional variables worth recording. Neither has been isolated as a cause: the controlled change so far is the Dock position. A useful follow-up would be to repeat the same corner tests at another display mode, including 3840 × 2160, with the Dock kept on the same side, and to record the Underscan setting. Instrumented result with Dock on the right I sampled NSEvent.mouseLocation every 20 ms, used CGEventSource.buttonState to identify the release, and read the window bounds using CGWindowListCopyWindowInfo about 0.6 seconds later. The same TextEdit window ID was observed for all four corner tests. Pointer and window coordinates below use the top-left of the display as (0, 0); dimensions are in macOS points. Release corner Pointer (x, y) Window (x, y, width, height) Result Top left (0, 0) (-1, 30, 727, 409) quarter Top right (1503.98, 0) (727, 30, 728, 816) RIGHT HALF Bottom left (0, 845.98) (-1, 438, 727, 409) quarter Bottom right (1503.98, 845.98) (727, 438, 728, 409) quarter At the upper-right release, the pointer is effectively at the screen's rightmost x coordinate and at y = 0. The resulting window is 816 points high, compared with 409 points for each quarter tile. The Hot Corner did not prevent the pointer from reaching that coordinate. Expected result Dragging to any of the four corners should produce the corresponding quarter regardless of whether the Dock is on the right, left, or bottom.

In my CarPlaySceneDelegate.swift, I have two tabs: The first tab uses a CPListImageRowItem with a CPListImageRowItemRowElement. The scroll direction is inverted, and the side button does not function correctly. The second tab uses multiple CPListItem objects. There are no issues: scrolling works in the correct direction, and the side button behaves as expected. Steps To Reproduce Launch the app. Connect to CarPlay. In the first tab, scroll up and down, then use the side button to navigate. In the second tab, scroll up and down, then use the side button to navigate. As observed, the scrolling behavior is different between the two tabs. Code Example: import CarPlay import UIKit class CarPlaySceneDelegate: UIResponder, CPTemplateApplicationSceneDelegate { var interfaceController: CPInterfaceController? func templateApplicationScene( _ templateApplicationScene: CPTemplateApplicationScene, didConnect interfaceController: CPInterfaceController ) { self.interfaceController = interfaceController downloadImageAndSetupTemplates() } func templateApplicationScene( _ templateApplicationScene: CPTemplateApplicationScene, didDisconnectInterfaceController interfaceController: CPInterfaceController ) { self.interfaceController = nil } private func downloadImageAndSetupTemplates() { let urlString = "https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRcYUjd1FYkF04-8Vb7PKI1mGoF2quLPHKjvnR7V4ReZR8UjW-0NJ_kC7q13eISZGoTCLHaDPVbOthhH9QNq-YA0uuSUjfAoB3PPs1aXQ&s=10" guard let url = URL(string: urlString) else { setupTemplates(with: UIImage(systemName: "photo")!) return } URLSession.shared.dataTask(with: url) { [weak self] data, _, _ in let image: UIImage if let data = data, let downloaded = UIImage(data: data) { image = downloaded } else { image = UIImage(systemName: "photo")! } DispatchQueue.main.async { self?.setupTemplates(with: image) } }.resume() } private func setupTemplates(with image: UIImage) { // Tab 1 : un seul CPListImageRowItem avec 12 CPListImageRowItemRowElement let elements: [CPListImageRowItemRowElement] = (1...12).map { index in CPListImageRowItemRowElement(image: image, title: "test \(index)", subtitle: nil) } let rowItem = CPListImageRowItem(text: "Images", elements: elements, allowsMultipleLines: true) rowItem.listImageRowHandler = { item, elementIndex, completion in print("tapped element \(elementIndex)") completion() } let tab1Section = CPListSection(items: [rowItem]) let tab1Template = CPListTemplate(title: "CPListImageRowItemRowElement", sections: [tab1Section]) // Tab 2 : 12 CPListItem simples let tab2Items: [CPListItem] = (1...12).map { index in let item = CPListItem(text: "Item \(index)", detailText: "Detail \(index)") item.handler = { _, completion in print("handler Tab 2") completion() } return item } let tab2Section = CPListSection(items: tab2Items) let tab2Template = CPListTemplate(title: "CPListItem", sections: [tab2Section]) // CPTabBarTemplate avec les deux tabs let tabBar = CPTabBarTemplate(templates: [tab1Template, tab2Template]) interfaceController?.setRootTemplate(tabBar, animated: true) } } Here is a quick video:

I’m simulating an iPhone Duo using Xcode 27.1 beta, and I’m having trouble tapping buttons placed near the top of the screen. It seems that the top ~20 pixels of the screen are not responding to taps. In my ViewController, preferredScreenEdgesDeferringSystemGestures returns .all, so system gestures should require two swipes to be triggered. However, a simple tap in this area does not seem to be recognized. This appears to happen only on iPhone Duo; taps work normally on other iPhone models. Does anyone know whether this behavior is expected to occur on the actual iPhone Duo hardware as well, or is it specific to the simulator? For reference, the buttons are positioned according to LayoutMarginsGuide with Safe Area. FB24914903 I wonder if anyone knows how to get the top margin size programmatically.

Security concern: To provide a visually appealing transition when launching or leaving an application, iOS introduced a feature that automatically captures a screenshot of the current view when an app is moved to the background. This screenshot is subsequently displayed as a preview in the App Switcher. There is security concern that the app shows sensitive information like activation codes or chat histories in the preview image of the App Switcher Need clarification on the following points: 1.Where exactly are these App Switcher preview screenshots stored on the device filesystem? 2.Can these App Switcher snapshots be accessed on a jailbroken iOS device? 3.Are these snapshots stored inside the application container or in a system-managed location outside the app sandbox? Can any Third party application or tool can access this screenshots in iOS device? 5.Is there any Apple-recommended API, entitlement, or platform-supported mechanism on iOS to prevent screenshots in iOS

Is there an API for opting out of the inner screen blur when the phone is actively folding? I want to play with using hinge angle as an interaction point in an app, but if half the visible screen blurs every time the user changes the angle, it kind of ruins the experience I'm imagining.

Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the iPhone Duo Group Labs: How should apps preserve navigation and UI state when switching between the inner and outer displays? Treat display transitions as size-class and trait changes, not a scene disconnect or app termination; your process stays alive. For more information, see Prepare your app for iPhone Duo. For state that must survive a scene disconnect/reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. Do multiple instances of the same app on iPhone Duo share UserDefaults/@AppStorage state? Multiple instances of your app's UI on iPhone Duo behave similarly to multi-window support on iPadOS. To learn more, see Leverage multiple displays and scenes on iPhone Duo. Both UserDefaults and AppStorage are app-wide, not per-window, stores. If a full-screen app on the inner display is closed, does it move to the outer display or get backgrounded? iPhone Duo honors UIRequiresFullScreen and apps adapt in place as the device opens and closes rather than backgrounding. To learn more, watch Prepare your app for iPhone Duo. How should apps preserve state — text input, scroll position, video playback, camera sessions — during hinge angle transitions? For example, when a LazyVGrid's column count changes because the device folds, does SwiftUI preserve scroll position automatically, or should you use scrollPosition(id:)? The system generally preserves text input and scroll position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. This applies even to cases like a LazyVGrid column-count change triggered by opening or closing the device — apps typically don't need to manually manage scroll position with scrollPosition(id:anchor:) for this transition. For more info, see Prepare your app for iPhone Duo. How can apps preserve what someone is doing when switching displays or folding/unfolding? Treat this as a resize/trait-change event, not app teardown — your process keeps running as size classes change. See Prepare your app for iPhone Duo to learn more. For scenes that actually disconnect and reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. How does actively playing video behave through the hinge angle animation? The system generally preserves video playback and player position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. AVKit will scale and resize the video automatically. If a user folds or unfolds the device mid-checkout, what does the system preserve automatically, and what should the app manage itself to avoid lost input or duplicate requests? When someone opens or closes an iPhone Duo, the system represents this as a size-class and trait collection change, not a scene disconnect or app teardown, so in-memory state like input fields typically persists automatically since the app’s process keeps running. For more info, see Prepare your app for iPhone Duo. How should apps handle the keyboard and text input when the device folds or unfolds while typing? As iPhone Duo folds or unfolds, the available screen geometry and framing change. Ensure your app adopts standard layout controls, containers, and size classes to handle resizability gracefully across all poses. When a text field becomes first responder, the system automatically shows the keyboard and binds its input to the text field. Because the appearance of the keyboard has the potential to obscure portions of your user interface, you should update your interface as needed to ensure that the text field being edited remains visible. Use keyboard notifications such as keyboardWillShowNotification, keyboardWillHideNotification, and keyboardWillChangeFrameNotification to detect the appearance and disappearance of the keyboard and to make necessary changes to your interface layout. To learn more, see UITextField. If someone is typing and closes iPhone Duo, does the keyboard/editing session survive the hinge transition, or does it get a new scene? When a user types and closes iPhone Duo, the active editing session and keyboard do not get a completely new scene. Instead, the app undergoes a dynamic resizing and transitions from the inner display to the compact outer display, maintaining the existing scene and application state. For more info, watch Prepare your app for iPhone Duo.

I’ve retested Sidecar after updating both my MacBook Pro to the current macOS 27 release and my iPad to the current iPadOS 27 release. When the iPad is connected through Sidecar and set to Use As → Extended Display, macOS does not offer a Rotation control for that display. Compatible conventional external displays do expose rotation options in System Settings → Displays. Physically rotating the iPad by 90° also leaves the Sidecar display in landscape orientation. This is consistently reproducible for me: Connect the iPad to the Mac using Sidecar. Select Use As → Extended Display. Open System Settings → Displays and select the iPad. Observe that no Rotation control is available. Physically rotate the iPad 90° into portrait orientation. Actual result: Sidecar remains connected and otherwise functions normally, but the iPad display remains landscape. No 90°/270° Rotation option is available, and physically rotating the iPad does not change the extended-display orientation. Expected result: An iPad used as an extended Sidecar display should be able to operate in portrait orientation, either automatically using the iPad’s orientation sensor or through 90°/270° Rotation controls in macOS Displays. I’ve filed the current issue through Feedback Assistant as FB24897273. I also previously filed the related portrait/full-screen limitation as FB22051066. Given that iPad natively supports portrait orientation, macOS already supports 90°/270° rotation for external displays, and Sidecar presents the iPad as an extended Mac display, the absence of any portrait option seems like a significant and increasingly conspicuous limitation rather than an inherent hardware constraint. This is particularly difficult to understand now that macOS/iPadOS 27 have substantially expanded Sidecar interaction. Is there any technical or platform constraint that prevents Sidecar from supporting the iPad’s native portrait orientation? If not, I hope FB24897273 can be considered for the appropriate Sidecar/display engineering team. I’m happy to provide additional reproduction details or diagnostics if useful.

Using iPad as sidecar for Mac, how to make full use of iPad keyboard? What I meant by that is, right now if I press Cmd+Tab or Cmd+Space for example, the shortcuts are intercepted by the iPad itself instead of passed to the Mac through sidecar. Can I turn off these iPad shortcuts while using sidecar somehow?

Xcode version 26.6 (17F113) MyOwnKeyboard-PAD app looks OK using simulator iPad Air 11-inch(M4). It automatically reformats to all orientations using only left and right landscape selected in General, Deployment Info. The submitted app 1.9 (4) had the portrait checked which was an error. I tried to update to version to 1.10 without portrait and upside down, but Validation states it must have all orientations needed. I tried setting all orientations and the simulator cuts off the sides. I am using a new mini M4 with Tahoe 26.6.2 Converted from an older developer mini using Migration Assistant. After conversion Xcode could not find xcspace files and apps locked up. I had to create new apps with different bundles which got conflicted in AppConnects causing rejects. When new versions are submitted, old versions cannot be removed because of submission states. Causing similar binaries, design and scam. I got trapped in the process! I have replied to AppConnect ref. binaries, design and scam. I hope someone can straighten this mess out. The good new is the free MyOwnKeyboard-PHONE analytics look OK with 4,000 impressions and 38 downloads and 172 product page reviews. It's a start! Thank you. Charlie Coupe Designer/Coder 2026sep16

Hello, I have updated to macOS 27 golden gate 2 days ago, and I have a concern about it. Mission Control currently keeps lagging and crashing when opening it, or when clicking on another desktop. It takes a bit to move desktops, highlight the desktop the cursor is on, and the "x" to close a desktop takes a while to show. Anyone facing the same issue? Please fix this, as Mission Control isn't like a feature, but a main thing in macOS. Sincerely, Alyaman

On the iPad, present a non-full-screen VC with a tableview inside. The TableviewCell contains a UISwitch. However, when the bottom is scrolled to where only half of the switch is visible, clicking the switch will cause the liquid glass animation effect to appear in the invisible area of the bottom view

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!