I have an NSTextView subclass that overrides mouseDown: to allow for image resizing. If a user clicks and drags on the edges of an image, I implement custom behaviour that resizes the image (and shows resizing cursors). If the user clicks anywhere else, super's implementation is called. This all works great. As of macOS 27, however, the transition to gesture recognisers instead of overriding mouseDown: means that I should probably be moving away from the above approach. NSTextView now uses the new NSTextSelectionManager to implement selection and dragging via gesture recognisers, although, according to the release notes: Existing NSTextView subclasses that override mouseDown: continue to work through a binary-compatible fallback path. (163365571) It's unclear whether this means that we therefore should still override mouseDown: for custom behaviour in NSTextView, but to me, this, along with the content of Tech Note TN3212, strongly implies that, although it will continue to work thanks to "a binary-compatible fallback", we should entirely move away from overriding mouseDown: in the future. If that is indeed the case, how do we implement custom dragging behaviour--such as for resizing images as in my example--in NSTextView? There still seems to be no way of doing it other than overriding mouseDown:. I had thought that I might be able to add an NSPanGestureRecognizer to the text view and have it fail via its delegate methods if the clicks were outside of an image's edges, but a pan gesture recogniser added to an NSTextView is entirely ignored, presumably because of the private gestures already added. Fortunately everything continues to work for now, but I would like to update my code as much as possible.

I have an NSTextView subclass that replaces the standard context menu with a custom one by building its own menu in an menuForEvent: override. The context menu that is shown depends on what is selected in the text view, so it checks the current selectedRange to determine which commands should be included. (I could do much the same via the NSTextViewDelegate method textView(_:menu:for:at:), but since my text view subclass is used in several areas, each with their own delegate, it's better to do it in menuForEvent(_:).) This has all worked fine for years, but with NSTextView's transition to gesture recognisers and NSTextSelectionManager for handling text selections in macOS 27, the timings have changed. Previously, if you Ctrl-clicked on a word so that the word is selected and the context menu appears, setSelectedRanges:affinity:stillSelecting: would be called first and then menuForEvent: would be called. On macOS 27, however, the order of events is reversed: menuForEvent: is called first, before setSelectedRanges:affinity:stillSelecting:. (If you implement NSMenuDelegate.menuNeedsUpdate:, that is also called before setSelectedRanges:....) This means that you can no longer rely on selectedRanges in menuForEvent:, because on macOS 27, selectedRanges in menuForEvent: represents the previous selection, not the selection you will actually see on screen when the menu appears. This makes building a custom context menu somewhat tricky. I suspect this is a bug and have reported it as such (FB23251873, with apologies to the engineers for the pleading tone in that report; it was at the end of a long week of getting my head around the gesture recogniser changes. :) ). But it occurs to me that there is nothing in the documentation that guarantees that selectedRanges will be accurate in menuForEvent:; it's just always worked this way. So am I missing something here? Is there a better or more reliable way of getting the range that will be affected by the contextual menu in NSTextView? (The delegate method only provides a single character index, which isn't enough information for spelling corrections and such which require a range.) My current workaround is to rebuild the context menu in setSelectedRanges:affinity:stillSelecting: if it is called between menuForEvent: and didCloseMenu:withEvent:.

Description I would like to request native reordering support for SwiftUI hierarchical views, especially OutlineGroup and List(_:children:). In iOS 27, SwiftUI introduces the new reordering APIs: .reorderable() .reorderable(collectionID:) .reorderContainer(for:move:) .reorderContainer(for:in:move:) These APIs work well for flat collections and explicit sectioned collections, but they do not appear to integrate with OutlineGroup, even though OutlineGroup is the natural SwiftUI API for tree-structured data. Currently, OutlineGroup hides the internal recursive ForEach / DisclosureGroup structure, so there is no obvious place to apply reorderable(collectionID:) at each hierarchy level. Current Working Pattern for Sections This works when each parent is represented manually as a section: struct SectionModel: Identifiable { let id: UUID var title: String var items: [Item] } struct Item: Identifiable { let id: UUID var title: String } struct ContentView: View { @State private var sections: [SectionModel] = sampleSections var body: some View { List { ForEach(sections) { section in Section(section.title) { ForEach(section.items) { item in Text(item.title) } .reorderable(collectionID: section.id) } } } .reorderContainer(for: Item.self, in: SectionModel.ID.self) { difference in apply(difference) } } private func apply(_ difference: ReorderDifference<Item.ID, SectionModel.ID>) { // Move item between explicit sections. } } But this does not scale naturally to arbitrary tree data. Desired API Ideally, this should work with OutlineGroup: struct Node: Identifiable { let id: UUID var title: String var children: [Node]? } struct ContentView: View { @State private var nodes: [Node] = sampleTree var body: some View { List { OutlineGroup(nodes, children: \.children) { node in Text(node.title) } .reorderable() } .reorderContainer(for: Node.self) { difference in apply(difference) } } private func apply(_ difference: ReorderDifference<Node.ID, ???>) { // Move node within the tree. } } For hierarchical data, SwiftUI would need to expose the parent or collection identity of the source and destination. For example, something like: .reorderableTree( children: \.children, allowsMoveIntoChildren: true ) Or an overload such as: OutlineGroup(nodes, children: \.children) { node in Text(node.title) } .reorderable(collectionID: \.parentID) With a ReorderDifference that includes: sourceParentID destinationParentID destinationPosition movedItemIDs Why This Matters Many apps represent user-created hierarchical data: folders bookmark collections nested lists project outlines document trees sidebar hierarchies OutlineGroup is the natural SwiftUI abstraction for displaying this data, but reordering currently requires either: 1abandoning OutlineGroup and rebuilding a recursive outline manually; 2flattening the hierarchy into sections, losing the real outline interaction; 3using older manual drag/drop APIs; 4falling back to UIKit/AppKit. None of these approaches feels aligned with SwiftUI's declarative model. Specific Request Please consider adding native reorder support to OutlineGroup and List(_:children:), including support for: moving items within the same parent; moving items between parents; optionally moving an item into another item as a child; preventing invalid moves, such as moving a parent into one of its descendants; exposing source and destination parent identifiers in the move callback; preserving SwiftUI's built-in disclosure UI. Minimal Example of the Current Limitation This is the kind of code I would expect to be possible: List { OutlineGroup(nodes, children: \.children) { node in Text(node.title) } .reorderable() } .reorderContainer(for: Node.self, in: Node.ID.self) { difference in moveNode(using: difference) } But because OutlineGroup creates its recursive rows internally, there is no clear way to attach reorderable(collectionID:) to each parent's child collection. Expected Outcome SwiftUI should provide a first-class way to reorder hierarchical data displayed with OutlineGroup, similar to how flat and sectioned collections can now use reorderable and reorderContainer.

Hi. macOS 26.5 introduced a bug involving menu item keyboard shortcuts without modifier keys. For example, it affects a menu item with the keyboard shortcut J, but not the keyboard shortcut ⌘J. This bug is also present in the first beta of macOS 27. When a menu item is invoked with a keyboard shortcut that has no modifiers and its validateMenuItem(_:) method returns false, the system beeps and refuses to perform the operation. This is expected. But then even after validateMenuItem(_:) is returning true again, the app will continue refusing to perform that keyboard shortcut until the app is quit and relaunched. It will also do the same with all other keyboard shortcuts that have no modifiers and are attached to menu items. I filed this with a sample project as FB22762541. I also wrote about it in more detail at: https://virtualsanity.com/202605/bug-involving-keyboard-shortcuts-for-menu-items-that-have-no-modifier-keys-on-macos-265/ I would love to see this issue addressed. Thank you for your work.

I’m building a rich Home surface around a DeviceActivityReport embedded in my host app, and I’ve hit a set of boundaries that I’d like to confirm as intended behavior rather than something I’m doing wrong. All results below are from physical devices running iOS 18 and iOS 26, since Screen Time data is not available in Simulator. What I’m trying to build I want a single scrolling page where: The host app owns some chrome, including a date picker, refresh button, and settings button. The embedded DeviceActivityReport renders the Screen Time data, including totals, a per-hour chart, and per-app usage. The host chrome can react to the report scrolling. Taps inside the report can open a full-screen sheet. Findings so far 1. Report → host App Group writes do not reach the host A UserDefaults(suiteName:) write, or a file written to the App Group container, from inside the report extension returns success. However, the host app reads nil for those keys, including for a plain string marker unrelated to Screen Time data. This appears to be a blanket block across persistence primitives. By contrast, host → report reads work fine: the host writes a value, and the report can read it in makeConfiguration or in the view body. So the channel appears to be one-way: host → report only. 2. A host UIScrollView cannot capture pan gestures that begin over the embedded report I wrapped the DeviceActivityReport in a real UIScrollView, using its own panGestureRecognizer to drive scrolling, not an added recognizer. The report content itself has no internal scrolling. The host scrolls only when the drag begins on a host-owned subview outside the report. A drag beginning over the report does not register with the host at all. No combination of delaysContentTouches, canCancelContentTouches, or direction-locking the pan changes this. This makes it look like the report’s remote view is the touch sink for its own rectangle, and host ancestor gesture recognizers never see touches that begin inside it. 3. A sheet presented from inside the report renders behind host overlays and is bounded by the report container Even when the report is presented edge-to-edge in a fullScreenCover, a .sheet presented from inside the report renders behind a host SwiftUI overlay that is a sibling above it in a ZStack. When the report is embedded inline as a sub-region, a report-presented sheet is bounded to the embed frame rather than the whole screen. Questions 1. Host-owned scrolling Is host-owned vertical scrolling over an embedded DeviceActivityReport supported in any configuration? Is there a sanctioned way to let host gesture recognizers observe or cooperate with touches over the report, or is the report’s rectangle definitively an opaque touch sink by design? 2. Report → host data flow Is the report → host one-way data boundary intended? Is there any supported channel for a report extension to send a value back to the host, other than DeviceActivityEvent thresholds via DeviceActivityMonitor? 3. Screen-sized modal presentation What is the supported way to present a screen-sized modal from a report interaction? Is hosting the report in a full-screen or pushed-navigation context the intended path? If so, are there constraints on what a report-presented modal can cover, such as host chrome or host-owned z-ordering? 4. Intended level of interactivity More broadly, how interactive is a DeviceActivityReport view intended to be? Buttons, @State mutation, DragGesture, and .sheet all work inside the report on device. Is rich interactivity, such as scrolling lists, gesture-driven paging, and in-report overlays, a supported use case? Or is the report intended primarily as a passive presentation surface? Any clarification on which of these are by design versus bugs would help me choose an architecture I can rely on. Environment DeviceActivityReport embedded in host app .individual Family Controls authorization App Group shared between host app and report extension Physical devices only iOS 18 and iOS 26

In SwiftUI for macOS, how do I configure a Picker as a segmented control to have a flexible width? This design pattern is present in Xcode 26 at the top of the sidebar and inspector panel. I can't figure out the combination of view modifiers to achieve a similar look. import SwiftUI struct ContentView: View { @State private var selection = 0 var body: some View { VStack { Picker("", selection: $selection) { Image(systemName: "doc") Image(systemName: "folder") Image(systemName: "gear") Image(systemName: "globe") .frame(maxWidth: .infinity) // Doesn't do anything. } .labelsHidden() .pickerStyle(.segmented) .frame(maxWidth: .infinity) // Doesn't affect segment sizes. Spacer() } } } I want the entire Picker to fill the width and for each segment to be of equal widths. How? In AppKit I would use AutoLayout for the flexible width and NSSegmentedControl.segmentDistribution for the segment widths. Is there a SwiftUI equivalent? macOS 26 / Xcode 26.3

I've been struggling to get consistent UI and UX behaviour of SwiftUI Views inside NSToolbarItems and was wondering if there is an official way to use them. I've now revisited this issue in macOS 27 and continue to see some idiosyncrasies. In the attached screenshot, you can see that the highlight area on mouse down between to the two buttons is different. This is the easiest example I've come up with that shows SwiftUI Views exhibiting different behaviour than AppKit Views. Two questions: Is an NSHostingView a valid and supported view type for NSToolbarItem.view? If so, are there any rules that govern how the SwiftUI view should be configured? (ex: frame, sizing options, supported SwiftUI Views, preferred "root view" types, etc?) Sample code that created the two NSToolbarItem buttons in the screenshot. macOS 27 ZY21R0CMGL (Public Beta 1) Xcode 27.0 beta Minimum Deployment target: 27.0 // Left-Top SwiftUI Button (Clipped Highlighting) let item = NSToolbarItem(itemIdentifier: itemIdentifier) let rootView = Button { } label: { Image(systemName: "sidebar.trailing") } item.view = NSHostingView(rootView: rootView) // ... snip .. // Right-Bottom AppKit Button (Correct Highlighting) let item = NSToolbarItem(itemIdentifier: itemIdentifier) item.image = NSImage(systemSymbolName: "sidebar.trailing", accessibilityDescription: nil) Both screenshots are taken on mouse down.

On iPad, a multiline TextField inside a List does not scroll when the text wraps to a new line. The caret and newly entered text can move behind the keyboard until the user scrolls manually. The same code works correctly on iPhone. struct ContentView: View { @State var text = "" var body: some View { List { Color.red.frame(width: 200, height: 500) // When the caret goes to the next line during the text input the scroll doesn't follow it. // So the new text is being overlapped by the keyboard until you scroll manually. TextField( "Run me on iPad and start entering multiline text with keyboard up", text: $text, axis: .vertical ) .lineLimit(1...) Color.red.frame(width: 200, height: 500) } } }

I read through the iOS 27 release notes and the following caught my attention: In apps built with the iOS 27.0 and iPadOS 27.0 SDKs, a TabView enforces that its selection is set to a visible tab. TabView might crash when its selection is set to a hidden or otherwise unavailable tab. (164516837) My app has a partially configurable tab bar. If the user currently has tab X selected (in the TabView) and then chooses to hide tab X (by toggling an option in my app's settings), then I guess this could cause a crash. My app already has logic in place so that if the user hides the tab that is currently the selected tab, then the currently selected tab is changed to another one that is always visible. This is handled by an .onChange view modifier (basically: on change of setting, if selected tab is now hidden, change selected tab to something else). However, I'm concerned about the potential for race conditions with this set up. For example, if the TabView re-renders before the selected tab is changed to an available tab, then this could cause a crash. My questions for Apple: Are programmatically configurable TabViews officially supported, or are you recommending against this practice? If they are, what defensive steps are recommended to avoid crashes (e.g. adding a small delay to make sure that the selected tab is changed first before removing a tab from the TabView).

Environment: iOS 26; iPad Mini/Air/Pro Problem: In a TextField, I am using a keyboard with the type .decimalPad. When I initially tap into the TextField, the "popover" keyboard (i.e. the decimalPad) shows up and focusses the TextField. However, when I click outside the TextField (to dismiss the keyboard), the TextField is still focussed (the keyboard was dismissed though). When reentering in the TextField, another keyboard (from the bottom of the screen) appears (most likely .numeric). Does anybody know how to solve this? What I already tried: I tried listening to the dismissal of the keyboard to manually set the FocusState to nil. However, the dismissal of the "popover/decimal" keyboard is not recognized as such a dismissal. I also tried to build a custom component out of that, but then I lose the TextField behavior, conflicting with HIG.

[Submitted as FB21961572] When navigating from a tile in a scrolling LazyVGrid to a child view using .navigationTransition(.zoom) and then returning, the source tile can lag behind the rest of the grid if scrolling starts immediately after returning. The lag becomes more pronounced as tile content gets more complex; in this simplified sample, it can seem subtle, but in production-style tiles (as used in both of my apps), it is clearly visible and noticeable. This may be related to another issue I recently filed: Source item disappears after swipe-back with .navigationTransition(.zoom) CONFIGURATION Platform: iOS Simulator and physical device Navigation APIs: matchedTransitionSource + navigationTransition(.zoom) Container: ScrollView + LazyVGrid Sample project: ZoomTransition (DisappearingTile).zip REPRO STEPS Create a new iOS project and replace ContentView with the code below. Run the app in sim or physical device Tap any tile in the scrolling grid to navigate to the child view. Return to the grid (back button or edge swipe). Immediately scroll the grid. Watch the tile that was just opened. EXPECTED All tiles should move together as one coherent scrolling grid, with no per-item lag or desynchronization. ACTUAL The tile that was just opened appears to trail behind neighboring tiles for a short time during immediate scrolling after returning. MINIMAL CODE SAMPLE import SwiftUI struct ContentView: View { @Namespace private var namespace private let tileCount = 40 private let columns = [GridItem(.adaptive(minimum: 110), spacing: 12)] var body: some View { NavigationStack { ScrollView { LazyVGrid(columns: columns, spacing: 12) { ForEach(0..<tileCount, id: \.self) { index in NavigationLink(value: index) { RoundedRectangle(cornerRadius: 16) .fill(color(for: index)) .frame(height: 110) .overlay(alignment: .bottomLeading) { Text("\(index + 1)") .font(.headline) .foregroundStyle(.white) .padding(10) } .matchedTransitionSource(id: index, in: namespace) } .buttonStyle(.plain) } } .padding(16) } .navigationTitle("Zoom Transition Grid") .navigationSubtitle("Open tile, go back, then scroll immediately") .navigationDestination(for: Int.self) { index in Rectangle() .fill(color(for: index)) .ignoresSafeArea() .navigationTransition(.zoom(sourceID: index, in: namespace)) } } } private func color(for index: Int) -> Color { let hue = Double(index % 20) / 20.0 return Color(hue: hue, saturation: 0.8, brightness: 0.9) } } SCREEN RECORDING

I'd like to create a Quick Look extension for a file type for which a location or region on a Map should be shown as preview. However the MapView would only show a grid without any map. From within the MapKit delegate I can see from the "Error" parameter (a server with this domain can not be found) that this seems to be a network issue. The Quick Look extension seems to have no access to the internet and therefore the MapView can not load any map data. I've then also done some other tests via URLSession, which also only fails with connection errors. I haven't seen any limitations or restrictions mentioned in the API documentation. Is this the expected behavior? Is this a bug? Or am I missing something?

We have a Mac app the allows customers to create a user account in our system. However, we have found that on the 'create account' screen, the system's password autofill is popping up for the "New Password" field. We don't want this, because they need to enter a new password, not pull one from the Passwords app. I built a test project with a basic UI and explicitly set the content type to None in the XIB. However, I can see when I put focus on the "New Password" NSSecureTextField, the system shows the passwords autofill popup. How can I explicitly suppress this on a per text field basis? (We are developing on macOS 26.3 right now with Xcode 26.3)

We have a status item which works fine on macOS 26 and earlier, which has the following properties: Supports left-click to open main UI (a popover) Supports left-click (while open) to toggle (close) the main UI Supports right-click to show "app" menu (e.g. About, Quit) Supports a drop destination to accept files and folders, which then triggers the main UI for more interaction In macOS 27: left-click seems ok if we use expanded interface session, but otherwise broken left-click while open no longer toggles (event is missing?) right click is no longer operational, to the point that it seems the Menu Bar doesn't forward the event at all. Other (Apple-provided) items work fine, and expose new context menus Dragging now triggers Mission Control, which seems wrong given the destination was in the Menu Bar (FB23018381). Are these interactions now forbidden, and are there lists or documentation of the new rules? As an additional bug, it looks like popovers don't pick up appearance changes. The child scroll view claims to be in light appearance in the View Debugger, but is clearly showing the wrong background color, this is a new (as-yet unreported) issue. One last bug: expanded interface session seems to suppress the popover's animation when shown.

Hi there, not sure anyone encountered the same situation, we rolled out our feature and we found that flag is all false for all the users in Brazil.. super weird.. anyone has any idea?

I'm trying to nail down the correct mental model for keeping a push-to-start Live Activity updatable, and want to confirm my understanding rather than design around an assumption. Flow: my server creates the activity via push-to-start, then I capture its per-activity token (Activity.pushTokenUpdates) and send it to the server for update/end pushes. I observe Activity.activityUpdates and also prime from the Activity.activities snapshot at launch and on foreground. What I'd like to understand for each app state: Foreground / backgrounded (in memory): I capture the token reliably — is that the intended guarantee? System-terminated (jettisoned for resources): does the system relaunch the app in the background to deliver the per-activity token, and is that something I can rely on? User force-quit (swiped from the App Switcher, not reopened): what should I expect here for per-activity token delivery, and what's the recommended strategy if the app stays force-quit — e.g. stale-date on the start push for graceful expiry, or any extension-based path? Essentially: across these states, what's the supported strategy to keep a push-started Live Activity correct? Tested on iOS 18 and 26. Related question from the implementation side: https://developer.apple.com/forums/thread/834934

Hi team, We are seeing a high volume of app terminations (uANRs), with most of them sharing the attached stack trace. I’d love to get your input on potential workarounds or fixes we can explore to mitigate this issue. 0 CoreFoundation -[__NSSingleObjectArrayI countByEnumeratingWithState:objects:count:] + 132 1 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 228 2 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 3 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 4 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 5 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 6 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 7 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 8 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 9 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 10 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 11 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 12 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 13 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 14 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 15 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 16 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 17 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 18 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 19 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 20 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 21 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 22 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 23 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 24 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 25 ScreenshotServices +[SSScreenshotMetadataHarvester _contentRectsForMetadata] + 216 26 ScreenshotServices +[SSScreenshotMetadataHarvester harvestScreenshotMetadataAndRespondToAction:] + 628 27 UIKitCore -[UIScreenshotMetadataRequestAction fulfillRequest] + 180 28 UIKitCore -[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion:] + 3432 29 UIKitCore -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 412 30 UIKitCore -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 31 UIKitCore -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 336 32 FrontBoardServices __76-[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke.146 (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 252 33 FrontBoardServices -[FBSScene _callOutQueue_coalesceClientSettingsUpdates:] + 68 34 FrontBoardServices -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] + 712 35 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 + 148 36 FrontBoardServices -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 37 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke.cold.1 + 252 38 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke + 184 39 libdispatch.dylib _dispatch_client_callout + 16 40 libdispatch.dylib _dispatch_block_invoke_direct + 284 41 FrontBoardServices __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 52 42 FrontBoardServices -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 240 43 FrontBoardServices -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 28 44 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in ae3c9338-0166-397a-9643-356b14f6ee58) + 28 45 CoreFoundation __CFRunLoopDoSource0 (in ae3c9338-0166-397a-9643-356b14f6ee58) + 172 46 CoreFoundation __CFRunLoopDoSources0 (in ae3c9338-0166-397a-9643-356b14f6ee58) + 332 47 CoreFoundation __CFRunLoopRun (in ae3c9338-0166-397a-9643-356b14f6ee58) + 840 48 CoreFoundation CFRunLoopRunSpecific (in ae3c9338-0166-397a-9643-356b14f6ee58) + 572 49 GraphicsServices GSEventRunModal (in d372e13f-7505-3add-ae13-062656f0b1f6) + 168 50 UIKitCore -[UIApplication _run] (in 5e794caa-4162-3ff6-861e-45f29f6b8ac0) + 816 51 UIKitCore UIApplicationMain (in 5e794caa-4162-3ff6-861e-45f29f6b8ac0) + 336

Since iOS26 the UISplitViewController is displayed in a way where the primary column (red) overlaps the secondary column (blue) instead of displaying them next to each other like before. Several Apple apps still display the columns next to each other, like Notes, Mail and Photos. What is the correct way to display the columns next to each other again using UIKit and if possible Storyboards.

It seems this method is not updated for the new "Show on all Spaces" option in system wallpaper preferences. I encounter this problem because one customer reported that every time my app sets a new wallpaper, this option is turned off. NSDictionary* options = [SHARED_WORKSPACE desktopImageOptionsForScreen:screen]; [SHARED_WORKSPACE setDesktopImageURL:imageFileURL forScreen:screen options:options error:&error]; This can be easily verified by dumping the returned dictionary - which only contains 3 keys. Is this a known bug?

On iPadOS 26 (up to beta 7), .sheet backgrounds have a dark green tint on Dark Mode and a gray tint on Light Mode. This is clearly noticeable on both the Canvas/Simulator and a physical device. Here's a sample View that shows the issue: import SwiftUI struct ContentView: View { @State private var isPresenting: Bool = false var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") Button("Show Sheet") { isPresenting.toggle() } } .sheet(isPresented: $isPresenting) { VStack { HStack { Spacer() Button("Cancel", systemImage: "xmark.circle.fill") { } .foregroundStyle(.secondary) .labelStyle(.iconOnly) .buttonStyle(.plain) .contentShape(.circle) } TabView { Tab("Tab 1", systemImage: "cart") { Text("Hello, tab 1") } Tab("Tab 2", systemImage: "cart") { Text("Hello, tab 2") } } } .scenePadding() } .padding() .preferredColorScheme(.dark) } } #Preview { ContentView() } Is this the expected behavior with the new OS? Anyone else seeing this?