Does Crashlytics encounter assertionFailure as crash?

Question

I'm a bit confused and can't find proper information about this case. As we all know from docs:

Use this function to stop the program, without impacting the performance of shipping code, when control flow is not expected to reach the call—for example, in the default case of a switch where you have knowledge that one of the other cases must be satisfied. To protect code from invalid usage in Release builds, see preconditionFailure(_:file:line:).

However, I'm getting crash report in Crashlytics when my asserionFailure fires.

Crashed: com.apple.main-thread
0  libswiftCore.dylib             0x1b0c15efc specialized _assertionFailure(_:_:file:line:flags:) + 440
1  libswiftCore.dylib             0x1b0a316b8 assertionFailure(_:file:line:) + 96
2  OneFit                         0x100a3d238 AdditionalUserInfoRouter.enqueueRoute(with:animated:completion:) + 64 (AdditionalUserInfoRouter.swift:64)
3  OneFit                         0x100a53040 protocol witness for MVVMRouter.enqueueRoute(with:animated:completion:) in conformance AdditionalUserInfoRouter + 4374458432 (<compiler-generated>:4374458432)
4  OneFit                         0x100638224 MVVMRouter.enqueueRoute(with:) + 32 (MVVMRouter.swift:32)
5  OneFit                         0x100a6a6c8 closure #2 in AdditionalUserInfoViewModel.close() + 132 (AdditionalUserInfoViewModel.swift:132)
6  OneFit                         0x100a676a0 thunk for @escaping @callee_guaranteed (@guaranteed [Subscription]) -> (@error @owned Error) + 4374541984 (<compiler-generated>:4374541984)
7  OneFit                         0x100a6fb94 partial apply for thunk for @escaping @callee_guaranteed (@guaranteed [Subscription]) -> (@error @owned Error) + 4374576020 (<compiler-generated>:4374576020)
8  PromiseKit                     0x10344d048 $s10PromiseKit8ThenablePAAE4done2on5flags_AA0A0CyytGSo17OS_dispatch_queueCSg_8Dispatch0J13WorkItemFlagsVSgy1TQzKctFyAA6ResultOyARGcfU_yycfU_ + 64
9  PromiseKit                     0x103426614 $sIeg_IeyB_TR + 28
10 libdispatch.dylib              0x1a35a9610 _dispatch_call_block_and_release + 24
11 libdispatch.dylib              0x1a35aa184 _dispatch_client_callout + 16
12 libdispatch.dylib              0x1a355c1d0 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1044
13 CoreFoundation                 0x1a385a3c4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
14 CoreFoundation                 0x1a38553b8 __CFRunLoopRun + 2004
15 CoreFoundation                 0x1a38548bc CFRunLoopRunSpecific + 464
16 GraphicsServices               0x1ad6c0328 GSEventRunModal + 104
17 UIKitCore                      0x1a78ea6d4 UIApplicationMain + 1936
18 OneFit                         0x1003b3784 main + 39 (AppDelegate.swift:39)
19 libdyld.dylib                  0x1a36df460 start + 4

---

Does Crashlytics logs asserts as crashes or I have some real crash?

UPD: Firebase/Crashlytics support response:

I don't know of any particular Crashlytics-related behavior around assertionFailure, and unless it's terminating the main app thread I would not expect us to view it as a crash. I see there's already an answer on the stackoverflow post - does that clear things up?

Answer 1

Assertions are not supposed to be enabled in release builds with -O optimisations level. This means that in final release code there will be like a blank line and so Crashlytics has nothing to crash at.

Double-check your target's build settings, if you created it from scratch or copied it from debug you may have left assertions enabled.

From docs:

In playgrounds and -Onone builds (the default for Xcode’s Debug configuration), stop program execution in a debuggable state after printing message.

In -O builds, has no effect.

In -Ounchecked builds, the optimizer may assume that this function is never called. Failure to satisfy that assumption is a serious programming error.