In macOS 27 developer beta 5, search fields in toolbars (NSSearchToolbarItem instances) have their placeholder text, search strings, and magnifying glass icons vertically off-center. I reported this as FB24286690. You can see this in the Feedback Assistant app. The “Search” placeholder text, the magnifying glass, and the search string are all closer to the top of the toolbar item than the bottom. My feedback has a sample project demonstrating this, along with screenshots. I have a more detailed writeup at: https://www.virtualsanity.com/202608/vertically-off-center-components-in-nssearchtoolbaritem-in-macos-27-developer-beta-5/

It compiles for iOS but seems to be a no-op. Is this coming in a future beta? Or is there a way to hide the default back button when using the presentation + zoom navigationTransition APIs? I have a view that needs to show a confirmation on dismissal. I was previously doing this manually using a custom toolbar button + confirmationDialog modifier. But in iOS 27 I don't seem to be able to hide the navigation back button since I added the zoom navigationTransition API. This allows the user to tap the back button and lose changes. Not a great UX.

I'm seeing two related UI issues when presenting MFMailComposeViewController from SwiftUI using .sheet. The Cancel button disappears During the sheet presentation animation, the Cancel button is visible in the navigation bar. However, once the presentation animation completes, the Cancel button disappears. This is particularly problematic when the mail composer is presented full-screen: since the Cancel button is removed, there is no longer any way for the user to cancel composing the email and dismiss MFMailComposeViewController. The navigation bar changes abruptly when the presentation animation finishes The navigation bar has one appearance while the sheet is being presented, including the Cancel button and the layout/styling of its navigation items. As soon as the presentation animation finishes, the navigation bar abruptly changes to a different appearance. This causes a noticeable flicker/jump at the end of the animation. In other words, the appearance of MFMailComposeViewController during the sheet transition does not match its final appearance after the transition completes. The sample code below reproduces the issue. Steps to reproduce: Run the sample on an iPad Pro 13-inch (M5) running iPadOS 26.5. Present MFMailComposeViewController using the provided SwiftUI .sheet. Observe the navigation bar during the presentation animation. When the animation completes, observe that the navigation bar changes abruptly and the Cancel button disappears. Is this a known issue with MFMailComposeViewController when presented from SwiftUI using .sheet? struct ContentView: View { @State private var isMailComposerPresented = false var body: some View { VStack { Button("Send") { isMailComposerPresented = true } .buttonStyle(.borderedProminent) } .sheet(isPresented: $isMailComposerPresented) { MailComposerView() } } } struct MailComposerView: UIViewControllerRepresentable { @Environment(\.dismiss) private var dismiss func makeUIViewController(context: Context) -> MFMailComposeViewController { let composer = MFMailComposeViewController() composer.mailComposeDelegate = context.coordinator return composer } func updateUIViewController(_ uiViewController: MFMailComposeViewController, context: Context) {} func makeCoordinator() -> Coordinator { Coordinator(dismiss: dismiss) } final class Coordinator: NSObject, MFMailComposeViewControllerDelegate { private let dismiss: DismissAction init(dismiss: DismissAction) { self.dismiss = dismiss } func mailComposeController( _ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error? ) { dismiss() } }}

It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.

In my apps, I have a requirement to display an image of the application icon is certain circumstances. This is fairly straightforward for iOS/iPadOS and it used to be straightforward for macCatalyst. For MacCatalyst, this is no longer true (at least since macOS 26). This is because the app icon is now stored as an .icns file and (in the case of using an IconComposer icon), the `'png' in the Asset Catalog now has an unknown name. So the following code no longer works: public extension Bundle { var icon: UIImage? { #if targetEnvironment(macCatalyst) guard let iconName = infoDictionary?["CFBundleIconName"] as? String else { return nil } return UIImage(named: iconName, in: self, compatibleWith: nil) #else guard let icons = infoDictionary?["CFBundleIcons"] as? [String : Any] else { return nil } guard let primaryIcon = icons["CFBundlePrimaryIcon"] as? [String : Any] else { return nil } guard let iconFiles = primaryIcon["CFBundleIconFiles"] as? [String] else { return nil } guard let file = iconFiles.last else { return nil } return UIImage(named: file, in: self, compatibleWith: nil) #endif } The obvious solution is to place an Image in the Asset Catalog which I can access, but this is a maintenance headache. What I would actually like to do is either create a UIImage directly from the .icns file, or access the .png file in the Asset Catalog (which has a name beginning with the icon file name, but has additional characters in its name that I don't know). Can you help?

Hello everyone, I have a question regarding the Place Card API I'm using .mapFeatureSelectionAccessory(.automatic) to get information about a POI on the Map The trouble I have is that it forces me to use Apple Maps for directions, which isn't ideal for my use case For example, I support commercial navigation, including large units such as trucks, and I have my own routing engine for this Is there a way to handle the directions via my routing engine instead? Is there a modifier I'm missing, or should I suggest this as an enhancement? Thanks, great work MapKit team

I am seeing a weird crash from Xcode 27 Beta 3 when building a variadic type DynamicProperty that also needs SwiftUI.State. This does not crash from Xcode 26. Here is a repro: import SwiftUI struct Repeater<each Input>: DynamicProperty { @State private var storage = Storage() private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } } extension Repeater { final class Storage { } } @main struct CrashDemoApp: App { private var repeater = Repeater(1) var body: some Scene { WindowGroup { EmptyView() } } } Here is the crash: Thread 1 Queue : com.apple.main-thread (serial) #0 0x000000019a93aec0 in swift::TargetMetadata<swift::InProcess>::isCanonicalStaticallySpecializedGenericMetadata () #1 0x000000019a946b38 in performOnMetadataCache<swift::MetadataResponse, swift_checkMetadataState::CheckStateCallbacks> () #2 0x000000019a8c85f0 in swift_checkMetadataState () #3 0x00000001004a2c78 in type metadata completion function for Repeater () #4 0x000000019a94cfe4 in swift::GenericCacheEntry::tryInitialize () #5 0x000000019a94c870 in swift::MetadataCacheEntryBase<swift::GenericCacheEntry, void const*>::doInitialization () #6 0x000000019a94f820 in swift::LockingConcurrentMap<swift::GenericCacheEntry, swift::LockingConcurrentMapStorage<swift::GenericCacheEntry, (unsigned short)14>>::getOrInsert<swift::MetadataCacheKey, swift::MetadataRequest&, swift::TargetTypeContextDescriptor<swift::InProcess> const*&, void const* const*&> () #7 0x000000019a93c714 in _swift_getGenericMetadata () #8 0x00000001004a4190 in __swift_instantiateGenericMetadata () #9 0x00000001004a2a5c in type metadata accessor for Repeater () #10 0x00000001004a5094 in type metadata accessor for Repeater<Pack{Int}> () #11 0x00000001004a4fcc in type metadata completion function for CrashDemoApp () #12 0x000000019a9543bc in swift::MetadataCacheEntryBase<(anonymous namespace)::SingletonMetadataCacheEntry, int>::doInitialization () #13 0x000000019a8d2ae0 in swift_getSingletonMetadata () #14 0x00000001004a479c in type metadata accessor for CrashDemoApp () #15 0x00000001004a473c in static CrashDemoApp.$main() () #16 0x00000001004a4a34 in main () #17 0x0000000186e47e00 in start () Here is a repo to demo: https://github.com/vanvoorden/2026-07-17 Please let me know if you have any ideas about that. Thanks!

Hello， We’re seeing an iPad-specific Launch Screen issue related to multitasking window sizes. Environment Device: iPad (iPadOS 26) Device orientation: Landscape App is launched in a small window where the app window is portrait-shaped (width < height) Issue When the iPad is in landscape but the app is launched as a portrait-shaped small window, the LaunchScreen.storyboard appears to be rendered/layouted as landscape, not matching the actual window geometry. As a result, the Launch Screen content is clipped / partially missing (we see blank/empty area at the bottom during launch). After the app finishes launching, our first view controller uses the correct window size and the UI looks fine — the problem is mainly during the Launch Screen phase. What we checked LaunchScreen.storyboard uses Auto Layout and is expected to adapt to screen/window size. This only reproduces when the device orientation and the app window aspect ratio don’t match (landscape device + portrait-shaped app window, or vice versa). When device orientation and window shape are aligned, the Launch Screen displays correctly. Question Is it expected that iPadOS renders LaunchScreen.storyboard based on the interface orientation / size class rather than the actual window bounds in multitasking scenarios? If not expected, what is the recommended way to ensure the Launch Screen matches the app’s actual window size/aspect ratio at launch (without using code, since Launch Screen is static)? Are there any additional diagnostics or recommended steps to help us investigate and confirm the root cause (e.g., specific logs, APIs/values to capture at launch such as UIWindowScene bounds, interfaceOrientation, size classes, or any guidance on how Launch Screen snapshots are chosen/cached in multitasking)? Thank you.

macOS 27 developer beta 5 introduces a bug where an NSTrackingSeparatorToolbarItem in a toolbar causes a bar to appear under the toolbar, overlaying the content. I have a blog post about this at: https://www.virtualsanity.com/202608/nstrackingseparatortoolbaritem-causes-white-bar-over-top-of-content-in-macos-27-developer-beta-5/ I reported this as FB24266969. A sample project and a screenshot are included in both the blog post and the feedback report.

Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.

Any view that is content for the tabViewBottomAccessory API fails to retain its state as of the last couple of 26.1 betas (and RC). The loss of state happens (at least) when the currently selected tab is switched (filed as FB20901325). Here's code to reproduce the issue: struct ContentView: View { @State private var selectedTab = TabSelection.one enum TabSelection: Hashable { case one, two } var body: some View { TabView(selection: $selectedTab) { Tab("One", systemImage: "1.circle", value: .one) { BugExplanationView() } Tab("Two", systemImage: "2.circle", value: .two) { BugExplanationView() } } .tabViewBottomAccessory { AccessoryView() } } } struct AccessoryView: View { @State private var counter = 0 // This guy's state gets lost (as of iOS 26.1) var body: some View { Stepper("Counter: \(counter)", value: $counter) .padding(.horizontal) } } struct BugExplanationView: View { var body: some View { ScrollView { VStack(alignment: .leading, spacing: 16) { Text("(1) Manipulate the counter state") Text("(2) Then switch tabs") Text("BUG: The counter state gets unexpectedly reset!") } .multilineTextAlignment(.leading) } } }

We are experiencing issues during extended automated test executions on iOS devices. During long-duration test runs that involve a high volume of interactions with the device under test, the socket connection is unexpectedly terminated. When this occurs, the automation session is disrupted and the test run fails. We would like to better understand the root cause of this behavior and determine whether it is related to the automation framework, the underlying iOS platform, or another system-level constraint. We have the following questions: Are there any iOS security mechanisms or system protections that may be triggered after a high number of automated interactions, resulting in the termination of an active socket connection? Does iOS impose any runtime limitations, session timeouts, resource restrictions, or inactivity thresholds that could impact long-running automation sessions? Are there any known conditions under which iOS may terminate or reset socket connections during extended periods of intensive device interaction? Any guidance on troubleshooting steps, relevant system logs, or known platform limitations would be greatly appreciated.

Hi everyone, We're experiencing a bug on iOS 26 that only occurs when the user has Reduce Transparency enabled in Accessibility settings. App structure: Our app uses a TabView with a standard tab bar. Inside each tab, we use a NavigationStack. The tab bar is visible on root-level screens, and hidden on all pushed destinations using: .toolbar(.hidden, for: .tabBar) The problem: On iOS 26 with Reduce Transparency off (Liquid Glass active) — everything works correctly. The tab bar hides as expected. On iOS 26 with Reduce Transparency on — a white bar appears at the bottom of the screen in every place where the tab bar is hidden. This white bar: Overlaps content at the bottom of the screen. Blocks scroll, tap, and all user interactions in that area. We also tried: .toolbarBackground(.hidden, for: .tabBar) Removing all custom UITabBarAppearance configuration The only workaround we found is setting UIDesignRequiresCompatibility = YES in Info.plist, which reverts the entire app to the pre-iOS 26 design — not a viable long-term solution. What can we do? Thanks in advance.

I’m seeing a layout regression in SwiftUI on iPadOS 26.4 involving NavigationSplitView inside a TabView. When a NavigationSplitView is embedded in a TabView, the sidebar toolbar appears to reserve too much vertical space. There is a large vertical gap between the top edge of the sidebar and the sidebar collapse/toggle icon. It looks as if the sidebar toolbar itself has become much taller than expected. The same NavigationSplitView layout is rendered correctly when it is shown directly without being embedded in a TabView. Environment: iPadOS 26.4 or later SwiftUI iPad TabView NavigationSplitView inside one tab Expected behavior The sidebar toolbar should use its normal height, as it does when the same NavigationSplitView is shown without a surrounding TabView. The sidebar collapse/toggle icon should appear close to the top of the sidebar, without a large empty gap above it. Actual behavior When the NavigationSplitView is hosted inside a TabView, the sidebar toolbar area becomes excessively tall. A large empty space appears above the sidebar collapse/toggle icon. This only happens in the TabView setup. Rendering the same NavigationSplitView directly does not show the issue. Feedback I also filed this as Feedback Assistant report: FB22645938 Has anyone else seen this behavior since iPadOS 26.4? Is this an intentional layout change, or is there a supported way to avoid this additional top inset when using NavigationSplitView inside TabView? Reproduction import SwiftUI struct ContentView: View { enum AppTab { case first case second } @State private var selectedTab: AppTab = .first var body: some View { TabView(selection: $selectedTab) { Tab("First", systemImage: "sidebar.leading", value: .first) { NavigationSplitView { List { Section("Sidebar Content") { ForEach(1...20, id: \.self) { index in Text("Item \(index)") } } } .navigationTitle("Sidebar") .toolbar { ToolbarItem(placement: .topBarLeading) { Button { // action } label: { Image(systemName: "plus") } } } } detail: { Text("Detail") } } Tab("Second", systemImage: "doc", value: .second) { Text("Second tab") } } } }

I need to display verse so that if a line exceeds the right margin, it is continued on the next line but indented. In UIKit this is easy by using NSParagraphStyle and headIndent and firstLineHeadIndent. But none of this is available on SwiftUI on the Apple Watch, which marks a big step back compared to WatchKit. Is there any way to display text indented in this way? I attach two screenshots, one with the indentation and one without. The one with indentation is far more readable!

Did VisionOS get the LazyVGrid Performance Updates that other platforms received? I’m observing that a LazyVGrid that works well on iPhone, iPad, and Mac appears to hitch and jitter as cells exit and renter the lazyVGrid on VisionOS. It really feels like it did not get the same behavior changes as the other platforms. I observe the scrollbar expands as cells leave the top of the grid, and each “exit” of a row seems to cause a hitch. I’ve got rigidly defined cell frames, rigidly defined columns. I don’t think any cells frames are being invalidated during scroll… (there’s no way to check this with instruments, right?) I‘ve made several analysis passes myself and threw the Xcode Agent with Codex at it just to scan for stuff, but it’s starting to just guess at things. Any known issues with VisionOS?

I’ve hit a strange SwiftUI preview crash that happens on macOS previews when using a view inside a List’s ForEach, resulting in the error Fatal Error in TableViewListCore_Mac2.swift. Only crashes macOS preview - iPhone/iPad preview doesn't crash. Doesn't crash when actually running the app. Here’s a minimal reproducible example, causing the preview to crash. XCode: Version 26.0.1 (17A400) MacOS: 26.0.1 (25A362) import SwiftUI struct Item: Identifiable { let id = UUID() let name: String } struct ItemRow: View { let item: Item var body: some View { HStack { Button(action: {}) { Image(systemName: "play") } Text(item.name) Spacer() ProgressView() } } } struct ContentView: View { @State private var items = [ Item(name: "Item A"), Item(name: "Item B"), ] var body: some View { List { ForEach(items) { item in ItemRow(item: item) } } } } #Preview("Content view") { ContentView() } #Preview("Item row") { ItemRow(item: Item(name: "Item A")) } If I wrap the row in a container, like this: ForEach(items) { item in ZStack { ItemRow(item: item) } } the crash seems to disappear. Has anyone else seen this behavior? What might I be doing wrong? Any ideas about what could be causing this?

Hello, I found a difference in application lifecycle behavior between iPadOS 26.5 and iPadOS 27 beta when the app is running in the foreground and the iPad top button is pressed to put the device into sleep. Test condition Device: iPad App state: app is running in foreground (active) Action: press the top button once to put the device to sleep Observed via UIApplicationDelegate lifecycle callbacks Observed behavior iPadOS 26.5 The following callbacks are called in this order: applicationWillResignActive applicationDidEnterBackground iPadOS 27 beta The following callbacks are called in this order: applicationWillResignActive applicationDidBecomeActive applicationWillResignActive applicationDidEnterBackground Expected behavior I expected the lifecycle sequence on iPadOS 27 beta to be the same as, or at least consistent with, iPadOS 26.5 when the device is put to sleep from the foreground app state. In particular, I did not expect applicationDidBecomeActive to be called during the transition to sleep/background. Question Is this changed behavior expected in iPadOS 27 beta, or could this be a bug in the beta? If this is expected, could you clarify the intended lifecycle behavior when the top button is pressed and the device transitions to sleep? Thank you.

I am trying to use an NSSearchToolbarItem using AppKit directly in Objective-C. If I perform a search and then click the cancel icon, my target/action is called while the NSSearchField still contains the search text (not yet cleared) and the delegate has not yet received the ending search invocation. In other words, it looks exactly the same as if the user had submitted the same search twice. Google's AI suggested using the controlTextDidChange method, but that was deprecated long ago. My current solution is to ignore searches that appear redundant (although they may not be, if the data being searched changes). This is on macOS 26.6.

Collapsing a NavigationSplitView sidebar from the toolbar button terminates the process in a right-to-left window — but only when the detail column's content carries a padding modifier. Remove the padding and it never crashes. Switch the window to left-to-right and it never crashes. AppKit raises an uncaught exception from -[NSWindow _postWindowNeedsUpdateConstraints] (the window is asked to update its constraints more times than it has views) while a SwiftUI NSHostingView re-invalidates its layout without ever settling. Environment: macOS 27.0 beta (26A5388g), MacBook Pro with Apple M5; Xcode 27.0 (27A5228h); Swift 6.4. Complete reproducer This is the whole app — no dependencies, no model, no table, no timer, no toolbar items of my own. @main struct PaddedDetailCrashApp: App { @State private var columns: NavigationSplitViewVisibility = .all var body: some Scene { Window(Text(verbatim: "Padded Detail"), id: "main") { NavigationSplitView(columnVisibility: $columns) { List { Text(verbatim: "Projects") Text(verbatim: "Archived") Text(verbatim: "Trash") } } detail: { Color.gray .padding(40) // <-- remove this and the crash goes with it } .environment(\.layoutDirection, .rightToLeft) } .defaultSize(width: 900, height: 600) } } Steps to reproduce: 1 - Build and run the code above, launched with the arguments that mirror the window itself: -AppleTextDirection YES -NSForceRightToLeftWritingDirection YES 2 - Click the toolbar's sidebar toggle repeatedly and quickly — roughly four clicks a second. 3 - The process terminates, in my measurements after about 8 toggles. The timing is essential. Each click has to land while the previous collapse is still animating. Clicking slowly, or scripting it so each click completes before the next begins, never reproduces it. Driving the toggle from the View menu (which changes the same state without animating) also never reproduces it.