That is not exactly a development issue, but more a Mac configuration (which may hide other problems ?). I use a new MacBookAir with MacOS 26. When I Airdrop from another Mac (15.7.8) the MacBookAir does not show any icon but a blank area, whilst other devices show their icons: That seems an old issue with MacBookAir: https://www.reddit.com/r/macbookair/comments/1benu4o/blank_airdrop_icon/ Beside this, Airdrop works OK. Just as if the MacBookAir icon was missing in some system file ? Has anyone a solution ? I filed a bug report FB24034384

In the past I was always able to install every major macOS version on an external drive so that I can test my apps. But now I'm unable to install macOS Tahoe 26 on an external drive. Actually, as far as I'm aware, there are not even official links to macOS 26 installers, but only instructions on how to update to macOS 26 from an existing macOS installation. So I thought I'd install macOS 15 on a separate drive and then update to macOS 26, but whenever I run the macOS 15 installer, tell it to install on the external drive, and reboot after the setup process completes, my MacBook just boots into my main macOS partition as if nothing happened. 3 months ago I somehow managed to install macOS Tahoe beta 1 on an external drive, I don't remember how (but I don't think it was anything crazy); booting into that beta 1 partition and trying to update doesn't work either, as my MacBook again boots into my main macOS partition. I already asked help about the update problem one month ago here, but nobody replied. Could someone at Apple please provide instructions on how one is supposed to install macOS 26 on an external drive (if possible before it becomes available to the public)? Are we supposed to buy a separate Mac for every macOS version that we want to test our apps on?

We have been having unexplained failures with the codesign tool recently on macosx aarch64 and x64 hosts. Every once in a while when signing an app locally using the following command: /usr/bin/codesign -s - -vvvv --force /home/me/FooBarCalculator.app results in the following error: /home/me/FooBarCalculator.app: timestamps differ by 185 seconds - check your system clock The number of seconds reported in the error message keeps varying (but usually in that range). We have checked the system clock but there isn't anything wrong (from what we can see) with the host. In fact, we have been seeing this error on several hosts now, so it isn't specific to one host. While looking into this issue, we even printed the details of an already signed binary using the following command: codesign -dvvv HelloWorld.app and that prints among other things, similar warning message: ... Timestamp=12 May 2026 at 5:36:0 AM HelloWorld.app: timestamp mismatch: internal time 12 May 2026 at 5:32:59 AM (184 seconds apart) I'm looking for inputs on how we go about debugging this issue and where/how the codesign tool sources these timestamps from (any specific API?) and what value is it comparing against to notice a difference. These affected hosts have different operating system versions some 15.x and some 26.x.

I am developing a large iOS application with an extensive UI test suite (hundreds of UI test scenarios). After upgrading our CI runners to macOS Tahoe 26, we started observing an intermittent issue where an iOS Simulator may operate normally for many successful application launches before unexpectedly entering a persistent degraded state. Once this occurs, every subsequent application launch crashes inside dyld before reaching our application’s main(). The degraded state persists until the simulator device is reset This causes UI tests to hang and eventually timeout. Business impact CI/CD jobs frequently timeout (90+ minutes per failed run) Significant loss of CI capacity Difficult to maintain reliable quality gates At our scale, this has become a serious issue affecting release confidence and overall engineering productivity. Technical details Crash report MyProject-2026-07-13-125307.ips — a crash report from a CI Demo project dyld_crash_demo — a minimal reproducible project demonstrating the relevant dyld execution path. The project intentionally returns errors from system functions along the shared cache initialization path to demonstrate that dyld continues execution until DyldSharedCache::getUUID(), where it subsequently crashes. Simply open the project and run it in iOS Simulator 26.2. Environment Component Version macOS Tahoe 26.x Xcode 26.2, 26.5 iOS Simulator 26.2, 26.5, 26.6 Architecture Apple Silicon dyld 1378 dyld_sim 1335 What we have ruled out multiple Xcode versions multiple macOS 26.x releases multiple iOS Simulator runtimes multiple simulator devices UI tests with parallel execution disabled deleting the simulator dyld shared cache recreating simulator devices application-specific issues (the crash happens before main()) The issue is still reproducible. Investigation The earliest observable failure sequence is consistently: shared_region_check_np() → "Cannot allocate memory" (ENOMEM) Shared cache mmap(0x180000000, ...) → EACCES The shared cache region remains unmapped DyldSharedCache::getUUID() reads 0x180000058 EXC_BAD_ACCESS (Translation fault) The crash occurs before any application code executes. The first faulting instruction belongs to DyldSharedCache::getUUID(), while the shared-cache region is still unmapped. Published dyld source analysis Relevant execution path: loadDyldCache() ↓ mapSplitCachePrivate() ↓ preflightCacheFile() Based on the published sources of dyld-1378, this appears to be the execution path leading to the observed failure. After the loadDyldCache() function failed to load the cache, dyld continued execution anyway and moved on to calling the DyldSharedCache::getUUID() function, where it subsequently failed. Additional observations Once the simulator enters the degraded state: simctl spawn succeeds. simctl launch crashes inside dyld before reaching main(). During our experiments, both processes were created by the same launchd_sim instance Before dyld::_dyld_start, both processes expose the same virtual address layout, including an unmapped shared-cache region (0x180000000–0x300000000). Current workaround As a temporary mitigation, we launch the application with DYLD_SHARED_REGION=avoid In our environment, this completely avoids the launch failures. However, this mode appears to be undocumented and intended primarily for debugging. We are concerned that it may change or stop working in future macOS or Xcode releases, so we are reluctant to depend on it in our production CI infrastructure. Questions 1. dyld Is it expected for dyld to continue dereferencing the shared-cache header after both the shared-region initialization and the shared-cache mapping have already failed? Execution appears to continue into: loadInfo.loadAddress->getUUID(cacheUuid) which results in an access to an unmapped address. The attached demo project reproduces this behavior by simulating failures from the shared-cache initialization path. Is there an expected fallback behavior for this situation or is continuing into DyldSharedCache::getUUID() the intended behavior ? 2. Simulator state Why does a simulator that initially launches applications successfully eventually enter a state where every subsequent launch fails while the shared cache can no longer be mapper? The earliest related system log we have found is: vm_shared_region_start_address() returned 0x1 Is this a known CoreSimulator or macOS Tahoe issue? If so, is there a supported workaround or recommended long-term solution besides DYLD_SHARED_REGION=avoid? Any guidance would be greatly appreciated.

Hi, there's a bug in macOS 27 beta (carried over from 26) that causes base (non-Pro/Max/Ultra) M-series Macs to render certain UI animations, like Finder Quick Look and system dialog pop-ups (Restart, Shut Down, etc.), at ~30 fps unless screen recording is active. Screen recording immediately restores 60 fps across the board. The Quick Look animation is also unaffected by the bug when viewing a video file. I've reproduced the bug on multiple base M4, M5 and A18 Pro Macs in Apple Stores. Not reproducible on Pro/Max/Ultra variants. I filed a bug report in April against macOS 26 and a few weeks ago against 27. I'd very much appreciate if any of you could do so as well if it affects your machines. How to reproduce: Open Finder on any base (non-Pro/Max/Ultra) M-series Mac Press Space on any non-video file Observe ~30 fps animation Start any screen recording Repeat steps 1 and 2 Observe fluid animation Thank you in advance for your help.

Hello, I filed FB23906760 requesting full Persian (fa-IR) system-language support across Apple platforms. A focused Swift/SwiftUI feasibility and QA sample is attached privately to that feedback report. Apple platforms already provide important building blocks for Persian, including Persian text input, Unicode rendering, locale-aware formatting, semantic right-to-left layout support, and Persian calendar APIs. However, Persian is not currently selectable as a complete system interface language on iOS, iPadOS, or macOS. The submitted app-level sample exercises: runtime RTL/LTR layout switching; canonical Persian Kaf (U+06A9) and Yeh (U+06CC); ZWNJ (U+200C) preservation; LRI/PDI isolation for mixed Persian and Latin content; Persian digits and numeric separators; Foundation Persian-calendar conversion and month names; English/Persian localization-key parity; and localized accessibility metadata. I want to clearly distinguish application localization from operating-system support: A Swift or SwiftUI app can provide its own Persian strings through String Catalogs or localized resources. SwiftUI and Foundation provide useful primitives for app-level Persian support and repeatable QA. An app or sample project cannot add Persian to the system-language selector, translate Apple system UI or first-party apps, or add Persian to Siri, Dictation, Translate, or other system services. Those capabilities require implementation and release by Apple. The submitted project is therefore reproducible feasibility evidence and a QA seed, not a patch to Apple-owned operating-system resources. Its Persian copy is an AI-assisted engineering draft and is explicitly marked as requiring native linguistic, terminology, accessibility, and in-context review. I would appreciate guidance from Apple engineers on the following: What is the recommended configuration for testing a fully Persian-localized SwiftUI app when Persian is not available as a system UI language? Are there documented best practices for testing fa-IR RTL behavior, bidirectional text, VoiceOver metadata, Persian numerals, and Persian-calendar formatting consistently across iOS, iPadOS, and macOS? Are there additional developer-specific Feedback Assistant categories that would help Apple evaluate missing Persian support in system services and developer-facing localization infrastructure? Would additional fixtures or platform-specific targets be useful as supplements to FB23906760? More specifically, is there an Apple-recommended way to provide additional technical fixtures, terminology data, or validation cases to the relevant internationalization teams for evaluation of Persian (fa-IR) system-language support? This is an enhancement request and a technical localization question, not a request for information about unannounced product plans. Thank you.

I'm using PDFKitView: NSViewRepresentable to present the pdf page in SwiftUI. Seems we already have some useful built-in functions in the context menu. However, the highlight manipulation functions are not functional - I can neither delete the highlight annotation nor change the color/type of the current pointed highlight annotation. The "Add Note" and other page display changing functions work well.

Hello Apple Developer Community, My name is Chris, and I’m an independent developer building games, educational tools, and utility apps for Apple platforms. I’d like to share some of the applications I have released so far: ADVENT Text Game for Mac A retro-inspired text adventure designed specifically for macOS. View on the App Store ADVENT Text Game for iPhone and iPad Explore mysterious caves, discover hidden passages, collect treasures, and solve puzzles in a classic-inspired text adventure. View on the App Store iFrappe View on the App Store China Driving Exam Trainer A study and practice application for learners preparing for the Chinese driving licence theory examination. View on the App Store Ur: The Royal Game A digital interpretation of the ancient Royal Game of Ur. View on the App Store I’m also currently developing Steel Maze, a retro maze-based tank battle game for iPhone, iPad, and Mac. Each project has helped me explore different parts of Apple development, including SwiftUI, SpriteKit, Mac Catalyst, responsive layouts, Game Center, gameplay design, and App Store distribution. I would be happy to receive feedback from other developers and connect with people working on similar independent projects. You can find my current app portfolio here: CK My Apps Thank you for taking a look!

Hello! I am wondering if anyone else is experiencing a significant CPU drain from Spotlight (specifically corespotlightd) in macOS 11.2.2. Since updating to macOS 11.2.2 any time that I access spotlight using Command + Space Bar I immediately experience a system wide lag. Viewing this in Activity Monitor I see a %CPU spike of corespotlightd in the realm of 200-400%. that last for anywhere from 5 to 15 seconds. I have sent this in through Feedback Assistant, but no other reports seem to have been linked to the radar. I have attempted a few different fixes as well: Terminal killall corespotlightd resolves the issue momentarily, but does not fix long term Restarting computer does nothing to solve Re-indexing spotlight does not solve I have also disabled more advanced search functions (Bookmarks and History, Contacts, Events and Reminders, Fonts, Mail & Messages, Music, Siri Suggestions, and Movies are all disabled) - This did not fix the issue. I have also disabled search for external hard drives which also did not solve the issue. Open to any other suggestions for fixes, or if anyone else has a similar issue. Mac mini, 2018 (2020 release), 3.2 GHz 6-Core Intel Core i7, 32 GB 2667 MHz DDR4. External GPU Radeon RX 570 4 GB.

I'm running a PoC to validate remote push notification delivery on macOS (AppKit, no Storyboard, programmatic setup) using UNUserNotificationCenter. Environment: macOS Version 26.5 (25F71) Xcode Version 26.2 (17C52) App: sandboxed, entitlements include aps-environment: development, Push Notifications + Background Modes (Remote notifications) capabilities enabled Auth: token-based (.p8 key, ES256 JWT), sent via curl directly to api.sandbox.push.apple.com Setup: UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in if granted { NSApplication.shared.registerForRemoteNotifications() } } Delegate implements both: func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) and the legacy: func application(_ application: NSApplication, didReceiveRemoteNotification userInfo: [String: Any]) Repro steps: App launches, permission granted (true), device token successfully obtained via didRegisterForRemoteNotificationsWithDeviceToken Local notifications (via UNNotificationRequest + UNTimeIntervalNotificationTrigger) work correctly — banner displays, willPresent fires as expected Send a remote push via curl: curl -v --header "apns-topic: $TOPIC" --header "apns-push-type: alert" \ --header "authorization: bearer $AUTHENTICATION_TOKEN" \ --data '{"aps": {"alert": {"title": "Test Title","body": "Test Body"}}}' \ --http2 https://api.sandbox.push.apple.com/3/device/$DEVICE_TOKEN APNs responds HTTP/2 200 with a valid apns-id — accepted successfully Observed: No banner appears on screen Notification does not appear in Notification Center either Console log shows application(_:didReceiveRemoteNotification:) fired with the correct payload willPresent is never called for this remote push, despite firing correctly for local notifications in the same session Question: Given willPresent is documented to be the method responsible for foreground presentation decisions, and it's working correctly for local notifications, why would a remote alert-type push (with a proper alert dict, no content-available) route only through the legacy didReceiveRemoteNotification path and never reach willPresent/get displayed, despite a 200 response from APNs? One thing I noticed while investigating: the App ID used for this app (auto-created by Xcode's automatic signing) lists its Platform as "iOS, iPadOS, tvOS, watchOS, visionOS" only — macOS is not checked, even though the app itself is macOS-only and Push Notifications capability shows as enabled. Could this platform scoping on the App ID be responsible for APNs/the OS accepting the push at the network layer but not treating it as "alert-UI eligible" for display? Is macOS required to be explicitly checked as a platform on the App ID for willPresent to be invoked correctly, or is that unrelated? Any guidance on what determines whether a remote push is routed to the foreground presentation path vs. the legacy background delegate path on macOS would be appreciated.

I am currently developing an app for MacOS that needs to control HomeKit devices like lights. However, it seems like MacOS is supported on the official documentation, but not when I try to create an app ID on developer.apple.com. On the link https://developer.apple.com/apple-home/, MacOS is clearly showed as supported for MacOS. But when I try to create an app ID, it shows that it is only compatible for iOS, VisionOS and WatchOS. Could this be clarified? Best regards, orangeidle25

In /usr/include/libproc.h, there are a few number of APIs listed as private but which are commonly used (e.g. proc_pidpath). I'm trying to figure out how the proc_listallpids API is supposed to be used. From the examples I'm seeing in open source projects, the idea is to: call proc_listallpids(NULL, 0) to get a hint about the number of pids currently existing. call proc_listallpids with an appropriate buffer and retry if needed (I guess if the number of processes grew more than expected between the 2 calls). OK. What I'm not getting is how the resulting array of pids is to be used. What I am observing is that the array of pids you get is a list of the existing of the existing pids in a descendant order. BUT after pid 0, there can be additional pids. Numerous projects are just skipping pid = 0, but are using the pids after 0 as if they were valid. From what I'm seeing these are not valid pids and the correct way to handle the array of pids is to stop at pid 0 (or 1 if you want to skip the "kernel"). [Q] Is the proc_listallpids like the proc_pidpath a Voldemort API? Everyone can see it but you are not allowed to discuss it and to get more info about it you need to contact DTS. Or is it possible to know the right way to use this API and its results?

Since updating to macOS 27 beta 3 (build 26A5378j), my Mac is unable to establish any new TCP connections. This affects all outbound traffic regardless of destination or protocol, while ICMP (ping) continues to work normally. Steps to reproduce: Update to macOS 27 beta 3 (26A5378j) Connect to a standard home Wi-Fi network (no VPN, no proxy, no enterprise MDM profile) Attempt any outbound TCP connection (curl, git pull, ssh) Expected behavior: Connections to any HTTPS endpoint or SSH server should establish normally. Actual behavior: curl -4 -v https://github.com curl -4 -v https://google.com both hang indefinitely at "Trying [IP]..." — the TCP handshake never completes git pull over both HTTPS and SSH remotes times out with "Failed to connect... Timeout was reached" ping github.com and ping google.com both succeed normally and immediately This confirms the issue is isolated to TCP connection establishment, not DNS resolution or general network connectivity Issue persists identically across multiple reboots System info: macOS 27.0 beta 3, build 26A5378j Connected via personal home Wi-Fi (Bbox router) No VPN, no proxy, no enterprise security software Additional context: Multiple other users have reported identical symptoms on this same build across MacRumors forums and Reddit, describing broken connections in Firefox, Opera, Dropbox, Telegram, and Music/iTunes purchases, while Safari continues to work. Reported workarounds from other affected users include: Disabling "Limit IP Address Tracking" on the network interface Disabling all Network Extensions under System Settings → General → Login Items & Extensions Uninstalling CrowdStrike Falcon or similar EDR/security software (where present) This was working correctly on both beta 1 and beta 2, the regression appears to have been introduced specifically in beta 3.

Hi, I'm experiencing a strange issue with iCloud Drive and Xcode on a Mac mini (Apple Silicon). Environment Mac mini (Apple Silicon) macOS Tahoe 26.5.2 Xcode 26.5 Symptoms Files in iCloud Drive Desktop stay at "Waiting to Update" for several days. Cloud icons never disappear. Moving projects from iCloud Drive Desktop to ~/Developer takes hours or never finishes. Existing Xcode projects stored in iCloud Drive open as a white "Loading..." screen forever. New Xcode projects work normally. Projects already moved to ~/Developer (for example one project) open and build normally. What I have already tried Restart Mac Updated to the latest macOS Cleared Xcode caches (DerivedData, Archives, old simulators) 132 GB free disk space killall fileproviderd killall bird brctl download brctl diagnose fileproviderctl check -P Logs After restarting fileproviderd, I continuously get messages like: Possible slow statement on SELECT ... scheduler not stable: jobs are running fetch-metadata ... is busy fileproviderd constantly uses around 70% CPU. Also, fileproviderctl check -P never completes. It stops at: "About to launch FPCK checks for 1 domains" and stays there for more than 10 minutes. Questions Has anyone experienced this with macOS Tahoe? Is this likely a CloudDocs/FileProvider database issue? Is there any safe way to repair the FileProvider database without risking iCloud data? Is there any way to identify or clear the stuck synchronization queue? Any advice would be greatly appreciated.

When running a native macOS app using SwiftUI and a NavigationStack, clicking any links causes the contents of the stack to change immediately with no animation, and you can't use the usual two-finger swipe gesture to go back. The behavior is correct when running it as a Mac Catalyst app, you get the animated transitions when navigating, and swiping works. Minimal Example: (put this directly inside the WindowGroup) NavigationStack { VStack { NavigationLink { Rectangle().foregroundStyle(.red) } label: { Text("Button") } } }

In AppKit, NSSavePanel can be used to ask the user for a destination URL before the app creates a file. What is the SwiftUI equivalent for this? .fileImporter covers the NSOpenPanel case well enough, but I have not found a SwiftUI API that matches the simple NSSavePanel case where the app only needs the URL. There's a new API in .fileExporter that appears close, but it requires a non nil WritableDocument, and seems designed around SwiftUI performing the file export. My use case is a macOS app that creates new documents backed by SQLite. SQLite needs a file path so it can create the database at that location. With NSSavePanel, I can ask the user where to save the document, receive a URL, and then create the SQLite database myself. Is there a SwiftUI API for this on macOS 26 or later? If not, is NSSavePanel still the recommended approach for this case?

I have run into an interesting topic today. So far, I have been under the impression that when I am using the setCodeSigningRequirement() function on an NSXPCConnection, I am completely removing any chance of receiving AND sending messages to untrusted XPC Peers. However, I created a malicious replacement for my daemon, and I wanted to check if my application can still send and receive messages to it. I checked with codesign --verify that the replacement does NOT fulfil the code signing requirement. I put a system log instruction in the malicious tool's XPC function. When calling the XPC Peer, I expected to see: XPC connection to <redacted> failed! [Error Domain=NSCocoaErrorDomain Code=4102 "The code signature requirement failed." UserInfo={NSDebugDescription=The code signature requirement failed.}] and I did. However, I also saw the system log from the malicious tool's XPC function. Then, I checked all XPC documentation, and I found for the original C implementation - xpc_connection_set_peer_code_signing_requirement() - the following in the discussion section: All messages received on this connection will be checked to ensure they come from a peer who satisfies the code signing requirement. For a listener connection, requests that do not satisfy the requirement are dropped. When a reply is expected on the connection and the peer does not satisfy the requirement XPC_ERROR_PEER_CODE_SIGNING_REQUIREMENT will be delivered instead of the reply. (this is in xpc/connection.h) which seems to align with the observed results. However, this is (embarassingly?) new for me, I would have never expected this, given how in my head pre-checking before any connection is made seems straightforward, even with public Apple SDK APIs: Grab a SecCode (not SecStaticCode) object of the daemon (malicious or not). This is running code, so it cannot be substituted between the check and the outgoing message. Perform validations on the SecCode object in some form - on macOS 15.0+ it's pretty easy with LightweightCodeRequirement's SecCodeCheckValidityWithProcessRequirement(). Immediately drop the connection if the peer is untrusted, before any message is sent. Am I overlooking something or making wrong assumptions here? or Am I right and this is something that I have to accept that's implemented less than ideally and I can perform above steps 1-3 myself and make a difference? Thanks in advance!

Hello, I'm unable to install macOS 27 Beta 1 on relatively clean test system - 15" MacBook Air M4 16GB RAM. Error from installer log: Jun 9 09:55:29 COMPUTERNAME osinstallersetupd[11696]: Operation queue failed with error: Error Domain=com.apple.OSInstallerSetup.error Code=1007 "An error occurred preparing the update." UserInfo={NSLocalizedRecoverySuggestion=Failed to personalize the software update. Please try again., NSLocalizedDescription=An error occurred preparing the update., NSUnderlyingError=0xbdbf93f30 {Error Domain=SUMacControllerError Code=7723 "[SUMacControllerErrorPreflightPersonalizeFailed=7723] Failed to perform PreflightPersonalize operation: [MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_PERSONALIZATION_FAILURE(2)_1_MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_GLOBAL_TICKET_INVALID(53)]" UserInfo={NSLocalizedDescription=Failed to personalize the software update. Please try again., SUMacControllerErrorIndicationsMask=0, NSDebugDescription=[SUMacControllerErrorPreflightPersonalizeFailed=7723] Failed to perform PreflightPersonalize operation: [MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_PERSONALIZATION_FAILURE(2)_1_MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_GLOBAL_TICKET_INVALID(53)], NSUnderlyingError=0xbdbf93b10 {Error Domain=MobileSoftwareUpdateErrorDomain Code=2 "Could not personalize boot/firmware bundle." UserInfo={NSUnderlyingError=0xbdbf93d80 {Error Domain=MobileSoftwareUpdateErrorDomain Code=53 "Global ticket failed to verify" UserInfo=0xbdbfd2be0 (not displayed)}, NSLocalizedDescription=Could not personalize boot/firmware bundle., target_update=26A5353q}}}}} Not sure if anyone else has experienced this error?

I have an iOS app that I want to publish to the Mac App Store as a Catalyst app, but I noticed a situation where the app can't be closed and has to be force quit. The problem happens if the user has 0 photos in their Photo Library, and hits "Limited Access" on the request authorization prompt (In my case PHPhotoLibrary.requestAuthorization(for: .readWrite). Since the popup is a system prompt, I can't manually add a close button to it. I tried wrapping it in a view with a close button but the popup always shows up over any view I'm presenting within my app. If anyone has a workaround that would be greatly appreciated!

On macOS 27 Beta 2, a simple NavigationSplitView example exhibits bizarre behaviour when the window is resized. The sidebar seemingly expands and collapses at random as the window is resized. The symptoms can be exacerbated with toolbar items. The sidebar appears to behave correctly when an inspector view is not present. Copy paste the code below into a new Xcode 27 project and run on macOS 27 and then resize the window: File -> New -> Project... -> App import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { var body: some View { NavigationSplitView { Text("Sidebar") } detail: { Text("Content") } .inspector(isPresented: .constant(true)) { Text("Inspector") } } } Adding .frame or .inspectorColumnWidth to any of the Text views does not appear to fix the issues. macOS: 27.0 Beta (26A5368g) Xcode: 27.0 beta 2 (27A5209h)