There are significant crash reports coming from iOS 18 users regarding AVKit framework that starts from this line [AVPlayerController _observeValueForKeyPath:oldValue:newValue:] which seems to be coming from iOS internal SDK. There are 2 kinds of crash we found: UI modification on background thread From the stack trace it seems like when AVPictureInPictureController is being deallocated and its view is being removed from superview somehow the code is being executed in background thread because there is this line there _AssertAutoLayoutOnAllowedThreadsOnly highlighted before the crash. But I’ve checked our code that plays around AVPictureInPictureController, in the locations where we would deallocate the object it will always be called on main thread which are insideviewDidLoad and deinit inside UIViewController class. From the log, it seems like the crash happened when user try to open another content when PIP player is active resulting in the current PIP instance will be replaced with a new one. My suspect is the observation logic inside AVPlayerController could be the hint to this issue, probably something broken over there since this issue happened across our app versions on iOS 18 users only. Unfortunately, I was unable to reproduce this issue yet but one of my colleagues reproduced it once but haven’t been able to do it again since. The reports keep raising each day up to 1.3k events in the last 30 days now. Over release object This one has lower reports than the first one but I decided to include it since it might have relevant information regarding the first crash since the starting stack trace is similar. The crash timing seems to be similar to the first one, where we deallocate existing AVPictureInPictureController and later replace it with a new one and also found only in iOS 18 users which also refers to [AVPlayerController _observeValueForKeyPath:oldValue:newValue:]. I also was unable to reproduce this issue so far. Oh, and both of the issues happened on both iPhone and iPad. We’d appreciate any advice on what we can do to avoid this in the future and probably any hint on why it could happened. I have reported this issue with bug number: FB15620734 I also attached one sample crash report for each of the crashes here. non ui thread access.crash over release.crash

We found there is a significant crash reports (most of them are from iOS 17, the rest are iOS 16 and 15) comes from network loader from CFNetwork. Apparently it seems there are two types of crashes if we checked from the stack trace, the one we found from both Xcode organizer and 3rd party crash reporter is referring to URLConnectionLoader::loadWithWhatToDo and the other one from our 3rd party crash reporter (didn’t found the report from Xcode organizer) referring to _CFURLResponseCreateFromArchiveList (this one only happened on iOS 17.5 and later devices). It seems that they are both kinda similar which might point to the same root cause. From what I’ve seen, we never touch the lower level API directly, we usually use the URLSession to manage our API request. The crashed stack trace also didn’t give any indication about which of our app code that triggered the crash, it only shows calls to Apple’s internal SDKs so we are unsure how to approach this issue meanwhile the crash event already reached 800+ in the last 30 days. Unfortunately, we cannot reproduce the issue as the stack trace itself seems unclear to us. I have submitted a report through feedback assistant with number: FB14679252. Would appreciate if anyone can give any advice on what we can do to avoid this in the future and probably any hint on why it could happened. Hereby I attached the crash reports that we found each from Xcode crash report and our 3rd party crash reporter (the report said it crashed on com.apple.CFNetwork.LoaderQ) so you could get a glimpse of the similarity. Xcode crash report xcode crash report.crash 3rd party crash report 3rd party crash report.txt

We have a crash regarding to Core Data access that was not reproducible in our side but the crash count keeps increasing with the last stack trace is assertionFailure from Apple internal SDK. The last stack trace before the assertionFailure by system is our code initializing CoreData in DataContainer.init(name:bundle:inMemory:) where we will try to access CoreData and the error message we found from our 3rd party crash reporter is something like this DataStore/DataContainer.swift:30: Fatal error: Unresolved error Error Domain=NSCocoaErrorDomain Code=256 "The file “Content.sqlite” couldn’t be opened. UserInfo={NSFilePath=/var/mobile/Containers/Data/Application/9DBF262C-851A-486B-90CC-4397A8896525/Library/Application Support/Content.sqlite, NSSQLiteErrorDomain=13}, ["NSSQLiteErrorDomain": 13, "NSFilePath": /var/mobile/Containers/Data/Application/9DBF262C-851A-486B-90CC-4397A8896525/Library/Application Support/Content.sqlite] That sqlite file is supposed to be file used by Core Data (since we have no other code that access it) and we are quite confused on why sometimes the CoreData cannot be accessed with that kind of error message. So far, we still have no idea to reproduce it and what do to resolve it. I have submitted the report with bug number: FB14433998 I attached an example of the crash report here too. Please gave us insight on why it happened and how we can prevent it from happening again. crash log 1.crash

This is a testing thread to try attaching crash report that was unable to be attached few days earlier when I tried to create a new thread. This test is requested by Apple DTS to help isolating the issue. For more context: https://forums.developer.apple.com/forums/thread/747480 Crash report: crash-log-iOS-17.crash

We found crash reports from Xcode organizer about some crashes happening only in iOS and iPadOS version 17.3.0 and later across all our releases mostly in background state related to Network SDK. Unfortunately, we are unable to reproduce the issue. On the crashed thread, it seems to refer to process from Network SDK but we never import and use it directly in our project. Most of the functions found in the main thread in the crash report can't be accessed from the project, it seems to be internal framework calls in iOS SDK. The crash pointing to this line of code: nw_protocol_error Bug number: FB13661192 Somehow I cannot attach any crash report here, it always return error This post contains sensitive language. Please revise it in order to continue. whenever I try to submit it. If I remove it, I can submit the post.

We are currently observing AVPlayerItemNewErrorLogEntry notification event to track error from AVPlayer which later will be written in our logs to help us identify issue in production. But when we checked again, turns out currently the notification is not getting triggered causing many missing crucial information in our logging to debug issue that occurred related to AVPlayer as we need the errorComment information inside the error log event. Meanwhile, the accessLog event get triggered just fine. But if we check the error directly, it said that the errorLog is not empty and we can retrieve the errorLog manually by accessing the errorLog from AVPlayer.currentItem directly. (can refer to the screenshot below regarding the error from console) Is there something wrong with our implementation or it is indeed a bug from Apple ? We already filed bug report with number: FB12580746 and we are using Xcode 14.3.1.

Hi, Our application is currently crashing in production, only for users with iPhone and iPad running iOS and iPadOS 15 through all releases. Unfortunately, we cannot reproduce the issue, neither through direct build from Xcode or using build from app store, so it seems to happen intermittently. From third party crash analytics, it seems to happens mostly of background and they highlighted this as the issue. Fatal Exception: NSInvalidArgumentException -[_NSXPCDistantObject cleanupWithCompletionHandler:]: unrecognized selector sent to instance 0x2813293b0 From the Xcode crashlogs, it highlighted this which intrigue me a bit and it also exists on the stack trace from the third party (you can see they call a same function __cleanupWithCompletionHandler there). 5 Pegasus __58-[PGPictureInPictureProxy __cleanupWithCompletionHandler:]_block_invoke It seems that the crash happens probably because some process related to PIP feature that triggered this function that is handled by Pegasus framework. Any idea why this happens and is there anything i can do to prevent the crashes from happening again ? crash-log-iOS-15.crash