Post

Replies

Boosts

Views

Activity

Reply to NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)
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
Topic: UI Frameworks SubTopic: AppKit
1d
Reply to My macOS app is getting closed by the system
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
1d
Reply to My macOS app is getting closed by the system
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
2d
Reply to My macOS app is getting closed by the system
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
1w
Reply to NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)
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
Topic: UI Frameworks SubTopic: AppKit
2w
Reply to My macOS app is getting closed by the system
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!
Topic: UI Frameworks SubTopic: AppKit Tags:
3w
Reply to My macOS app is getting closed by the system
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
4w
Reply to NSApp.activate() does not work with menu bar (background) apps
@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")!)
Topic: UI Frameworks SubTopic: AppKit Tags:
Jul ’26
Reply to NSApp.activate() does not work with menu bar (background) apps
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
Topic: UI Frameworks SubTopic: AppKit Tags:
Jul ’26
Reply to My macOS app is getting closed by the system
Thank you for your quick reply! I’m sure that LaunchAgent is a great workaround for this issue, but it’s a workaround. I wonder if there is any reliable way to fix that issue. My app could be relaunched with no issues, but what if the app is doing some work, or has some unsaved progress, or for any other reason we don’t want the app to be randomly killed and relaunched every couple of minutes? Usually, we don’t want to fix app crashes by installing an agent relaunching the app. The same way we don’t want to fix app getting killed by the system by installing that agent. It would be a good solution if we want to make sure that the app is always running no matter what happens, but it’s not a good solution if we just want to make sure that the app operates normally as the user expects it to work. Also, this workaround works only if the user wants to launch the app on every system startup. If the user doesn’t select that option, the workaround is not applicable and the app will be terminated randomly. Also, setting KeepAlive = true means that the app will be relaunched even if the user decides to quit the app manually, which isn’t a desired behavior. Probably I could intercept a manual termination and update LaunchAgent, but it seems like building a serious logic just to workaround an issue that shouldn’t occur in the first place. I’m quite sure that my app isn’t heavily using cache, so I’d love to know how to diagnose this problem and how to determine why on my client’s device, only my app is affected by this aggressive clean up macOS behavior. I think it shouldn’t be considered normal that the app might be killed every couple of minutes just because the user has let’s say 8gb free disk space instead of 30gb.
Topic: UI Frameworks SubTopic: AppKit Tags:
Jun ’26
Reply to My macOS app is getting closed by the system
I finally managed to collect logs and pin down the issue: 2026-06-06 19:40:48.660726+0200 0x2ad59d Default 0x0 1 0 launchd: [gui/502/application.com.bundle.id.198150604.198151841 [89659]:] exited with exit reason (namespace: 15 code: 0xbaddd15c) - OS_REASON_RUNNINGBOARD | <RBSTerminateContext| code:0xBADDD15C explanation:CacheDeleteAppContainerCaches requesting termination assertion for com.bundle.id reportType:None maxTerminationResistance:NonInteractive attrs:[ <RBSPreventLaunchLimitation| <RBSProcessPredicate <RBSProcessBundleIdentifierPredicate "com.bundle.id">> allow:(null)> 2026-06-06 19:40:48.660738+0200 0x2ad59d Default 0x0 1 0 launchd: [gui/502/application.com.bundle.id.198150604.198151841 [89659]:] service state: exited 2026-06-06 19:40:48.660756+0200 0x2ad59d Default 0x0 1 0 launchd: [gui/502/application.com.bundle.id.198150604.198151841 [89659]:] internal event: EXITED, code = 0 As it turns out, the problem appears when the system is running low on disk space. Then the runningboardd kills the app to perform cache clean up: OS_REASON_RUNNINGBOARD | <RBSTerminateContext| code:0xBADDD15C explanation:CacheDeleteAppContainerCaches Is there any way to prevent that? My application is not using cache at all besides what Apple frameworks and common 3rd party SDKs use.
Topic: UI Frameworks SubTopic: AppKit Tags:
Jun ’26
Reply to App Review keeps rejecting without addressing my replies
If you keep receiving the same response it's most likely because you are talking to a bot. Every time you reply it probably runs the same test on your app and prints the same output. I encountered it in the past. I think this bot also takes data from review notes, so you can try adding information there and resubmitting your app. This is what we get for the annual subscription and 15-30% fees from sales.
May ’26
Reply to NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)
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
Topic: UI Frameworks SubTopic: AppKit
Replies
Boosts
Views
Activity
1d
Reply to My macOS app is getting closed by the system
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
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
1d
Reply to NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)
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.
Topic: UI Frameworks SubTopic: AppKit
Replies
Boosts
Views
Activity
1d
Reply to My macOS app is getting closed by the system
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
1d
Reply to My macOS app is getting closed by the system
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
2d
Reply to My macOS app is getting closed by the system
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
1w
Reply to NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)
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
Topic: UI Frameworks SubTopic: AppKit
Replies
Boosts
Views
Activity
2w
Reply to My macOS app is getting closed by the system
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!
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
3w
Reply to My macOS app is getting closed by the system
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
4w
Reply to NSApp.activate() does not work with menu bar (background) apps
@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")!)
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Jul ’26
Reply to NSApp.activate() does not work with menu bar (background) apps
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
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Jul ’26
Reply to My macOS app is getting closed by the system
I've just got more details from my customer: The app's cache is using 12kb, so it's not normal that the system kills the app for that reason. The customer has 9GB of free disk space + iCloud space that could be used by the system by moving local files to cloud.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Jun ’26
Reply to My macOS app is getting closed by the system
Thank you for your quick reply! I’m sure that LaunchAgent is a great workaround for this issue, but it’s a workaround. I wonder if there is any reliable way to fix that issue. My app could be relaunched with no issues, but what if the app is doing some work, or has some unsaved progress, or for any other reason we don’t want the app to be randomly killed and relaunched every couple of minutes? Usually, we don’t want to fix app crashes by installing an agent relaunching the app. The same way we don’t want to fix app getting killed by the system by installing that agent. It would be a good solution if we want to make sure that the app is always running no matter what happens, but it’s not a good solution if we just want to make sure that the app operates normally as the user expects it to work. Also, this workaround works only if the user wants to launch the app on every system startup. If the user doesn’t select that option, the workaround is not applicable and the app will be terminated randomly. Also, setting KeepAlive = true means that the app will be relaunched even if the user decides to quit the app manually, which isn’t a desired behavior. Probably I could intercept a manual termination and update LaunchAgent, but it seems like building a serious logic just to workaround an issue that shouldn’t occur in the first place. I’m quite sure that my app isn’t heavily using cache, so I’d love to know how to diagnose this problem and how to determine why on my client’s device, only my app is affected by this aggressive clean up macOS behavior. I think it shouldn’t be considered normal that the app might be killed every couple of minutes just because the user has let’s say 8gb free disk space instead of 30gb.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Jun ’26
Reply to My macOS app is getting closed by the system
I finally managed to collect logs and pin down the issue: 2026-06-06 19:40:48.660726+0200 0x2ad59d Default 0x0 1 0 launchd: [gui/502/application.com.bundle.id.198150604.198151841 [89659]:] exited with exit reason (namespace: 15 code: 0xbaddd15c) - OS_REASON_RUNNINGBOARD | <RBSTerminateContext| code:0xBADDD15C explanation:CacheDeleteAppContainerCaches requesting termination assertion for com.bundle.id reportType:None maxTerminationResistance:NonInteractive attrs:[ <RBSPreventLaunchLimitation| <RBSProcessPredicate <RBSProcessBundleIdentifierPredicate "com.bundle.id">> allow:(null)> 2026-06-06 19:40:48.660738+0200 0x2ad59d Default 0x0 1 0 launchd: [gui/502/application.com.bundle.id.198150604.198151841 [89659]:] service state: exited 2026-06-06 19:40:48.660756+0200 0x2ad59d Default 0x0 1 0 launchd: [gui/502/application.com.bundle.id.198150604.198151841 [89659]:] internal event: EXITED, code = 0 As it turns out, the problem appears when the system is running low on disk space. Then the runningboardd kills the app to perform cache clean up: OS_REASON_RUNNINGBOARD | <RBSTerminateContext| code:0xBADDD15C explanation:CacheDeleteAppContainerCaches Is there any way to prevent that? My application is not using cache at all besides what Apple frameworks and common 3rd party SDKs use.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Jun ’26
Reply to App Review keeps rejecting without addressing my replies
If you keep receiving the same response it's most likely because you are talking to a bot. Every time you reply it probably runs the same test on your app and prints the same output. I encountered it in the past. I think this bot also takes data from review notes, so you can try adding information there and resubmitting your app. This is what we get for the annual subscription and 15-30% fees from sales.
Replies
Boosts
Views
Activity
May ’26