I experienced the same issue with safe areas and reported it here: FB24979367 But now in Xcode 27.1 RC the layout of the native keyboard has changed (not sure if it's intentional change) and globe and dictate buttons are gone, they appear as normal keys instead. However, the SDK always return "needsInputModeSwitchKey = false" for custom keyboards... so I reported it as another bug: FB25073949 On top of that, hinge detection and reserved regions don't work either... Reported as: FB24883137 27.1 release is an insane mess. iPhone Duo release experience will be a spectacular failure for the users.

I confirm the same issue. I also created a ticket: FB24785360

Still doesn't work in Xcode 27.1 RC... What a joke...

The code below doesn't detect hinge either. The reserved region isn't returned. GeometryReader { reader in let reservedRegion = reader.reservedRegions(kind: .division) }

I can confirm that the workaround prepared by @JyHu works perfect. Thank you! Your fix is going to make life easier for many users! :) Here is Swift version: enum RemoteViewCrashGuard { private static var isInstalled = false static func install() { guard shouldInstall, !isInstalled else { return } isInstalled = true swizzleContainingWindowWillOrderOnScreen() } // MARK: - Private /// Only macOS 27 is affected by the beta bug. private static var shouldInstall: Bool { ProcessInfo.processInfo.operatingSystemVersion.majorVersion == 27 } private static func swizzleContainingWindowWillOrderOnScreen() { guard let remoteViewClass = NSClassFromString("NSRemoteView") else { return } let selector = NSSelectorFromString("containingWindowWillOrderOnScreen:") guard let method = class_getInstanceMethod(remoteViewClass, selector) else { return } // Wrap the original implementation so the assertion is caught instead of // crashing. Only NSRemoteView's inconsistency is swallowed; anything // else is re-raised so we don't mask unrelated bugs. typealias OriginalFunction = @convention(c) (AnyObject, Selector, NSWindow?) -> () let originalIMP = method_getImplementation(method) let callOriginal = unsafeBitCast(originalIMP, to: OriginalFunction.self) let guardedBlock: @convention(block) (AnyObject, NSWindow?) -> () = { receiver, window in let exception = ObjCExceptionCatcher.catchException { callOriginal(receiver, selector, window) } guard let exception else { return } if exception.name == .internalInconsistencyException, exception.reason?.contains("NSRemoteView") == true { print("[RemoteViewCrashGuard] Suppressed NSRemoteView assertion: \(exception.reason ?? "")") } else { exception.raise() } } method_setImplementation(method, imp_implementationWithBlock(guardedBlock)) print( "[RemoteViewCrashGuard] Installed for macOS \(ProcessInfo.processInfo.operatingSystemVersion.majorVersion).x" ) } } ObjCExceptionCatcher.h: #import <Foundation/Foundation.h> NS_ASSUME_NONNULL_BEGIN /// Bridges Objective-C exception handling to Swift, which cannot catch /// `NSException`. Runs `tryBlock` inside an `@try/@catch` and returns any /// raised exception instead of letting it unwind and crash the app. @interface ObjCExceptionCatcher : NSObject /// Runs `tryBlock`, returning the `NSException` it raised, or `nil` if it /// completed normally. + (nullable NSException *)catchException:(NS_NOESCAPE void (^)(void))tryBlock; @end NS_ASSUME_NONNULL_END ObjCExceptionCatcher.m #import "ObjCExceptionCatcher.h" @implementation ObjCExceptionCatcher + (NSException *)catchException:(NS_NOESCAPE void (^)(void))tryBlock { @try { tryBlock(); return nil; } @catch (NSException *exception) { return exception; } } @end

Hi again, I've just managed to collect the sysdiagnose from the last customer having this issue. However, it occurred a couple of days ago, so I'm not sure if the logs will be still relevant. Here is the ticket ID: FB24089979

Hi, Any progress on that? I receive a lot of crash reports caused by this bug. I also searched the internet and many users across many different apps experience the same issue. It seems to be a critical bug. It's still reproducible using beta 4.

I asked the customer to create a ticket in Feedback Assistant, will let you know once it's done. Hopefully there is still something relevant in the logs. Interesting thing that his machine is much stronger than mine: MacBook Pro, M4 Pro, 48GB RAM, ~1TB disk vs mine: MacBook Pro M1 Pro, 16GB RAM, 1TB. The idea with swap sounds reasonable. I'm still curious why would the system always pick my application to kill.

And have you looked for your apps termination in the console log? Yes, the same reason as before - CacheDeleteAppContainerCaches I gave up and released a new version that uses a helper running as a Launch Agent to keep the main app alive. I really don't like this solution, as it introduced several edge cases that I now have to handle, such as distinguishing between an intentional quit and an unexpected termination. Unfortunately, I don't see any other way to solve it. I've collected all the information I could, but there doesn't seem to be any way to determine why the system behaves this way. It's also unclear why I've never experienced CacheDeleteAppContainerCaches while having very low free disk space. I believe that the cache-clearing feature is behaving too aggressively and is terminating the app even when it shouldn't. The logs don't provide enough information to diagnose why this is happening. It looks like the implementation of this system feature needs to be investigated.

Hello again :), My another customer has contacted me experiencing the same issue. This time we managed to collect what you asked before and here are the results: Important Usage Capacity: 58950711604 bytes (58.95 GB) Opportunistic Usage Capacity: 15721119744 bytes (15.72 GB) Soon we will also have another Feedback Assistant report from that machine. As I understand the results, they mean that the machine has instant access to ~16GB of free disk space, but in total it's possible to allocate ~59GB. So it doesn't seem like a situation in which the system should aggressively kill apps launched explicitly by the user. The customer is using Sequoia 15.7.7 (24G720) - so there might be a difference in how the system triggers those clean ups. I checked cache again and it is used only by 3rd party libraries, CloudKit and URLSession - but nothing spectacular, the size of cache on the customer's machine is below 1MB, and on my machine it's 5MB. The funny part is, that it turned out that I'm also low on free disk space. Results from my machine: Important Usage Capacity: 35198571945 bytes (35.20 GB) Opportunistic Usage Capacity: 6679613504 bytes (6.68 GB) and I have never experienced this issue. I even checked the last 28 days against CacheDeleteAppContainerCaches and there is nothing. I'm starting to suspect that maybe free disk space is just one of the components causing this problem. Maybe also something else matters - like Mac configuration or a specific service running in the background. I know that I still can go with the solution to auto-relaunch the app, but I keep it for now as the last resort, as I believe there must be something else here. Every single person reporting this issue mentions the same thing - "it only happens with your app". I also checked launch agents on my machine and none of the apps is registered there and I'm using many menu bar apps. So if the issue was "normal" it would occur also for other apps not being launch agents. I think it wouldn't be natural for the normal app to be a launch agent with the "keep alive" option. It makes sense for something that really maintains a service, that must be running all the time, but not for the normal UI app. I'm not expecting the user to be running my app all the time, I'm expecting the app to be running for as long as the user wants it running - to be explicit from the moment the user launches the app to the moment when the user quits the app - the same way the user expects non-menu bar apps to be running. Right now, I have only two wild guesses on what could be the differentiating factor between my and other apps: I'm using iCloud synchronization, so maybe it's doing too much work in the background and that's why the system decides to kill my app - this is also using cache. I'm using Firebase Crashlytics - we were able to notice that it maintains an active session in cache (probably records events that are included in crash reports). However, Firebase is quite popular so it's likely that other apps would have the same problem. I'm also keeping the library up to date. This bug is probably going to give me nightmares. It's like looking for a needle in a haystack.

I experience the same crash in my app on macOS 27 beta. It happens when I call NSAlert.beginSheetModalForWindow My stack trace: Application Specific Backtrace 0: 0 CoreFoundation 0x000000018bb76448 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018b5d45e4 objc_exception_throw + 88 2 CoreFoundation 0x000000018bb9af50 _CFBundleGetValueForInfoKey + 0 3 ViewBridge 0x00000001966063f0 -[NSRemoteView containingWindowWillOrderOnScreen:] + 216 4 CoreFoundation 0x000000018bafafc4 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 5 CoreFoundation 0x000000018bb89e88 ___CFXRegistrationPost_block_invoke + 92 6 CoreFoundation 0x000000018bb89dcc _CFXRegistrationPost + 440 7 CoreFoundation 0x000000018bac7300 _CFXNotificationPost + 688 8 Foundation 0x000000018d1ad384 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 9 AppKit 0x000000019005c970 -[NSWindow _doWindowWillBeVisibleAsSheet:] + 28 10 AppKit 0x0000000190994ad0 -[NSWindow _reallyDoOrderWindowAboveOrBelow:] + 1104 11 AppKit 0x0000000190995698 -[NSWindow _reallyDoOrderWindow:] + 64 12 AppKit 0x000000019099591c -[NSWindow _doOrderWindow:] + 300 13 AppKit 0x000000019018de4c -[NSApplication _orderFrontModalWindow:relativeToWindow:] + 268 14 AppKit 0x00000001901cc984 -[NSWindow _beginWindowBlockingModalSessionForSheet:service:completionHandler:isCritical:] + 1016 15 AppKit 0x000000019020db2c __54-[NSAlert beginSheetModalForWindow:completionHandler:]_block_invoke + 280 16 AppKit 0x000000019020ab90 -[NSAlert beginSheetModalForWindow:completionHandler:] + 116 I've also submitted it: FB23794308

None of that information is in the sysdiagnose the user captured, most likely because it’s been purged to reclaim storage. It happened back on June 6, so it's probably gone from the logs by now. Thank you for analyzing logs so fast! I wouldn't be worried if that was the only case, but I received similar reports in the past and users mentioned that "my application is the only one having this problem". I tried this and that and I thought the problem is resolved but then I got another reports. Unfortunately, I can't contact them anymore, but they did not have any app crashes in their Console. I think I'll just wait and see if anyone else reports this issue again. In such case, I'll ask them this time to collect logs properly and will let you know in this thread :). Thank you again for all the effort put into analyzing this issue!

Hi, thank you for the detailed answer and sorry for my late reply. I checked logs provided by my customer and: CacheDeleteAppContainerCaches occurred two times within 1 hour The first CacheDeleteAppContainerCaches occurred just 6 minutes after launching my app Then the customer relaunched the app 20 minutes later The second CacheDeleteAppContainerCaches occurred after 30 minutes since the app launch So it seems to happen quite often. I also asked my customer to create a ticket in the Feedback Assistant and include diagnostic logs. Here is the ticket number: FB23543555. Hopefully it will help analyze the issue on your side and see if there is anything wrong with this system behavior. I also asked him to run a script checking "volumeAvailableCapacityForOpportunisticUsageKey" and "volumeAvailableCapacityForImportantUsageKey". I'm still wait for the data, but I will post it here as soon as I get it.

@Etresoft In my case, changing the activation policy doesn't work. See the video below. I even added extra DispatchQueue.main.async and switched the window from SwiftUI to AppKit - in both cases the same result. https://github.com/user-attachments/assets/6734c215-8129-4402-9f0a-b777d27195ad Nevertheless, showing a dock icon is too disruptive for menu bar apps in most cases. If we must use a workaround, I've found a better one - calling a deeplink activates the app. It just requires registering URL scheme and calling something like: NSWorkspace.shared.open(URL(string: "menubar://main")!)

Hi, thank you for the quick reply! I wanted to call out a specific user experience issue with this approach regarding menu bar apps. Currently, if a user clicks an item in the menu bar expecting a window to open, that window appears behind the currently active window. Because it's hidden from view, the user might assume the app is broken or didn't respond. It's hard to imagine that this is the intended behavior. Bringing the newly opened window to the foreground would be the expected behavior in this case. It seems like the new NSApp.activate() was designed for regular apps and did not take menu bar apps into account. This behavior is the same when using NSApp.activate() and SwiftUI openWindow. For now, all menu bar apps still rely on the deprecated NSApp.activate(ignoringOtherApps:), but removing this function would result in breaking thousands of apps. That's why I think there should be an alternative to NSApp.activate(ignoringOtherApps:) or the behavior of NSApp.activate() should be changed when the activation policy is set to NSApp.setActivationPolicy(.accessory). Please see the video presenting this issue: https://github.com/user-attachments/assets/cc1748da-3a18-4254-b730-e8fa844158d6