I am taking the advice in https://developer.apple.com/videos/play/tech-talks/111462/ And using (in Obj C) navigationItem.additionalOverflowItems = UIDeferredMenuElement({ provider in provider(self.persistentOverflowItems()) }) This is quite fine as I already had menus on my barButtons. But the overflow menu doesn't match my color palette. It is white, and nothing else onscreen is. White = 100% on and draws the eye, whereas overflow should be the least important item on the screen. Thus, I should be able to color it. But with Glass, we can't set the bar tint and have it do anything useful. I can set the tint color of a .backItem. But I do not see a .overflowItem to set the TintColor of. I will be tempted to not use the system Overflow (as suggested in the video and there's usually an unspoken reason for so I'd like to use the system one, just not in white), and instead favor my own More button. Am I missing something or do I need to write a feedback?

Following up on a related discussion here: https://developer.apple.com/forums/thread/797298 "Using the new Liquid Glass effect in iOS 26 for widget backgrounds" I’ve also been looking at the widgetRenderingMode documentation and the “Optimizing your widget for accented rendering mode and Liquid Glass” documentation you mentioned. I understand that the widget should adapt its content based on the rendering mode, and that Liquid Glass is provided by the system when the widget is rendered in the appropriate context. What I’m still trying to understand is the behavior of the widget’s background/container itself. I tested a minimal widget on an iPhone running iOS 27, including: .containerBackground(for: .widget) { Color.clear } I also tried EmptyView(), .clear, containerBackgroundRemovable(true), and several material/glass combinations. What I found is: In Clear/Tinted Home Screen appearance, the widget becomes .accented and the system provides the expected transparent/Liquid Glass presentation. In the normal Home Screen appearance, the widget remains .fullColor (confirmed by logging @Environment(.widgetRenderingMode) directly in the widget view), but the actual Home Screen wallpaper does not show through the widget container. So I’m wondering whether this is simply expected behavior for .fullColor. Is it possible for a Home Screen widget to remain in .fullColor while its system widget container is genuinely transparent, allowing the actual Home Screen wallpaper to remain visible behind the widget? Or is transparency of the system widget container intentionally limited to the system’s Clear/Tinted (.accented) presentation? I’m asking because I’ve seen some third-party widgets that appear to provide a transparent or Liquid Glass-style widget even when the Home Screen is using its normal appearance, so I’m trying to understand whether there is a public WidgetKit/SwiftUI API or configuration that I’m missing. Thanks for any clarification.

Hi, for anyone who is working with LiveActivities and is running a beta of iOS 27, has apple made the ability for LiveActivities to be vertically larger and display more content as they appear in some of the demo images, or are these LiveActivities like the ones in the pictures above just system specific that is only available to apple.

I've run into an issue with my app that I've been able to narrow down to a small reproducer. Any time there is a task associated with the DetailView and you "pop to top", onAppear is called again and the task is re-run. Why is that? Is this a SwiftUI bug? It doesn't happen on iOS 17, only 18. import SwiftUI @Observable class Store { var shown: Bool = true } @main struct MyApp: App { @State private var store = Store() var body: some Scene { WindowGroup { if store.shown { ContentView() } else { EmptyView() } } .environment(store) } } struct ContentView: View { var body: some View { NavigationView { NavigationLink(destination: DetailView()) { Text("Go to Detail View") } } } } struct DetailView: View { @Environment(Store.self) private var store init() { print("DetailView initialized") } var body: some View { Button("Pop to top") { store.shown = false } .task { print("DetailView task executed") } .onAppear { print("DetailView appeared") } .onDisappear { print("DetailView disappeared") } } }

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?

Our app crashes when compiled with the iOS 27 beta 3 SDK and run as an iOS app on Mac, on both macOS 26 and macOS 27, as soon as a UISearchBar receives focus. The crash is due to this exception: *** Assertion failure in BOOL _screenBasedFocusUnsupported(void)(), UIScreen.m:3.725 Accessing the focus system through UIScreen is no longer supported. ( 0 CoreFoundation 0x000000018bea31c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018b91e91c objc_exception_throw + 88 2 Foundation 0x000000018e092644 -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 UIKitCore 0x00000001c5dae8ec _screenBasedFocusUnsupported + 272 4 UIKitCore 0x00000001c5dae960 -[UIScreen _preferredFocusedWindow] + 24 5 UIKitCore 0x00000001c4ea3a60 -[UIScreen _mainSceneReferenceBounds] + 200 6 UIKitCore 0x00000001c4ea3914 -[UIScreen _mainSceneBoundsForInterfaceOrientation:] + 40 7 UIKitCore 0x00000001c5708134 +[UINavigationBar defaultSizeForOrientation:] + 76 8 UIKitCore 0x00000001c6222c88 -[_UISearchPresentationController _layoutPresentationWithSize:transitionCoordinator:] + 704 9 UIKitCore 0x00000001c622296c -[_UISearchPresentationController containerViewWillLayoutSubviews] + 84 10 UIKitCore 0x00000001c549304c block_destroy_helper.13 + 25112 11 UIKitCore 0x00000001c549344c block_destroy_helper.13 + 26136 12 UIKitCore 0x00000001c4ea26a8 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1648 13 QuartzCore 0x0000000196103dbc _ZN2CA5Layer15perform_update_EPS0_P7CALayerjNS_17LayerUpdateReasonEPNS_11TransactionE + 460 14 QuartzCore 0x000000019610390c _ZN2CA5Layer17update_if_needed_EPNS_11TransactionENS_17LayerUpdateReasonE + 692 15 QuartzCore 0x0000000196035d2c _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 608 16 QuartzCore 0x0000000195e69520 _ZN2CA11Transaction6commitEv + 652 17 AppKit 0x0000000190fe116c __37+[NSDisplayCycle currentDisplayCycle]_block_invoke.7 + 44 18 CoreFoundation 0x000000018be34ad0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 19 CoreFoundation 0x000000018be34a10 __CFRunLoopDoBlocks + 396 20 CoreFoundation 0x000000018be33e54 __CFRunLoopRun + 2356 21 CoreFoundation 0x000000018bf06234 _CFRunLoopRunSpecificWithOptions + 532 22 HIToolbox 0x0000000198c1f560 RunCurrentEventLoopInMode + 320 23 HIToolbox 0x0000000198c228bc ReceiveNextEventCommon + 488 24 HIToolbox 0x0000000198dac14c _BlockUntilNextEventMatchingListInMode + 48 25 AppKit 0x00000001909163d0 _DPSBlockUntilNextEventMatchingListInMode + 228 26 AppKit 0x000000019026a084 _DPSNextEvent + 576 27 AppKit 0x0000000190dff96c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 28 AppKit 0x0000000190dff678 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72 29 AppKit 0x000000019025d13c -[NSApplication run] + 368 30 AppKit 0x00000001902357b0 NSApplicationMain + 880 31 AppKit 0x000000019047c958 +[NSWindow _savedFrameFromString:] + 0 32 UIKitMacHelper 0x00000001aa2651bc UINSApplicationMain + 972 33 UIKitCore 0x00000001c4e1aed4 UIApplicationMain + 144 34 UIKitCore 0x00000001c548bda0 block_destroy_helper.31 + 8880 35 DigitalConcertHall.debug.dylib 0x0000000106e41bd8 $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ + 128 36 DigitalConcertHall.debug.dylib 0x0000000106e41b4c $s18DigitalConcertHall11AppDelegateC5$mainyyFZ + 32 37 DigitalConcertHall.debug.dylib 0x0000000106e4afc0 __debug_main_executable_dylib_entry_point + 28 38 dyld 0x000000018b9ac4e4 start + 6992 ) I could not test with the iOS 27 beta 4 SDK due to this blocking issue: https://developer.apple.com/forums/thread/839012 However, when I tried to set up a simple sample project, I could not reproduce the issue. Does anybody know what might be causing this? I filed feedback FB24201508

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.

With the new Liquid Glass tab bar, I’m able to customize the color of the textfor the selected tab. However, the unselected tab bar items automatically use the system’s vibrancy effect, and their text color appears to be determined by the Liquid Glass appearance. I would like to manually specify the color of the unselected tab bar item text/icons as well, instead of having the system apply vibrancy. For example, I would like to have: Selected tab → custom color (e.g. blue) Unselected tabs → another custom color (e.g. gray) No automatic vibrancy/color transformation applied to the unselected items Is there a supported API or configuration in UIKit to control the foreground/text/icon color of unselected UITabBarItems when using the Liquid Glass tab bar? I’ve tried using UITabBarAppearance / UITabBarItemAppearance, but the unselected item's color still appears to be affected by the Liquid Glass/vibrancy behavior. Is there a recommended way to achieve this while retaining the Liquid Glass tab bar?

Why is the UI orientation LandscapeRight instead of the expected Portrait? Video reproduction:

How do you add custom macOS target properties in a SwiftUI Multi-platform target? I only see custom iOS target properties. I want to add keys such as BAAppGroupID, but only for macOS.

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

Hi, I would like to share an issue with UISearchBar's delegate method searchBarCancelButtonClicked on iOS 27 beta. On iOS 27 beta, when search bar is integrated into navigation bar’s items, tapping search cancel button doesn’t invoke UISearchBar’s delegate method searchBarCancelButtonClicked:. Steps to reproduce: Create UINavigationController with one UIViewController Set up searchController. Set searchController.searchBar.delegate, preferredSearchBarPlacement = .integratedButton, searchBarPlacementAllowsToolbarIntegration = false Tap the search button and type a query Tap the search cancel button Expected: On iOS 26, the searchBarCancelButtonClicked delegate method is called. Actual: On iOS 27 beta, the searchBarCancelButtonClicked delegate method is NOT called. On iOS 27 beta, if search bar is “stacked” or placed in the toolbar rather than the navigation bar, the bug does not reproduce. I’m using Xcode Version 27.0 beta 6 with latest available iOS 27 iPhone 17 Pro simulator (24A5423a). I reported the issue via Feedback Assistant with a minimal reproduction example and 2 videos comparing the behavior between iOS 26 and iOS 27 beta. Here is the report ID: FB24636315. Here is the minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } let window = UIWindow(windowScene: windowScene) window.rootViewController = UINavigationController(rootViewController: ViewController()) window.makeKeyAndVisible() self.window = window } } // ViewController.swift import UIKit final class ViewController: UITableViewController { private let allItems = (1...30).map { "Item \($0)" } private var items: [String] = [] private var cancelCount = 0 override func viewDidLoad() { super.viewDidLoad() items = allItems updateTitle() let searchController = UISearchController(searchResultsController: nil) searchController.searchBar.delegate = self navigationItem.searchController = searchController navigationItem.preferredSearchBarPlacement = .integratedButton navigationItem.searchBarPlacementAllowsToolbarIntegration = false tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell") } private func updateTitle() { title = "Cancel presses: \(cancelCount)" } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { items.count } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath) cell.contentConfiguration = { var config = cell.defaultContentConfiguration() config.text = items[indexPath.row] return config }() return cell } } extension ViewController: UISearchBarDelegate { func searchBarCancelButtonClicked(_ searchBar: UISearchBar) { print("searchBarCancelButtonClicked(_:)") cancelCount += 1 updateTitle() items = allItems tableView.reloadData() } } Thank you in advance!

I’m seeing inconsistent right-to-left behavior when using the new SwiftUI swipeActionsContainer() API with a ScrollView. The swipe-action buttons are positioned correctly according to the layout direction, but the gesture direction itself is not mirrored. Minimal reproducible example: import SwiftUI struct ContentView: View { var body: some View { ScrollView { LazyVStack { Text("Hello, World!") .padding() .frame(maxWidth: .infinity) .background(.blue.quinary) .swipeActions { Button(role: .destructive) { // Delete action } label: { Label("Delete", systemImage: "trash") } } } .padding() } .swipeActionsContainer() } } Steps to reproduce: Run the example using a left-to-right language such as English. Swipe the row from right to left. The trailing swipe actions appear correctly. Change the app language to Arabic. Swipe the row from left to right, which should reveal the trailing actions in an RTL layout. Nothing happens. Swipe from right to left instead. The actions appear, but from the correct visually mirrored edge. Expected behavior: Because the default swipe-action edge is .trailing, both the action placement and the gesture direction should follow the current layout direction: English/LTR: swipe from right to left. Arabic/RTL: swipe from left to right. Actual behavior: The action buttons visually respect the RTL layout, but the gesture recognizer still requires the LTR swipe direction. Environment: Xcode: 27.0 RC iOS: 27.0 RC Device: iPhone 17 Swift language version: Swift 6

I’m seeing a reproducible title-bar interaction issue on macOS 27 RC (26A428). This issue has been present since at least macOS 27 build 26A5416b (Developer Beta 6 / Public Beta 4) and is still reproducible on the Release Candidate, build 26A428. My System Settings → Desktop & Dock → Window title bar double-click action is configured to Fill. In several system apps with sidebars, including: Finder System Settings Reminders Feedback Assistant the right side of the title bar shows a visible rectangular region when the pointer hovers over it. The more important problem is that the middle portion of this region appears to intercept the title-bar double-click. Double-clicking there does nothing, while double-clicking very close to the top or bottom edge of the same region correctly triggers Fill. This makes the normal title-bar gesture surprisingly difficult to use because the center of the title bar is naturally where I would double-click. Interestingly, the sidebar area does not have this problem: double-clicking the top, middle, or bottom portions of the sidebar title-bar area all works normally. Feedback Assistant makes the behavior particularly easy to see because its left sidebar and rightmost pane behave normally, while the title-bar region above the middle pane exhibits the problem. Steps to reproduce: Set “Double-click a window’s title bar” to Fill in Desktop & Dock settings. Open Finder, System Settings, Reminders, or Feedback Assistant. Move the pointer over the right/content portion of the title bar until the rectangular hover region appears. Double-click around the center of that region. The Fill action does not occur. Double-click very close to the upper or lower edge of the same region. Fill works normally. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by migrated preferences, caches, login items, or third-party software. A screen recording demonstrating the exact hit-testing behavior was submitted through Feedback Assistant. Feedback: FB24462749 Is anyone else able to reproduce this? It looks as though some view or overlay in the new title-bar/toolbar area may be intercepting mouse events.

I've encountered crashes when trying to reorder items using the new reordering API. Fatal error: Unexpected identifier type. Expected UUID, got UUID To reproduce, simply run one of the 2 first tests and comment out the others: import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct Task: Identifiable { let id = UUID() var title: String } struct ContentView: View { @State private var tasks = [ Task(title: "Design Invoice"), Task(title: "Send Proposal"), Task(title: "Review Feedback"), Task(title: "Publish Update") ] @State private var showingPopover: Bool = false var body: some View { ScrollView { LazyVGrid( columns: [ GridItem(.adaptive(minimum: 100)) ] ) { ForEach(tasks) { task in // Test 1: This will crash when reordering if #available(iOS 26.0, macOS 26, *) { Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) } else { Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) } // Test 2: This will also crash Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) .popover(isPresented: $showingPopover) { Text("Popover") } // Test 3: This is ok Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) } .reorderable() } .reorderContainer(for: Task.self) { difference in tasks.apply(difference: difference) } } } } extension Array { mutating func apply<CollectionID: Hashable & Sendable>( difference: ReorderDifference<Element.ID, CollectionID> ) where Element: Identifiable, Element.ID: Sendable { // Find the source element that moved. guard let sourceIndex = firstIndex( where: { $0.id == difference.sources[0] } ) else { return } let movedElement = remove(at: sourceIndex) // Find the destination of that element. var destination: Int switch difference.destination.position { case let .before(value): guard let index = firstIndex( where: { $0.id == value } ) else { return } destination = index case .end: destination = endIndex } insert(movedElement, at: destination) } } I hope this is not just a limitation for the 27 release and is a bug that will be addressed in the next betas. Perhaps I'm just doing something wrong? In such case, thanks for pointing out what. FB23640379

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?

Since iPadOS 18, UIDocumentViewController has contained a document browser that shows a white page with rounded corners against a background of your choice, with the app name and "Create Document" buttons on the page. For instance, when you launch Pages, you see a white rounded page rectangle against a background of swirly orange, with “Choose a Template” and “Start Writing” buttons on the white page. In Numbers, there’s a green swirly background. In apps built and run on iPadOS 27, however, the white page with rounded corners is entirely missing, making the browser screen very ugly, with the “New Document” button translucent directly against whatever background is set. This can be reproduced simply by creating a new iOS "Document App" in Xcode 27 and building on iPadOS 27. I assume this is a bug, since if you turn on exception breakpoints, you see the following exception breakpoint triggered during launch: Exception = (NSException *) "[<_UIDocumentLaunchViewController 0x10732b200> valueForUndefinedKey:]: this class is not key value coding-compliant for the key _pageContainerView." I have thus reported it as FB23418746. I am curious, though, whether it is a design decision to remove the page background on iPadOS 27, or whether I am missing some sort of setting in the UIDocumentViewController’s launch options for restoring the page. (I hope it’s not intentional, as I like the page, and without it, the black app name gets lost against darker or busier backgrounds.) (I did try to include screenshots showing the issue when I first went to post this message, but doing so resulted in my IP address being blocked access to the forums for a week because of the forums’ new security measures.)

I have CarPlay Video enabled for my account and App ID. I tested both my main app and a completely new minimal iOS app with a new Bundle ID. The minimal app only contains: UIApplicationDelegate CPTemplateApplicationScene configuration CPTemplateApplicationSceneDelegate A single CPListTemplate root Results: With com.apple.developer.carplay-audio only, CarPlay launches normally. When com.apple.developer.carplay-video is added, CarPlay opens a blank screen. No CarPlay callbacks are called: application(:configurationForConnecting:options:) CPTemplateApplicationSceneDelegate.templateApplicationScene(:didConnect:) CPApplicationDelegate.didConnectCarInterfaceController The signed app and embedded provisioning profile both contain com.apple.developer.carplay-video. Does CarPlay Video require an additional runtime allowlist, specific head unit support, a different scene configuration, or another entitlement beyond com.apple.developer.carplay-video?

I encountered a severe NSColorSampler failure on macOS 27.0 (26A5425a). After invoking: NSColorSampler().show { selectedColor in // Handle selected colour } the system colour sampler became stuck. The pointer disappeared and all mouse clicks were captured across macOS. Pressing Escape did not recover it. Quitting the host application also did not restore clicking. The Apple-owned process remained active after the application exited: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/ColorSampler.xpc/Contents/MacOS/ColorSampler Sending SIGTERM to that process had no effect. Force-terminating it with SIGKILL immediately restored mouse clicking. Environment: macOS 27.0, build 26A5425a MacBook Pro Mac16,8 Apple M4 Pro SwiftUI content hosted inside a borderless AppKit window Expected behaviour: selecting a colour, pressing Escape, or terminating the host application should cancel sampling and release all captured input. Actual behaviour: ColorSampler.xpc survives the host application and continues preventing all mouse clicks system-wide. Feedback Assistant report: FB24722293 Has anyone else reproduced this with NSColorSampler, particularly from a borderless AppKit window?