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.

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.

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.

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.

That's how this company operates. In such important process like app review where a single decision can destroy your business, there should be an independent mediator who can resolve disputes, but there is none, because they don't care, this is how those big companies operate. So the whole process is a random thing, you will notice sooner or later that you may get rejected and other apps in the App Store do the same and they are fine. It's all random and depends on who is assigned to your review. I also noticed that there are some cases which are incorrectly implemented in their automation and if I don't add extra info in review notes, I will get rejected every time for the same thing, even though it is invalid.

I confirm everything you wrote. The wait for a review is now significantly longer. And I can tell you that no, they aren't doing anything about it. The quality of Apple's services is going down drastically. They don't fix reported critical bugs, and they introduce new ones with every update. Reviews are just another step in lowering quality. Not to mention that the review process is not a charity work, we pay the annual subscription and 15-30% in fees from sales... And that's what we get in exchange - making dev lives miserable by rejecting apps for every tiny thing and waiting for days for a review. I also observed a significant drop in installations since April, so they also changed something in algorithms. I will be adding a direct distribution in the near future too. The review process and wait time is unacceptable.

I managed to perform multiple tests on the physical Apple Watch and I can confirm that the root cause of this problem is the app intent shared between watchOS and widget extension target. Having this file in a single target solves the issue. However, this approach can’t be used to workaround this issue because the widget configuration intent is by design supposed to be used in these two targets. Otherwise, tapping on a widget produces silent errors, which I included in the previous post. Also, sharing intents is necessary to be able to perform ClockKit complications migration and to check widgets configuration from the watchOS app. So we found the root cause, but we don’t have any suitable workaround yet. This problem is clearly watchOS bug. Additionally, I also observed that sharing the intent between iOS app and widget extension doesn’t cause this issue. So it happens only when the intent is shared between watchOS app and widget extension. Also, the problem isn’t caused by sharing the localization file. It all depends on target membership of the intent file.

Hi, I'm using the latest Xcode (26.4.1) and I'm targeting iOS 16.6. Also, make sure that you don't provide parametrized summary - in this case it works correctly. I'm using something like that: static var parameterSummary: some ParameterSummary { Summary("List Items") { \.$collections } } The issue occurs only if you have the "form" view. It's easily reproducible with this configuration. I tried also with an optional array [String]? and it doesn't help. I've found a workaround which in my case is suitable. I added predefined values this way: @Parameter(title: "Collections", optionsProvider: CollectionsOptionsProvider()) var collections: [String]? However, it isn't good enough if someone needs a completely custom input.

I experience the same problem. Have you managed to resolve it?

Hopefully this is not too late. I've been quite swamped these days... No, I'm still trying to resolve this problem. Thank you for investigating it. Tomorrow, I will be able to check it on a physical device. However, even if this is a workaround, it won't help in my case, because I need to have access to intents from the watch app to check a couple of things and to perform old complications migration from ClockKit to WidgetKit. Also, intents should be shared between the watchOS app and widgets extension. If you don't share it and tap on a widget you get these warnings in the console: Failed to instantiate type ConfigurationAppIntent by name (12WatchWidgets22ConfigurationAppIntentV). The type with this mangled name does not exist in the process’s memory space. [InitializeAction <<E:A1CC23EC19DC>>] Could not find an intent with identifier ConfigurationAppIntent, mangledTypeName: Optional("12WatchWidgets22ConfigurationAppIntentV") associateAppIntent(forUserActivity:) - Error converting INIntent to App Intent: AppIntents.PerformIntentError.intentNotFound You can check this if you run your project from Xcode (watchOS app target) and tap on a widget.

@DTS Engineer so what's going on with this issue? I created DTS ticket as requested, I provided reproducible minimal project, and the only thing I received is this message... Thank you for providing this information. It is quite intriguing and I believe it would be prudent to file a bug report to investigate the underlying cause of this issue. As we do not encounter any localization-related problems on watchOS, it is possible that you have identified an issue that requires our attention. Please submit a complete bug report regarding this issue using Feedback Assistant So the localization isn't working and this bug is going to be ignored for the next couple of years? Great support in exchange for a yearly developer subscription and a 15% fee on app sales. Not to mention another truly critical bug that hasn't been fixed for 2 years... https://developer.apple.com/forums/thread/757380

I ran some tests and can confirm that with Xcode 26, xcodebuild now works just as fast as Xcode 16 with the workaround. This is true both when rebuilding the app without any changes and when performing incremental builds after making changes. I also noticed that Xcode 26 no longer calls the slow developerservices2.apple.com. Instead, it uses https://ocsp2.apple.com, which is much faster.

We have a similar issue with MP4 files. It works well with HLS, but with MP4 the AVPlayer requests all chunks like (, ), so basically, it ends up downloading the same video multiple times during a single playback... It seems like the streaming is broken.

Great investigation guys! Indeed those requests are very slow, on my side they take around ~20 seconds: Blocking developerservices2.apple.com significantly improves build time. As @FelixII suggested, the solution is to block it in /etc/hosts by adding: 127.0.0.1 developerservices2.apple.com or probably a better option to use something like Proxyman app to temporarily block/unblock it. Keep in mind that blocking this domain will probably result in Xcode being unable to automatically register devices, capabilities, etc. I guess we need to wait for some fix from Apple. Probably some cache?

I figured it out: You can connect any Bluetooth keyboard to an iPhone, it should behave the same way as on iPad. Hitting the globe button once should show a list of keyboards, if I select my custom keyboard it appears automatically on the screen even if the hardware keyboard is connected. Then I can quickly switch between two most recent keyboards by hitting Globe button again.