On the iPhone Duo, default toolbar items are 48 pt instead of 44 pt, even when the navigation bar is horizontal. There doesn't seem to be a public API to query this size, making it difficult to match custom toolbar items to system controls without device-specific checks. I've filed FB25271102 requesting an API to expose the default toolbar item dimensions, ideally through a SwiftUI environment value.

When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.

Description: The time scale values on the battery usage curve in macOS 27 are displayed incorrectly. The screenshot timestamp is 14:39:11, October 20. Under the "Last 24 Hours" tab for Battery Level and Screen On Time charts, the timeline shows usage extending past 21:00 on October 20. This timestamp does not match the actual current time. It appears the timeline axis failed to shift correctly as time progresses. For comparison: a reference screenshot captured on macOS 26 at 09:30, August 8. Its battery usage timeline rendered correctly. The bottom time span covered August 7 to August 8, which is the expected and proper display behavior. This bug only exists in macOS 27’s battery usage chart. The older macOS 26 implementation works correctly. Device: MacBook Air M5 macOS version: macOS 27.2 RC

Is there a public iPadOS API (or entitlement) that lets a third-party app present a transparent, interactive drawing layer over another foreground app? What I want: App A (Safari, a video app, etc.) stays in the foreground and remains visible. My app draws Apple Pencil ink on a transparent layer above that content. Pencil strokes go to my layer. I do not need to read the pixels underneath. This must be possible with public APIs only, for an App Store app. What I already checked, and why it does not match: UIWindow / windowLevel: only orders windows inside my own scene, not above another app. Slide Over, Split View, Stage Manager: a separate window beside or over the other app, not a transparent ink layer on its pixels. Picture in Picture with a custom content source: a floating window, not a full-screen transparent canvas. ReplayKit / ScreenCaptureKit: capture or broadcast, not an interactive overlay. Screen Time shields / AssistiveTouch-style overlays: system UI, not available to third-party apps. I am not asking for a review of an app concept. I am asking whether any current public API can do this, and if not, which of the options above is the supported boundary. Environment: iPadOS 26, Xcode 26, PencilKit.

It appears that hidesBottomBarWhenPushed no longer works in iOS 26 Beta 1. Is it supposed to work, is it going away or is there a alternate behavior we should be using?

Hallo everyone, We are building our app with Xcode 27 and noticed that UIDesignRequiresCompatibility still appears to be honored on iOS 26 devices. Questions: Could you confirm whether this key is still supported on iOS 26 when built with Xcode 27? If our deployment target includes iOS 26, should we keep the key for backward compatibility, or is Apple's recommendation to remove it entirely? Additionally, are there any risks associated with removing it for iOS 26 users?

Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?

I’m developing a SwiftUI iPad app that runs on an Apple silicon Mac as an iPad app—not as a Mac Catalyst app. The app supports multiple windows, with each Live Screen window associated with a different virtual machine. In the macOS Window menu, all child windows appear as “VirtualProg” rather than showing their content or VM name. The Live Screen window is created from a data-driven  WindowGroup , roughly like this: WindowGroup(id: "vm-screen", for: String.self) { $vmName in VMScreenWindow(vmName: vmName) .navigationTitle(vmName.map { "Live ($0)" } ?? "Live Screen") } I’ve tried setting the title with  .navigationTitle  both on the  WindowGroup  content and inside the window’s  NavigationStack . I also tried setting  windowScene.title  on the specific scene obtained from  view.window?.windowScene  after the view controller appeared. Neither changed the Window-menu entries. Is there a supported way to set a per-window title for the macOS Window menu when running an iPad app on Mac? Does  UIScene.title  affect that menu, or only the window title bar and app switcher? Is this a limitation of the iPad-app-on-Mac runtime, or is there a recommended SwiftUI/UIKit lifecycle hook for this? I’m looking for a public API solution rather than private AppKit/window introspection.

If the NavigationSplitView on iPadOS 26 is combined with a .inspector column, the sidebarToggle is always hidden, when the sidebar is collapsed. If you remove the .inspector modifier, the sidebarToggle stays visible throughout the collapsed or expanded state. Has maybe someone a workaround for this issue? The problem does not exist in iOS 18. The bug is reported as FB20061260

I’m using MFMailComposeViewController to send emails from my app. Since updating to iPadOS 26.4, there is no way to cancel the mail composer because the “X” button in the top-left corner has disappeared. On iPhone with iOS 26.4, everything still seems to work as expected. Is this a known issue, or am I missing something? Has anyone else experienced this, or found a workaround?

项目设置了iPad只能竖屏，在iPadMini（6th） ios27.01, xcode27.1下，在iPad横屏情况下点击APP，项目设置的竖屏无效果

The Duo simulator boots showing only the outer display: the window is fixed at 382×644 pt and our layout classifier always reports the compact stack mode. We measured this on two separate clean boots (shutdown, erase, boot). xcrun simctl help lists no subcommand for folding, posture, or selecting the inner display — we read the full list. xcrun simctl io screenshot does reveal a second display (LCD-1, 2007×2853 px, aspect 0.70, close to the 669×951 inner portrait size). Unfolding manually in the Simulator UI works and the app then renders the two-column layout correctly, but we could not find a programmatic equivalent. Is there a supported way to unfold a Duo simulator from the command line or from XCTest?

We are investigating a Mac App Store version of an app that provides tap-to-click and two-finger dragging for Magic Mouse. We need contact identity, finger positions, touch-down/up, and simultaneous contact count while the pointer is over other apps. We want a supported public API and normal App Sandbox entitlements. We are not asking how to use a private framework or bypass the sandbox. Environment tested: macOS 27.0.1 (26A434), Apple Silicon arm64, Bluetooth Magic Mouse vendor 0x004c / product 0x0269. Both IOHIDManager/IOHIDDevice and CoreHID are tested in a standalone sandboxed diagnostic app, signed with a persistent local certificate. Sandbox is confirmed via SecTask, Input Monitoring granted via System Settings and confirmed by IOHIDCheckAccess. Entitlements: app-sandbox, device.usb, device.bluetooth. No temporary exceptions, no seizeDevice, no SetReport or device reconfiguration. The normal app was still running during capture; we can repeat with it stopped if necessary. We discover four mouse interfaces, primary usage pairs FF00/03, FF00/12, FF00/0B, and 01/02. All open successfully after Input Monitoring is granted. The latter descriptor includes a 0D/05 Touch Pad collection but only vendor-defined payload for that collection. Standard individual contact fields are not declared. Input report IDs 0x3f and 0x44 are declared in addition to mouse report 0x12. Two 60-second captures, one per API, include user-performed phases for hands off, one finger, two fingers, moving each finger independently, scrolling, and physical movement/click. IOHID received 1310 input reports; CoreHID received 2349. Every report was ID 0x12, 8 bytes. Element updates were exclusively Generic Desktop X/Y, without individual contact identity or finger coordinates. Neither 0x3f nor 0x44 was delivered. The diagnostic client only reads mouse interfaces and does not read keyboard input. Questions: Is there a supported public API to observe global individual Magic Mouse contacts in an App Sandbox app, including when another app is active? Is individual-contact data expected to be available through IOHIDDevice input reports or CoreHID for this device? If so, what documented setup and entitlements are required? Are the declared vendor-defined reports 0x3f/0x44 intended for third-party clients, and is their payload documented for this purpose? If there is no supported public route, should this functionality remain outside the Mac App Store, or is there a supported capability path we should investigate? The diagnostic source is independent of the production app. Please advise whether further captures with all other input utilities stopped would help distinguish a driver/client interaction from an unsupported use case. No logs or source attachments are included in this public post.

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

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.

If i'm going to implement a custom vertical bar – how do i arrange for that? Any good doc / instruction?

I have a SwiftData @Model class that has a var of Media. enum Media: String, CaseIterable, Identifiable, Codable { case dvd = "DVD" case bluray = "Blu-ray" case bluray4k = "Blu-ray 4k" var id:String { self.rawValue } } In one of my views, I'm trying to show a Picker with the enum values, and then bind the @Model's field to the Picker's selection. I've been trying all kinds of things from suggesting I'm finding online. Here's a poorly pasted version of what my last attempt looks like (I'm sure I have the wrong number of closing curly brackets, but just ignore that): struct DetailView: View { @Binding var item:Item; // The @Model class. @State private var selectedMedia:Media = .dvd; var body:some View { Picker("Media", selection:$selectedMedia) { ForEach(Media.allCases, id:\.self) { media in Text(media.rawValue); } } .labelsHidden() .onAppear() { selectedMedia = item.media; } .onChange(of:selectedMedia) { oldValue, newValue in item.media = selectedMedia; } } } What's a good way to make this work? Am I going to have to use a custom formatter of some type, bind the Picker to a string, and convert the selected value with the formatter?

Hi! We're trying to investigate the following crash, but have a little bit hard time of understanding what the reason for it might be. I assume this might be us trying to reduce the state too often? Thread 0 Crashed: 0 libswiftCore.dylib 0x00000001884fec20 _swift_release_dealloc + 48 (:-1) 1 libswiftCore.dylib 0x00000001884fd938 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 240 (:-1) 2 SwiftUICore 0x000000018ed7f940 specialized _ArrayBuffer._consumeAndCreateNew(bufferIsUnique:minimumCapacity:growForAppend:) + 244 (:-1) 3 SwiftUICore 0x000000018ed7ecdc specialized Array._createNewBuffer(bufferIsUnique:minimumCapacity:growForAppend:) + 16 (:-1) 4 SwiftUICore 0x000000018ed7ecdc specialized Array._reserveCapacityAssumingUniqueBuffer(oldCount:) + 24 (:-1) 5 SwiftUICore 0x000000018ed7ecdc specialized Array.append(_:) + 56 (:-1) 6 SwiftUICore 0x000000018ed7ecdc NSAttributedString.MetricsCache.metrics(requestedSize:layoutMargins:wantsNumberOfLineFragments:context:) + 2996 (:-1) 7 SwiftUICore 0x000000018eda7afc ResolvedStyledText.StringDrawing.draw(in:with:applyingMarginOffsets:containsResolvable:context:renderer:) + 208 (:-1) 8 SwiftUICore 0x000000018ee5fe90 ResolvedStyledText.draw(in:with:applyingMarginOffsets:context:renderer:) + 100 (:-1) 9 SwiftUICore 0x000000018ee5fe90 closure #1 in DisplayList.ViewUpdater.Platform.updateItemView(_:index:item:state:) + 176 (:-1) 10 SwiftUICore 0x000000018ee5f7a0 closure #1 in PlatformDrawableContent.draw(in:size:contentsScale:state:) + 20 (:-1) 11 SwiftUICore 0x000000018ee5f7a0 CGContextRef.withPlatformContext(do:) + 56 (:-1) 12 SwiftUICore 0x000000018ee5f7a0 PlatformDrawableContent.draw(in:size:contentsScale:state:) + 136 (:-1) 13 SwiftUICore 0x000000018ee5fd94 CGDrawingLayer.draw(in:) + 88 (:-1) 14 SwiftUICore 0x000000018ee5fd94 @objc CGDrawingLayer.draw(in:) + 224 (:-1) 15 QuartzCore 0x000000018ad2304c CABackingStoreUpdate_ + 344 (:-1) 16 QuartzCore 0x000000018ad22df0 invocation function for block in CA::Layer::display_() + 72 (:-1) 17 QuartzCore 0x000000018ad257c4 CA::Layer::display_() + 2180 (:-1) 18 QuartzCore 0x000000018ad257c4 -[CALayer _display] + 2312 (:-1) 19 QuartzCore 0x000000018ac5d0f4 CA::Layer::display_if_needed(CA::Transaction*) + 256 (:-1) 20 QuartzCore 0x000000018ac5d0f4 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 732 (:-1) 21 QuartzCore 0x000000018ac593c8 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 568 (:-1) 22 QuartzCore 0x000000018ac587c0 CA::Transaction::commit() + 428 (:-1) 23 QuartzCore 0x000000018ac59018 CA::Transaction::flush() + 84 (:-1) 24 QuartzCore 0x000000018ac585c0 CA::Transaction::flush_as_runloop_observer(bool) + 224 (:-1) 25 UIKitCore 0x000000018b111800 _UIApplicationFlushCATransaction + 52 (:-1) 26 UIKitCore 0x000000018b110e74 performCATransactionCommitAction + 308 (:-1) 27 UIKitCore 0x000000018b110e74 __setupUpdateSequence_block_invoke_2 + 336 (:-1) 28 UIKitCore 0x000000018b117b88 _UIUpdateSequenceRunNext + 128 (:-1) 29 UIKitCore 0x000000018b117928 schedulerStepScheduledMainSectionContinue + 48 (:-1) 30 UpdateCycle 0x00000002b9c47bc0 UC::DriverCore::continueProcessing() + 84 (:-1) 31 CoreFoundation 0x0000000186ea8c20 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (:-1) 32 CoreFoundation 0x0000000186ea8b94 __CFRunLoopDoSource0 + 192 (:-1) 33 CoreFoundation 0x0000000186e8a268 __CFRunLoopDoSources0 + 316 (:-1) 34 CoreFoundation 0x0000000186e89384 __CFRunLoopRun + 416 (:-1) 35 CoreFoundation 0x0000000186e8a7f4 _CFRunLoopRunSpecificWithOptions + 344 (:-1) 36 GraphicsServices 0x000000023154cf24 GSEventRunModal + 120 (:-1) 37 UIKitCore 0x000000018b1681cc UIApplicationMain + 336 (:-1) 38 UIKitCore 0x000000018b403644 UIApplicationMain(_:_:_:_:) + 104 (:-1) 39 MyApp 0x00000001021d9c08 main + 116 (/<compiler-generated>:10) 40 MyApp 0x00000001021d9c08 0x1021d4000 + 23560 (AppDelegate.swift:0) 41 dyld 0x0000000186cdb5b8 start + 6616 (:-1) Attaching one of the crashes, but I do have an access to xcrashpoint file as well. Crash: 2026-10-13_00-35-13.8383_-0400-3db78b940c1a263bd5595645b082edf503063be8.crash It seems to happen on the following version of iOS: 18.7.8 26.5 26.6.2 26.7.1 27.0 27.0.1 Would appreciate any tips!

OK, I'm going to try SwiftUI one more time. Every other time I've tried it I've run into major blockages that prevented it from being usable. So far I've code up this basic design (see screenshot at end). It's a common thing: Filters in the left sidebar, filtered assets in the center list (ignore the temp IDs for debugging purposes), and a detail view of the selected asset on the right. I have no part of the filters figured out yet, so I wouldn't mind getting advice of how to use that to filter the SwiftData. It's currently just using the common @Query to get all the items into a var of the main ContentView. As for the asset list and detail view, my current layout works, but the detail only shows for the first item clicked. Rather than show my SwiftUI code, it might be best to just ask for expert opinions about what is the right way to achieve this design. I want it to run on macOS and iOS. The details field all need to be editable. I'm currently doing this by declaring a struct as such: struct TitledField:View { let title:String; @Binding var value:String; var body:some View { LabeledContent("\(self.title):") { TextField(self.title, text:$value) .labelsHidden(); } } }

Hello Apple Developer Community, I’m Yashwanth Pentakota, the independent developer behind EyeFlow, a prototype exploring hands-free screen navigation using a standard device camera. EyeFlow focuses on gaze-based scrolling and dwell-based selection. The goal is to support people who have difficulty using a mouse or touchscreen. My current work includes improving calibration, reducing gaze jitter, and preventing unintended actions. I’m exploring bringing this interaction model to Apple platforms and would appreciate guidance on one architectural question: For gaze-controlled scrolling and selection within my own app, which supported Apple frameworks or APIs should I evaluate first, and what platform limitations should I account for? My current pipeline is: Camera capture → face/eye detection → gaze estimation → calibration and smoothing → scrolling or selection. This is an experimental prototype; I’m still evaluating its accuracy and usability. Prototype/source: https://github.com/Yashwanth6121/Eye-Flow-v3. Suggestions on relevant documentation or sample projects would be helpful. Thank you, Yashwanth Pentakota