Runningboard services crash on iOS13: Crashed: com.apple.runningboardservices.connection.incoming

Our application has been experiencing a weird iOS 13 crash which I still haven't managed to solve.

As per Fabric data, it is only happening on iOS 13 devices and 96% of the time when app is in background. The following crash is displayed in Fabric:



Crashed: com.apple.runningboardservices.connection.incoming

EXC_BAD_ACCESS 0x00000001039e3800


Raw Text

0


libdyld.dylib


dyld3::closure::ObjCStringTable::hash(char const*, unsigned long) const + 16


6


libobjc.A.dylib


look_up_class + 100


7

Foundation


NSClassFromString + 200


8


BaseBoard


_BSXPCDecodeObject + 2000


25


libsystem_pthread.dylib


start_wqthread + 8



Has anyone else experienced anything similar or can advise me where to look for clues? Thank you in advance.

Replies

We're also having a similar issue under iOS 13.

I’m also seeing the same error in Crashlytics but have no idea where it comes from.

We're seeing the same issue being reported on Firebase Crashlytics. Any help would be appreciated!

Same issue! Anyone figure this out yet?

Are you using NSFileProtectionComplete in your entitlements? We found a *strong* correlation between using NSFileProtectionComplete and the crash, which would happen soon after device lock.


We were able to temporarily work around this issue by switching to NSFileProtectionCompleteUntilFirstUserAuthentication, then locking specific directories with NSFileProtectionComplete.

I have responded on this thread: https://forums.developer.apple.com/thread/122858

"It seems that the dyld3 saves the generated clojure files in the app tmp directory and if you use NSFileProtectionComplete the clojure files have this property too. To generate a crahs close the app, lock the phone, send a push that will wake up the app and then the crash is generated.

The solution seems to be simple, just change the permissions for the app tmp direcptry to NSFileProtectionCompleteUntilFirstUserAuthentication and the app will not crash.

I really don't know why apple did this."

Though the solution can avoid the crash. Compromising the security of the app data to avoid a crash doesnt seems like a good idea.