My CloudKit
dataset in Production Environment
is somewhat bigger than Development
, and other exotic difference could exist.
T
When the app will go the the background, at some point it will be killed by iOS because your thread won't have answered to the -applicationDidEnterBackground
, and then you will get a backtrace of all your threads.
If you want a better chance to trigger the kill (if the locked thread is not the main thread), you could grab a background task (- beginBackgroundTaskWithExpirationHandler:
) in your working threads: if they are locked at some point they will never release the background task and they'll trigger the kill.
Now just wait for the iOS scheduler to kill your app and grab the stack trace. In there, you should be able to find the culprit by looking at all you thread's backtraces and identify which ones are locked in a mutex lock() function.
I bet you don't even need symbolication for that.
I would recommend using a crash reporting service. While there are a few options out there, I worked with Crashlytics, and I was very happy with the reports that they provided, always helping me to fix bugs in production.