We've seen an issue whereby when our app is backgrounded, quit and later launched again it appears that the system has deleted all files from the app container, cleared User Defaults and cleared the app's Keychain items. No action was taken by the user to trigger this. No code within the app clears all 3 of these things (certain items in the Keychain we never clear and these are gone too) and there's no logs or tracking events to suggest the app has done this itself. This suggest to me that, for some reason, the system itself is deleting, or making inaccessible, all of the app's data and even its Keychain items (something that I thought iOS never did itself?). For the user affected (on iOS 14.6) this happened repeatedly 4 times over the span of 2 days and then suddenly stopped with no clear reason. It's also sporadically happened every few months for them. We unfortunately haven't been able to capture a sysdiagnose thus far. I'm keen to hear what might trigger this kind of behaviour by iOS or if I'm missing something?

Over the past couple of weeks we've seen an increase in crashes on launch reported by users. On retrieval of these crashes from their devices (as they were not reported in Xcode) it became apparent that they were watchdog 0x8badf00d terminations. Having consulted the documentation on Addressing Watchdog Terminations - https://developer.apple.com/documentation/xcode/diagnosing_issues_using_crash_reports_and_device_logs/identifying_the_cause_of_common_crashes/addressing_watchdog_terminations the crash reports suggest the app is mostly idle as the elapsed application CPU time is very small (0.134s) compared to the total elapsed CPU time (28.57s). What seems concerning is that the reports show almost all threads are locked (__ulock_wait) in libobjc waiting on either class look-up (look_up_class) or method dispatch (_objc_msgSend_uncached/lookUpImpOrForward), bar two queues, one of which is waiting on another queue and the other of which is inspecting images loaded by dyld (likely hitting the same lock?). There's nothing immediately apparent suggesting our app is doing anything to trigger this (the main thread is simply waiting on an object to be initialised). All crash reports present the exact same series of frames on the main thread which suggests it's not something happening beforehand taking a large amount of time (which I'd expect to be more variable). For all users re-opening the app again it works fine. Here's one of the clearest crash reports - https://gist.github.com/SquaredTiki/11a58e6837029e44da6098b34486658d (we've seen it occurring on iOS 14.2 and above). Any ideas what might be happening here?

We've noticed that our app is now immediately crashing on background on iOS 14 Beta 3 with the 0xdead10cc termination reason. This indicates (as per Technical Note TN2151 - https://developer.apple.com/library/archive/technotes/tn2151/_index.html) that the app held on to a file lock or sqlite database lock during suspension. However this crash didn't occur at all prior to beta 3. Did something change in iOS that might cause this? Stricter enforcement? This is a hard crash for us to debug with little than the technical note to go on and potentially an unknown change in iOS itself.