Crash on iOS 13.1

Guys, I am super worried about this, because we have tons of crashes. I have the impression it happen while the app is going into background, therefore it might not be noticed by the users.
I am on 5.5.0 and will update to 5.5.1 soon. Nevertheless, if you didn’t fix it in 5.5.1, it will most likely be there again. Attaching some logs for you:

0  libdyld.dylib                  0x1ae4156c0 dyld3::closure::ObjCStringTable::hash(char const*, unsigned long) const + 16
1  libdyld.dylib                  0x1ae415cd4 dyld3::closure::ObjCStringTable::getIndex(char const*) const + 52
2  libdyld.dylib                  0x1ae415a6c dyld3::closure::ObjCStringTable::getPotentialTarget(char const*) const + 20
3  libdyld.dylib                  0x1ae4159fc dyld3::closure::ObjCStringTable::getString(char const*, dyld3::Array<unsigned long> const&) const + 32
4  libobjc.A.dylib                0x1ae34c80c search_builtins(char const*) + 112
5  libobjc.A.dylib                0x1ae34c614 __sel_registerName(char const*, bool, bool) + 44
6  libobjc.A.dylib                0x1ae33e794 fixupMethodList(method_list_t*, bool, bool) + 160
7  libobjc.A.dylib                0x1ae33c46c prepareMethodLists(objc_class*, method_list_t**, int, bool, bool) + 132
8  libobjc.A.dylib                0x1ae33b8ac realizeClassWithoutSwift(objc_class*, objc_class*) + 1412
9  libobjc.A.dylib                0x1ae33b0f0 realizeClassMaybeSwiftMaybeRelock(objc_class*, mutex_tt<false>&, bool) + 100
10 libobjc.A.dylib                0x1ae33ac00 initializeAndMaybeRelock(objc_class*, objc_object*, mutex_tt<false>&, bool) + 116
11 libobjc.A.dylib                0x1ae3474a4 lookUpImpOrForward + 700
12 libobjc.A.dylib                0x1ae3354fc _objc_msgSend_uncached + 60
13 MoneyBox                       0x1052b0af4 -[IntercomSDK_IntercomNexusSocket disconnect] + 4379118324
14 MoneyBox                       0x1052ae570 -[IntercomSDK_IntercomNexusConnection finishBackgrounding] + 4379108720
15 Foundation                     0x1ae9fa03c __NSFireTimer + 64
16 CoreFoundation                 0x1ae58ee1c __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28
17 CoreFoundation                 0x1ae58eb58 __CFRunLoopDoTimer + 880
18 CoreFoundation                 0x1ae58e228 __CFRunLoopDoTimers + 276
19 CoreFoundation                 0x1ae589364 __CFRunLoopRun + 1920
20 CoreFoundation                 0x1ae5888bc CFRunLoopRunSpecific + 464
21 GraphicsServices               0x1b83f3328 GSEventRunModal + 104
22 UIKitCore                      0x1b261d6d4 UIApplicationMain + 1936
23 MoneyBox                       0x104b71760 main + 15 (AppDelegate.swift:15)
24 libdyld.dylib                  0x1ae413460 start + 4

0  libdyld.dylib                  0x1aca08684 dyld3::closure::ObjCStringTable::hash(char const*, unsigned long) const + 16
1  libdyld.dylib                  0x1aca08c98 dyld3::closure::ObjCStringTable::getIndex(char const*) const + 52
2  libdyld.dylib                  0x1aca08b18 dyld3::closure::ObjCClassOpt::forEachClass(char const*, dyld3::Array<std::__1::pair<unsigned long, unsigned long> > const&, void (void*, bool, bool*) block_pointer) const + 52
3  libdyld.dylib                  0x1aca154c4 dyld3::AllImages::forEachObjCClass(char const*, void (void*, bool, bool*) block_pointer) const + 132
4  libobjc.A.dylib                0x1ac947c38 getPreoptimizedClass + 148
5  libobjc.A.dylib                0x1ac9328d8 getClassExceptSomeSwift(char const*) + 20
6  libobjc.A.dylib                0x1ac933784 look_up_class + 100
7  BaseBoard                      0x1af79d2bc _BSXPCEncodeObjectForKey + 124
8  BaseBoard                      0x1af79d0cc -[BSXPCCoder encodeObject:forKey:] + 96
9  RunningBoardServices           0x1af738554 __44+[RBSXPCMessage messageForMethod:arguments:]_block_invoke + 288
10 RunningBoardServices           0x1af7382ac +[RBSXPCMessage messageWithEncoder:] + 72
11 RunningBoardServices           0x1af738358 +[RBSXPCMessage messageForMethod:arguments:] + 148
12 RunningBoardServices           0x1af7386d8 +[RBSXPCMessage messageForMethod:varguments:] + 192
13 RunningBoardServices           0x1af72816c -[RBSConnection _invalidateAssertionIdentifier:error:] + 144
14 RunningBoardServices           0x1af720fc4 -[RBSConnection invalidateAssertion:error:] + 80
15 RunningBoardServices           0x1af71ef8c -[RBSAssertion _clientInvalidateWithError:] + 124
16 AssertionServices              0x1b128e164 -[BKSAssertion _invalidateSynchronously:] + 104
17 AssertionServices              0x1b12930c4 -[BKSProcessAssertion invalidate] + 92
18 UIKitCore                      0x1b0c04384 __36-[UIApplication _endBackgroundTask:]_block_invoke.3308 + 272
19 UIKitCore                      0x1b0bd8eb0 -[_UIObjectReferenceCounter decrementReferenceForObject:invalidationHandler:] + 280
20 UIKitCore                      0x1b0c04240 __36-[UIApplication _endBackgroundTask:]_block_invoke + 320
21 libdispatch.dylib              0x1ac8d11cc _dispatch_client_callout + 16
22 libdispatch.dylib              0x1ac8b4e5c _dispatch_lane_barrier_sync_invoke_and_complete + 56
23 UIKitCore                      0x1b0c03fbc -[UIApplication _endBackgroundTask:] + 876
24 MoneyBox                       0x10297e6d0 -[IntercomSDK_IntercomNexusConnection invalidateBackgroundTask] + 4318635728
25 MoneyBox                       0x10297e5b4 -[IntercomSDK_IntercomNexusConnection finishBackgrounding] + 4318635444
26 Foundation                     0x1acfec810 __NSFireTimer + 64
27 CoreFoundation                 0x1acb816cc __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28
28 CoreFoundation                 0x1acb81408 __CFRunLoopDoTimer + 880
29 CoreFoundation                 0x1acb80ad8 __CFRunLoopDoTimers + 276
30 CoreFoundation                 0x1acb7bc14 __CFRunLoopRun + 1920
31 CoreFoundation                 0x1acb7b16c CFRunLoopRunSpecific + 464
32 GraphicsServices               0x1b69b3328 GSEventRunModal + 104
33 UIKitCore                      0x1b0be5d0c UIApplicationMain + 1936
34 MoneyBox                       0x102241760 main + 15 (AppDelegate.swift:15)
35 libdyld.dylib                  0x1aca06424 start + 4

Okay, I think I have the answer to this one.
A bit of context: our app has a 5-minute window, so that if you raise the app from background and 5 minutes have passed since the time you put in background, then we bring the user straight to login page.
In doing so, we replace the rootViewController of the app window.

Here is the problem:
our code to get the window of the app was UIApplication.shared.keyWindow whereas the correct code should be UIApplication.shared.delegate?.window.
Using the first snippet, Intercom was complaining I tried to replace the RootViewController of its window, not the window of the app!

Hey again,
unfortunately the crash is still happening. We had that on test flight, using IntercomSDK 5.5.1, iOS 13.1.2.
Steps to reproduce it:

  • we just put the app in background
  • after some minutes, the crash happens (test flight reports that on screen via an alert to the tester)

Same log I posted up there is still valid

Same issue here in my iOS app

Has anyone found a workaround in the meantime? Need to be able to access the view hierarchy.

No workaround yet. Intercom responded privately to me this morning saying there is no update on their side. Not sure they are looking at it. Everything was perfectly smooth for me until iOS 13 came up. Having thousands of crashes in our app at the moment. :pensive:

I have created this extension workaround (I now use .mainAppWindow() instead of .keyWindow)

import UIKit

extension UIApplication {
    func mainAppWindow() -> UIWindow? {
        for window in {
            if window.windowLevel == .init(0.0) {
                return window
        return UIApplication.shared.keyWindow

In my exploration so far the app window we are interested in reliably has windowLevel of 0.0, whereas the intercom window and others have <= 0.1.

This may not always be true however, if anyone has a better way to determine the correct window please let me know!

Hey all :wave:

Any idea if your apps are using UISceneDelegate? We dug into this and if so you must initialize Intercom in your SceneDelegate class (docs were recently updated):

iOS 13 has introduced the concept of a UIScene that wraps the traditional UIWindow. This is used for the new multiple window feature on iPadOS but the concept of a scene extends across all iOS 13 apps. If your app has a UISceneDelegate then you will need to initialize Intercom in this class and not in the AppDelegate as has traditionally been the case.

We are still not using the SceneDelegate in our app, unfortunately

1 Like

This error still is shown in iOS 13.1 and iOS 13.2, and It failed in Cordova-Intercom too.

Any solution?

Hi Nate
Brian here, I’m an iOS Engineer at Intercom.
In iOS, there is now the concept of an UIScene object that wraps all your windows. Usage of UIApplication.shared.keyWindow has been deprecated by Apple. Instead you should use UIApplication.connectedScenes. This will return a list of all your scenes. If you only have one scene you can then check the windows array in that scene that will return all the windows that are active in your app.
When you have Intercom installed, this will usually return two windows. Your own UIWindow and Intercom’s ICMWindow. You can do a simple type check on these to check which one belongs to you app and set the rootViewController on this.

Hope this helps


Hey Brian, appreciate the answer. I don’t think this crash is related to the window though. It is something happening when the app is in background.
It seems to be related to a background task that is started and not explicitly ended on termination of the app. It’s affecting a lot of our users, and on all currently live and beta versions of iOS13. The only thing that’s changed as far as I can tell is the length of time Apple allow you to complete background tasks in

Hey Valebettins,
Yep, I’m aware. My response was to clarify the earlier confusion about UIWindow.
The issue you are experiencing is as a result of Apple being extra aggressive in its background timeouts.
Some of our customers have reported to us that the cause of this for them is the use of NSFileProtectionComplete being specified in their entitlements file. When this option is set, Apple appear to reduce the background task time and this is causing crashes, not just for Intercom but for other services too. See

We’re working at the moment to properly re-create this issue internally so we can find a fix. It is quite difficult to debug this though because it only seems to occur on archived apps, not in the simulator.
If it’s the case that your app uses NSFileProtectionComplete, then a workaround that has worked for others is to change this to NSFileProtectionCompleteUntilFirstUserAuthentication.



Hi, any updates on this? I think we’re experiencing a related crash. We’re using Intercom 5.5.1 on iOS, and seeing lots of crashes on iOS 13 related to ICMRootViewController which sounds like an Intercom class?

Fatal Exception: NSInvalidArgumentException

-[ICMRootViewController tabBar]: unrecognized selector sent to instance 0x1619352c0

0 CoreFoundation 0x1afb8c98c __exceptionPreprocess
1 libobjc.A.dylib 0x1af8b50a4 objc_exception_throw
2 CoreFoundation 0x1afa9043c -[NSOrderedSet initWithSet:copyItems:]
3 UIKitCore 0x1b3bc82a8 -[UIResponder doesNotRecognizeSelector:]
4 CoreFoundation 0x1afb90e08 forwarding
5 CoreFoundation 0x1afb92bec _CF_forwarding_prep_0
6 Quick Service Estimates and Invoices 0x102568ac4 -[EmailViewController viewWillAppear:] + 336 (EmailViewController.m:336)
7 UIKitCore 0x1b359320c -[UIViewController _setViewAppearState:isAnimating:]
8 UIKitCore 0x1b35938a0 -[UIViewController __viewWillAppear:]
9 UIKitCore 0x1b34ed8b4 -[UINavigationController _startCustomTransition:]
10 UIKitCore 0x1b3500de8 -[UINavigationController _startDeferredTransitionIfNeeded:]
11 UIKitCore 0x1b35022ec -[UINavigationController __viewWillLayoutSubviews]
12 UIKitCore 0x1b34e6060 -[UILayoutContainerView layoutSubviews]
13 UIKitCore 0x1b4025270 -[UIView(CALayerDelegate) layoutSublayersOfLayer:]
14 QuartzCore 0x1b65115f8 -[CALayer layoutSublayers]
15 QuartzCore 0x1b6515e28 CA::Layer::layout_if_needed(CA::Transaction*)
16 QuartzCore 0x1b6521894 CA::Layer::layout_and_display_if_needed(CA::Transaction*)
17 QuartzCore 0x1b646a9f0 CA::Context::commit_transaction(CA::Transaction*, double)
18 QuartzCore 0x1b6494890 CA::Transaction::commit()
19 QuartzCore 0x1b6495284 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*)
21 CoreFoundation 0x1afb04b34 __CFRunLoopDoObservers
22 CoreFoundation 0x1afb05100 __CFRunLoopRun
23 CoreFoundation 0x1afb048bc CFRunLoopRunSpecific
24 GraphicsServices 0x1b9970328 GSEventRunModal
25 UIKitCore 0x1b3b9a6d4 UIApplicationMain
26 Quick Service Estimates and Invoices 0x10251933c main + 16 (main.m:16)
27 libdyld.dylib 0x1af98f460 start

Hi @Alex_Black
Thanks for posting this issue here.
This is unrelated to the rest of the thread. My suggestion is that you get in touch with one of our support engineers via Intercom chat to solve this.

It seems that the root cause of apps crashing in the background is as a result of a bug in iOS 13. Apps are being aggressively killed by the OS when they go into the background. This is a widely reported bug for iOS 13 and is even affecting Apple’s on native apps.
When the system kills the the app, it produces a stacktrace that gives a current snapshot of what is currently executing. Intercom runs a background task for 20 seconds when the app is backgrounded. This is done following Apple’s guidelines for background tasks and is well within the limit for background execution time. The reason that Intercom shows up in this stacktrace is because the app is being killed while Intercom is still running a background process.

From further research we have done on this, its clear that apps that have an NSFileProtectionComplete specified in their entitlements file are killed sooner than apps that don’t.
There’s not much Intercom can do about this except wait for Apple to fix this iOS 13 bug.
Just note that the stacktrace that is appearing for this is not as a result of Intercom causing a crash, it’s simply because Intercom is running as a background task when iOS kills the app.

I hope this provides clarification on this issue for you all. If you have any questions, feel free to ask.


Update 2
Apple have released 13.3 Beta and this seems to resolve the issue with apps being aggressively killed in the background.
This will resolve the issue reported in this thread.


Thanks, I will keep you posted if that is fixing the crashes we have

Update 3
This is actually fixed in iOS 13.2.1
No need to wait for 13.3 to be released.

I confirm this is now fixed! :partying_face: