I'm experiencing a weird issue on iOS16. There is no code change, it works fine on lower OS versions. The stack traces are: The first case: Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x00000000e5bde410 0 libobjc.A.dylib objc_release_x21 + 16 1 CoreData -[_PFManagedObjectReferenceQueue _processReferenceQueue:] + 1020 2 CoreData -[NSManagedObjectContext _processRecentChanges:] + 112 3 CoreData _performRunLoopAction + 412 4 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36 5 CoreFoundation __CFRunLoopDoObservers + 532 6 CoreFoundation __CFRunLoopRun + 1048 7 CoreFoundation CFRunLoopRunSpecific + 612 8 GraphicsServices GSEventRunModal + 164 9 UIKitCore -[UIApplication _run] + 888 10 UIKitCore UIApplicationMain + 340 The second case, I believe this stack trace has the same root cause as the previous one (same trend, same UI page, only happens on iOS 16). Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0033003200390070 0 libobjc.A.dylib objc_msgSend + 32 1 CoreFoundation -[__NSArrayM dealloc] + 188 2 MyApplication MyClass.m - Line 361 -[MyClass loadMessages:] + 361 3 MyApplication MyClass.m - Line 125 __74-[MyClass requestRecentMessagesAndDiscardExistingMessagesCompletion:]_block_invoke + 125 4 libdispatch.dylib _dispatch_call_block_and_release + 32 5 libdispatch.dylib _dispatch_client_callout + 20 6 libdispatch.dylib _dispatch_main_queue_drain + 928 7 libdispatch.dylib _dispatch_main_queue_callback_4CF + 44 8 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 9 CoreFoundation __CFRunLoopRun + 2036 10 CoreFoundation CFRunLoopRunSpecific + 612 11 GraphicsServices GSEventRunModal + 164 12 UIKitCore -[UIApplication _run] + 888 13 UIKitCore UIApplicationMain + 340 MyClass.m is an Objective-C class, it has a property: @property (nonatomic, strong) NSArray<Message *> *messages; // Message is NSManagedObject In the second stacktrace, frame -[OurClass loadMessages:] + 361, the messages array is deallocated: self.messages = [[NSArray alloc] init...]; So my guess is, somehow the messages are over-released. If the messages are released in MyClass before, then the crash happens as the first stack trace, otherwise, it happens as the second stack trace. I've turned on -com.apple.CoreData.ConcurrencyDebug 1 to try to find out the concurrency issues and fixed them, but no luck. Any help would be much appreciated. Thanks in advance!