Hi there. I was responding to some user feedback reported in this PR, that suggests UIImage 16-bit PNG exports may incorrectly handle alpha premultiplication. I put together a public repro of the issue that you can find here demonstrating the issue via a playground. Here's an LLM-generated summary of the problem: On the iOS 26.5 simulator (23F77), I’m seeing UIImage.pngData() produce darker translucent colors when exporting a 16-bit image captured with UIGraphicsImageRenderer. For a pixel drawn with UIColor(white: 0.96, alpha: 0.5), the PNG stores approximately 0.48 for its RGB samples and 0.50 for alpha. This appears to retain premultiplied colors, whereas PNG requires unpremultiplied colors. Exporting the same CGImage through ImageIO’s default PNG destination produces the expected 0.96 RGB and 0.50 alpha. An 8-bit standard-range control renders correctly through both exporters. I assume this is a framework bug, but let me know if the behavior is expected for some reason. I've also filed feedback FB25109021 regarding this behavior. Thanks in advance.

I'm seeing a camera preview rotation issue on iPadOS 27 that depends only on the SDK the app is linked against. I've filed it as FB25106148 and wanted to share it in case others hit the same problem. Sample project: https://github.com/bc-lee/avfoundation-rotation-coordinator-discrete-resizing-poc Setup Portrait-only iPad app with UIRequiresFullScreen = YES Front camera AVCaptureVideoPreviewLayer, rotated with AVCaptureDevice.RotationCoordinator, as in the AVCam sample: let coordinator = AVCaptureDevice.RotationCoordinator(device: device, previewLayer: previewLayer) // On every change of videoRotationAngleForHorizonLevelPreview: previewLayer.connection?.videoRotationAngle = coordinator.videoRotationAngleForHorizonLevelPreview iPad Pro 11-inch (4th generation), iPadOS 27.0.1, Stage Manager on, Rotation Lock off What happens after rotating the iPad from portrait to landscape Xcode 26.5 (iOS 26.5 SDK) Xcode 27.1 RC (iOS 27.1 SDK) App UI Stays upright for the user, letterboxed Stays in portrait and lies on its side with the device (discrete resizing, TN3192) videoRotationAngleForHorizonLevelPreview 180° 180° Camera preview Upright Sideways The source code and Info.plist are the same for both builds. interfaceOrientation, effectiveGeometry, window and screen bounds, and isInterfaceOrientationLocked are also identical between the two builds, so I couldn't find a public value that tells the two presentations apart. In the iOS 27 SDK build, applying videoRotationAngleRelative(toDeviceOrientation:) (new in iOS 27) for the scene's interface orientation, which gives 90°, instead of the horizon-level preview angle restores an upright preview. Questions Is videoRotationAngleForHorizonLevelPreview expected to reflect the discrete resizing presentation in iPadOS 27? Until that is resolved, is using videoRotationAngleRelative(toDeviceOrientation:) with the scene's interface orientation, only when linked against the iOS 27 SDK and running on iOS 27, a reasonable workaround? Has anyone else seen this, or found a better approach?

When attempting to use Toolbar(id: "") this crash occurs immediately upon showing the window. FAULT: NSInternalInconsistencyException: NSToolbarItemViewer's min/max size is nan. This indicates an item's size has been changed during layout which is illegal; { NSAssertFile = "NSToolbarItemViewer.m"; NSAssertLine = 942; } If I comment out the toolbars, re-run show the window once, then re-add id: the window properly displays, allows customization and does not error unless I clear data within ~/Library/Containers.

I have a floating bottom right button in my app (similar to twitter/x's blue compose button). I have no tab bar. When moving to the duo, this floating button now appears to the left of an empty tabbar/toolbar area on the right of the device. Ideally I want it to be inside the new tabbar/toolbar area when on the duo, as otherwise its wasted space. Is there anything new/inbuilt that I can leverage to manage this? Can I put my button into some container somewhere so that its the bottom right of the screen on an iPhone and automatically move to the toolbar area on duo? Something like a single item, right aligned, tabbar would be a great option. But the new liquid glass tabbar comes with too many restrictions on colors/styling I'm trying to find a way to avoid having logic like this in the app, as device specific logic becomes a maintenance issue int he future: if device == duo { // create toolbar button } else { // create button button and appen } d to window

Hello Apple Developer Community, I am developing Keyboard Atelier, a Korean custom keyboard built with Swift, UIKit, and UIInputViewController. Is there a supported way to apply a user-selected background color or image across the entire keyboard presentation, including the surrounding system-owned areas? Problem On an iPhone, we observe a strip above our keyboard extension’s visible content and a separate bottom area containing the system globe and dictation controls. When we apply a custom background to our extension, these surrounding areas retain a different background. This makes our keyboard look like a rectangular panel placed inside a separate system frame. Our product lets users customize keycaps and keyboard backgrounds. We want their selected color or image to appear continuous across the entire keyboard presentation. What we have tested We compared an opaque white root-view background with a clear root-view background in an isolated simulator test. With the opaque background, the boundaries above and below the extension were visible. Removing our own top padding did not eliminate the upper strip. Setting the root view’s backgroundColor to UIColor.clear made the backgrounds appear visually continuous in both light and dark appearances. However, this only reveals the default system background. It does not Questions Is there a public API or supported configuration that lets a custom keyboard specify the background color of the surrounding system-owned areas? Can a custom keyboard supply a background image that extends into those areas, including beneath the system globe and dictation controls? If neither is supported, what is the documented boundary of background customization for a keyboard extension? Is Feedback Assistant the appropriate place to request this capability? iOS should retain control of the system buttons, including their behavior, accessibility, touch targets, and contrast adjustments. We are asking to customize the background behind them while preserving their functionality. The solution must be suitable for App Store distribution and work when the keyboard is used in other apps, without requiring changes to those host apps. Reproduction steps Enable the custom keyboard in Settings > General > Keyboard > Keyboards. Open a UITextView in the containing app. Switch to the custom keyboard. Set the keyboard extension’s root-view background to an opaque white color while using dark appearance. Observe the different backgrounds above and below the extension’s content. Compare this with a build using UIColor.clear for the root-view background. Implementation Swift and UIKit UIInputViewController keyboard extension Test host: a UIKit UITextView in the containing app Light and dark appearances tested RequestsOpenAccess = false Please point me to any relevant API or documentation, or clarify whether this would require a new API. Thank you.

I would appreciate some feedback on this simple technical point. When a gesture is defined in code, it is simply added to the view with myFirstView.addGestureRecognizer(someGesture) That's fine. But, if by mistake, the same gesture is added later to another view myOtherView.addGestureRecognizer(someGesture) myFirstView will not receive anymore the notification. That's well known and documented, because in fact the gesture references the view and can only reference one. So my point: this may be a bit misleading, as API let one believe that the gesture is attached to the view ; hence, why not attach to a second view ? wouldn't it be better to have API where view is explicitly "attached" to gesture ? someGesture.attach(to: myFirstView) Doing so, if I later someGesture.attach(to: myOtherView) it would be clearer I am changing the attached view. I noted that when we define a gesture in IB, we can only connect from the view to the gesture, not from gesture to the view which seems to follow the same logic. A simple extension does it: extension UITapGestureRecognizer { func attach(to view: UIView) { view.addGestureRecognizer(self) } } Any thought ? PS: I'm amazed by code completion. I just typed extension UITapGestureRecognizer { func attach(to view: UIView) and it completed automatically the code with view.addGestureRecognizer(self)

I downloaded the CarPlay Simulator from Additional Tools for Xcode 27, but I can't find a way to test the navigation banners on the left or right side Several users have complained, and one of them finally sent me a photo. It looks fine in my simulator but not on their CarPlay screen How do we test those edge cases scenarios? This is my Simulator, looks fine And this is user's photo clearly showing the navigation banners in a different position

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

Before I file a bug report I wanted to verify that I'm not missing something. If I setup a view controller in a navigation controller and I add a view with a constraint that lines it up with the view controller's view's layoutMarginsGuide (leadingAnchor or trailingAnchor), in several cases the view will not line up with buttons added in the navigation bar. Under iOS 18 everything lines up as expected. To demonstrate, create a new iOS project based on Swift/Storyboard. Setup the storyboard to show a UINavigationController with one UIViewController. Then in ViewController.swift (the one embedded in the navigation controller), use the following code: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .yellow title = "Layout Margins" let leftCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.leftBarButtonItem = leftCancel let rightCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.rightBarButtonItem = rightCancel let leftView = UIView() leftView.backgroundColor = .blue leftView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(leftView) let rightView = UIView() rightView.backgroundColor = .red rightView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(rightView) NSLayoutConstraint.activate([ leftView.widthAnchor.constraint(equalToConstant: 80), leftView.heightAnchor.constraint(equalToConstant: 80), leftView.leadingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.leadingAnchor), leftView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), rightView.widthAnchor.constraint(equalToConstant: 80), rightView.heightAnchor.constraint(equalToConstant: 80), rightView.trailingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.trailingAnchor), rightView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), ]) } } This adds a "Cancel" button to both ends of the navigation bar and it adds two little square views lined up with the leading and trailing layout margins. Here's the results: iPad running iPadOS 26 beta 3 (note the misalignment). This is really jarring when trying to align another glass button below the cancel button: iPad running iPadOS 18.5 (aligned just fine): iPhone in portrait running iOS 26 beta (aligned just fine): iPhone in landscape running iOS 26 beta (no alignment at all): iPhone in portrait running iOS 18.5 (aligned just fine): iPhone in landscape running iOS 18.5 (aligned just fine): Under iOS 26 on an iPhone (simulator at least) in portrait, the cancel buttons line up with the colored squares. That's good. In landscape, the colored squares have much larger margins as expected (due to the larger safe areas caused by the notch), but the cancel buttons in the navigation bar are not using the same margins. This one is debatable. Under iOS 18 the cancel buttons use larger margins to match the larger safe area. But I can see why under iOS 26 they changed this since the navigation bar doesn't interfere with the notch. But it's inconsistent. Under iOS 26 on an iPad (simulator at least), it's wrong in any orientation. Despite the lack of any notch or need for a larger safe area, the colored squares are indented just a bit more than the buttons in the navigation bar. I see no reason for this. Under iOS 18 everything lines up as expected. My real question at this point: Is the mismatched margins on an iPad under iOS 26 between the buttons in the navigation bar and other views added to the view controller a likely bug or am I missing something?

Hello, I have a SwiftUI View sitting in the UIHosting view controller. On rotation to landscape, the system would add padding to the toolbar. I presume it's the nav bar. Anyone experienced this? What would be this space? padding? content margin?

Hello, Summary: Navigation apps that support the CarPlay Dashboard and Instrument Cluster set UIApplicationSupportsMultipleScenes = true, which allows users to open a second app window on iPhone Duo. However, the app cannot close that window, because requestSceneSessionDestruction returns "This functionality is not supported for this device idiom." We would greatly appreciate your advice on the recommended approach. Our navigation app supports CarPlay, including the Dashboard and Instrument Cluster scenes. Following the example in the CarPlay Developer Guide, our scene manifest sets UIApplicationSupportsMultipleScenes to true. On the inner display of iPhone Duo, this setting also allows users to open a second window of our app (for example, via "Open in Split View"). Since our app is designed around a single main window, we would like to allow only one UIWindowSceneSessionRoleApplication scene while keeping all CarPlay scenes working. Here is what we have found so far (tested on the iPhone Duo simulator running iOS 27.1; we have not yet tested on a physical device): In a test app with UIApplicationSupportsMultipleScenes = false, a second window cannot be opened, as expected. With true, we detect the additional window scene in scene(_:willConnectTo:options:) and display a notice instead of the app UI. However, requestSceneSessionDestruction(_:options:errorHandler:) fails with the error "This functionality is not supported for this device idiom." As a result, we are unable to close the additional window programmatically. We would be grateful if you could help us with the following questions: Is UIApplicationSupportsMultipleScenes = true required for the CarPlay Dashboard and Instrument Cluster scenes, or can these scenes connect when it is set to false? If it is required, is there a supported way to keep the CarPlay scenes while limiting the app to a single phone window? If there is no such way, could you please advise on the recommended way to handle an unwanted second window scene on iPhone Duo, given that apps cannot destroy scene sessions there? Thank you very much for your time and help.

For some reason, Carplay 18.x works fine, however in under certain situations in our app, Carplay 26.x breaks. The expected grid layout should be : However, this is what we see in some cases when we update our templates. I have not been able to isolate the cause of this issue. Has anyone ever seen this happen on their CarPlay apps and discovered the cause? The data sets fed into the templates are identical, the difference is in some of the timing and update order...

SwiftUI Button hit area extends ~16pt beyond its visual frame — expected OS behavior? Hi everyone, I’m working on a custom SwiftUI segmented control and noticed some unexpected hit-testing behavior with Button. I have a button structured roughly like this: Button { selectItem(at: index) } label: { ZStack { if selectedIndex == index { selectedBackground } SegmentCellView( tab: tab, isSelected: selectedIndex == index ) } .frame(maxWidth: .infinity) .contentShape(Rectangle()) } .accessibilityLabel(Text(tab.labelText)) The visual frame of the button has a certain height, but when testing on a real device, I can tap approximately 16pt outside the button's visible frame and the button still receives the tap. This seems to happen even though I explicitly use: .contentShape(Rectangle()) to define the tappable shape. My questions are: Is this ~16pt expansion of the interactive area expected SwiftUI/OS behavior? Is this related to Apple's minimum hit-target/accessibility guidelines being automatically applied to controls such as Button? If so, is there an official API/documentation describing this behavior? Is there a recommended way to make the Button's hit-testing area exactly match the bounds defined by .contentShape(Rectangle()), if that is actually possible? I'm particularly interested in understanding whether this is intentional system behavior or something caused by the ButtonStyle / layout hierarchy. Thanks!

We are seeing a production crash that only affects devices reporting iOS 27.0.0. Devices on 27.0.1 and later, and on iOS 26, are unaffected. The app is built with Xcode 27.0 (the same binary shape appears with the Xcode 27.1 RC toolchain), deployment target iOS 26.0. The crashing code is a plain availability-gated call: extension View { @ViewBuilder func disableNavigationBarMinimization() -> some View { if #available(iOS 27.0, *) { toolbarMinimizationBehavior(.never, for: .navigationBar) } else { self } } } Crash report excerpt (addresses and app symbols removed): crash_info_entry_0: Failed to look up symbolic reference at <addr> - offset <n> - symbol <nearest stripped symbol> in <app binary> - pointer at <addr> is likely a reference to a missing weak symbol Crashed: com.apple.main-thread 0 libsystem_kernel.dylib __pthread_kill 2 libsystem_c.dylib abort 3 libswiftCore.dylib <redacted> 9 libswiftCore.dylib swift_getTypeByMangledName + 908 10 libswiftCore.dylib swift_getTypeByMangledNameInContext2 + 248 11 <app> __swift_instantiateConcreteTypeFromMangledNameV2 12 <app> specialized closure #1 in View.disableNavigationBarMinimization() 13 <app> closure #1 in SomeView.body.getter What we established: Because the deployment target is 26.0 and the API is @available(iOS 27.0, *), the app weak-imports both the function and its opaque result type descriptor. dyld_info -imports on the binary shows: _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtF [weak-import] (from SwiftUI) _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtFQOMQ [weak-import] (from SwiftUI) The call site has to instantiate the opaque return type's metadata before calling the function. That is the frame that aborts. So when dyld binds the descriptor to null, #available(iOS 27.0, *) passes and the process still dies. The symbol is present and exported on the iOS 27.0 build we can inspect locally (24A437, via Xcode's DeviceSupport symbols), and the same code runs fine on the iOS 27.0 simulator runtime (24A434). We cannot reproduce the crash on any device we own. The SwiftUI binary in 24A437 exports both toolbarMinimizeBehavior(_:for:) / ToolbarMinimizeBehavior and toolbarMinimizationBehavior(_:for:) / ToolbarMinimizationBehavior. The iOS 27.1 SDK only declares the latter, still annotated @available(iOS 27.0, *). This looks like a rename late in the 27.0 cycle. Our working theory is that some iOS 27.0.0 builds in the field (earlier 27.0 builds, possibly the ones preinstalled on new devices) predate the rename and only contain toolbarMinimizeBehavior, so the renamed symbol is absent and the weak import resolves to null. Questions: Is the @available(iOS 27.0, *) annotation on toolbarMinimizationBehavior(_:for:) accurate for every shipped 27.0.0 build? Should it be 27.0.1 or 27.1? Is there a supported way to guard against a missing opaque type descriptor at runtime, short of raising the availability check? Feedback filed as FB25095054.

I’ve decided that to prepare my app for Duo I need to take iPhone landscape mode more seriously and use viewThatFits to cover landscape versus portrait. That works, even in the Beta Duo simulator, but the tabbar on non-Duo devices does not flip to vertical mode. Any idea how to achieve this (especially on iOS26) so that I’m prepared for the imminent Duo release?

QLPreviewController renders plain text as hyperlink in document downloaded from my ios app. xcode version 27.0, ipadOS - 26.5, ipad Air 11inch(M4). Expected behaviour - plain text should be shown as plain text only. Current Behaviour - When i download a document(excel file) with multiple tables(tabs), it shows some plain text as hyperlink, clicking on those links doesnt work. This works fine in case of single table(tab) document. When it happens The problem shows up only when all three are true: The user downloads the whole report as Excel ("Table Data"), which gives one file with many sheets. 2.The file is opened in the built-in iOS Quick Look / Files viewer. 3.At least one sheet has a real link in its header, footer or cells. It does not happen: 1.In the single table export (one sheet). Tapping the Google link shows the "Leave Files and open this link?" popup and opens the link. 2.In Microsoft Excel (Windows, Mac, iOS, web), even with the same multi-sheet file.

In Xcode 27.1 RC 1 there is a regression bug displaying incorrect accent color across the app. It worked correctly in Xcode 27.1 Beta 1. It affects borderPromintent top bar buttons and tab bars: https://x.com/kulik_wojciech/status/2107252543709692166?s=20 I already reported it as a bug: FB25074768

There's an easily reproducible SwiftUI bug on macOS where an app's UI state no longer updates/re-renders for "Designed for iPad" apps (i.e. ProcessInfo.processInfo.isiOSAppOnMac == true). The bug occurs in Xcode and also if the app is running independent of Xcode. The bug occurs when: the user Hides the app (i.e. it goes into the background) the user puts the Mac to sleep (e.g. Apple menu > Sleep) a total of ~60 seconds transpires (i.e. macOS puts the app into the "suspended state") when the app is brought back into the foreground the UI no longer updates properly The only way I have found to fix this is to manually open a new actual full app window via File > New, in which case the app works fine again in the new window. The following extremely simple code in a default Xcode project illustrates the issue: import SwiftUI @main struct staleApp: App { @State private var isBright = true var body: some Scene { WindowGroup() { ZStack { (isBright ? Color.white : Color.black).ignoresSafeArea() Button("TOGGLE") { isBright.toggle(); print("TAPPED") } } .onAppear { print("\(isBright ? "light" : "dark") view appeared") } } } } For the code above, after Hiding the app and putting the computer to sleep for 60 seconds or more, the button no longer swaps views, although the print statements still appear in the console upon tapping the button. Also, while in this buggy state, i can get the view to update to the current state (i.e. the view triggered by the last tap) by manually dragging the corner of the app window to resize the window. But after resizing, the view again does not update upon button tapping until I resize the window again. so it appears the diff engine is mucked or that the Scene or WindowGroup are no longer correctly running on the main thread I have tried rebuilding the entire view hierarchy by updating .id() on views but this approach does NOT work. I have tried many other options/hacks but have not been able to reset the 'view engine' other than opening a new window manually or by using: @Environment(.openWindow) private var openWindow openWindow could be a viable solution except there's no way to programmatically close the old window for isiOSAppOnMac (@Environment(.dismissWindow) private var dismissWindow doesn't work for iOS)

Hello, I’m reaching out after several days of investigation, as I’ve exhausted all standard troubleshooting steps and would truly appreciate guidance from Apple engineers or experienced developers. I am experiencing a persistent issue where StoreKit does not return any subscription products on any device, despite all subscriptions being fully approved and correctly configured in App Store Connect. What is happening • Auto-renewable subscriptions exist and are approved in App Store Connect • The app is installed from the production App Store (not TestFlight, not sandbox) • initConnection / StoreKit initialization succeeds • Requests for products/subscriptions return an empty result (no errors, no IDs) • In the UI, prices are shown as “Unavailable” • This behavior is 100% reproducible on every device, every Apple ID, every network Important detail This issue is not device-specific, account-specific, or environment-specific: • Tested on multiple iPhones • Tested with different Apple IDs • Tested on different networks • Same result every time — no subscriptions returned Why I believe this is not a code issue The exact same symptoms previously occurred on Google Play, where the root cause turned out to be a store-side configuration flag blocking billing visibility, not an application bug. Because: • StoreKit initializes correctly • No runtime errors occur • The issue is global across devices and users …I strongly suspect there may be an App Store Connect / StoreKit configuration, availability, storefront, agreement, or propagation-related factor that is preventing StoreKit from returning the products at runtime. Is there any known App Store Connect or StoreKit condition where: • subscriptions are approved and visible in App Store Connect • but StoreKit returns an empty result set in production? If so, I would be extremely grateful for guidance on where exactly to verify or correct this. Thank you very much for your time and support — any insight would be hugely appreciated. Kind regards, Mateusz

I’m adapting a UIKit app for iPhone Duo and noticed that UITableViewController separators extend underneath the navigation and tab bar controls when those controls move to the side. The cell content appears to respect the safe area, but the separators continue to the screen edge. When using a UITableView inside a regular UIViewController, constraining its horizontal edges to the parent’s safeAreaLayoutGuide prevents this. With UITableViewController, however, the table view is the controller’s root view. The attached screenshots show the difference: Screenshot 1: Separators extend underneath the side controls. Screenshot 2: Separators stop at the safe area boundary. Should UITableViewController respect these safe area boundaries out of the box, including for separators, when system controls move to the side? Or is drawing separators underneath those controls the intended behavior? If automatic adaptation is expected, could this be a UIKit issue?