From examining some crashes in crashlytics I can see that for a smattering of users there is a problem occuring when using CallKit's Call Extension, however the error code is one which isn't documented. The crash is reported as: libswiftCore.dylib _diagnoseUnexpectedEnumCaseValue<A, B>(type:rawValue:) + 1272 And crash_info_entry_0 is CXErrorCodeCallDirectoryManagerError(rawValue: 102) The Apple documentation for CXErrorCodeCallDirectoryManagerError lists the same as in the code (https://developer.apple.com/documentation/callkit/cxerrorcodecalldirectorymanagererror) And here are the error codes which have values 0 to 8 public enum Code : Int { public typealias _ErrorType = CXErrorCodeCallDirectoryManagerError case unknown = 0 case noExtensionFound = 1 case loadingInterrupted = 2 case entriesOutOfOrder = 3 case duplicateEntries = 4 case maximumEntriesExceeded = 5 case extensionDisabled = 6 @available(iOS 10.3, *) case currentlyLoading = 7 @available(iOS 11.0, *) case unexpectedIncrementalRemoval = 8 } So what is error 102 and why is it not documented? Here is my code dealing with the error codes: CXCallDirectoryManager.sharedInstance.reloadExtension(withIdentifier: Config.callExtensionIdentifier()) { error in if let err = error as NSError? { self.setLastAttemptToUpdateFailedKey(failed: true) if let cdError = error as? CXErrorCodeCallDirectoryManagerError { var debugString = "" var seriousError = false switch (cdError.code) { case .unknown: debugString = "Unknown error" case .noExtensionFound: debugString = "No extension found" case .loadingInterrupted: debugString = "Loading interrupted" seriousError = true case .entriesOutOfOrder: debugString = "Entries out of order" seriousError = true case .duplicateEntries: debugString = "Duplicate Entries" seriousError = true case .maximumEntriesExceeded: debugString = "Maximum entries exceeded" case .extensionDisabled: debugString = "Extension disabled" case .currentlyLoading: debugString = "Currently Loading" case .unexpectedIncrementalRemoval: debugString = "Unexpected Incremental Removal" }

There's been a longstanding issues with Voip pushes not being delivered to the app if the app has been terminated and the device rebooted PushKit notification not arriving after application kill AND device rebootHowever with iOS 13 I'm seeing that they are not being delivered if the app is terminated without the phone being rebooted (currently observing this on 13.1.3).This is 100% reproducible, but the number of pushes that get delivered to the app after its terminated appears for the first time appears to be variable. Often the app will continue to receive pushes after being terminated but only a few before it stops receiving them entirely. However on some occasions it doesn't receive any whatsoever after being terminated. If the app is launched again then its starts receiving them again BUT only if the app is in the foreground - move it to the background and it doesn't receive any.

There's been a longstanding issues with Voip pushes not being delivered to the app if the app has been terminated and the device rebooted PushKit notification not arriving after application kill AND device rebootHowever with iOS 13 I'm seeing that they are not being delivered if the app is terminated without the phone being rebooted (currently observing this on 13.1.3).This is 100% reproducible, but the number of pushes that get delivered to the app after its terminated appears for the first time appears to be variable. Often the app will continue to receive pushes after being terminated but only a few before it stops receiving them entirely. However on some occasions it doesn't receive any whatsoever after being terminated. If the app is launched again then its starts receiving them again BUT only if the app is in the foreground - move it to the background and it doesn't receive any.Anybody else seeing this?