iOS app crash, symbolicated logs are opaque - objective-c

Question

I believe I'm looking at properly symbolicated logs, but please do tell me if that's not the case. This is an excerpt of a crash log I received from Apple after rejected due to a crash upon launch, which I have been entirely unable to replicate.
I installed a crash reporting system called Crashlytics which received no crash reports during the time the app was In Review, leading me to believe the crash occurs before AppDelegate's didFinishLaunchingWithOptions where Crashlytics is initialized. That said, Crashlytics only sends reports upon re-opening the app after a crash. So the Apple reviewer may have experienced a crash and didn't bother to attempt again, possible the reason I have no Crashlytics report.
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 0
Last Exception Backtrace:
(0x181f9a084 0x1929ec0e4 0x180819674 0x100091318 0x100084fe4 0x100084098 0x18671d158 0x18671ce68 0x1867d0ee8 0x1869d1da8 0x186791938 0x18671e88c 0x1867906f8 0x10006187c 0x18678e5d0 0x1869a4de8 0x1869a7568 0x1869a5c00 0x18a171640 0x181f52360 0x181f51468 0x181f4fa8c 0x181e7d664 0x18678798c 0x186782984 0x100061c28 0x19305aa08)
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x0000000193172964 __kill + 8
1 Luff 0x00000001001330dc 0x10005c000 + 880860
2 libsystem_platform.dylib 0x0000000193208958 _sigtramp + 64
3 libsystem_pthread.dylib 0x0000000193211224 pthread_kill + 108
4 libsystem_c.dylib 0x00000001930eab14 abort + 108
5 libc++abi.dylib 0x00000001921d1414 abort_message + 112
6 libc++abi.dylib 0x00000001921f0b88 default_terminate_handler() + 300
7 libobjc.A.dylib 0x00000001929ec3bc _objc_terminate() + 124
8 libc++abi.dylib 0x00000001921edbb0 std::__terminate(void (*)()) + 12
9 libc++abi.dylib 0x00000001921ed738 __cxa_rethrow + 140
10 libobjc.A.dylib 0x00000001929ec290 objc_exception_rethrow + 40
11 CoreFoundation 0x0000000181e7d710 CFRunLoopRunSpecific + 568
12 UIKit 0x0000000186787988 -[UIApplication _run] + 548
13 UIKit 0x0000000186782980 UIApplicationMain + 1484
14 Luff 0x0000000100061c24 0x10005c000 + 23588
15 libdyld.dylib 0x000000019305aa04 start + 0

Answer 1

What you have is NOT fully symbolicated. In order to get it fully symbolicated, i.e. with the names for your functions on lines 14 and 1, and the last exception backtrace, you need the dSYM file which would have been generated when you built the app for submission and placed in the same folder as your app bundle. If you used Xcode's archive functionality, I believe the dSYM is included in the archive. I say lines 1 and 14 because those are the ones that have your app name on them (Luff).
What you need to do is put the crash report, dSYM file and app file (not the IPA) in the same folder (I'm not sure if the app file is actually necessary for Xcode to symbolicate, therefore make sure it is there if it doesn't work with just the crash report and dSYM). Then, import the crash report into the Xcode organizer and click "Re-symbolicate".
What you have above as it is right now is 100% useless without the dSYM, unless you can somehow map the addresses in the report to symbols (functions, methods).
Also, the stack trace of the crashed thread is not where the relevant info is. From experience, I can tell you a couple of things about that stack trace, though. The symbol on line 14 is most likely your main() function. Nothing special there.
The lines between 1 and 14 show a bunch of exception rethrow and catch, i.e. that is not the stack trace that led to the crash, but the stacktrace of the exception being passed around. Since you mentioned you have Crashlytics, I bet line 14 is just that. It says Luff and not Crashlytics because Crashlytics is a static library embedded into your app. For all intents and purposes, iOS sees it as just another part of your app. The reason I say it is Crashlytics is when you are catching crashes, the thing that caused the crash (exception, signal, etc.) is sometimes rethrown and it eventually reaches your own custom crash-reporting code.
The relevant info is in the Last Exception Backtrace addresses you have above. But to read that, it has to be symbolicated with the dSYM file.
Like you said, Crashlytics is not real-time. The user needs to reopen the app. I know all this because I'm working on my own project called Crashional which is real-time, provided there is an internet connection.

Answer 2

A possible reason that you did not get a report through Crashlytics is that the reviewer may have had internet disabled on the device when she first launched your app. Even if she opened it again, it would not have sent the crash back to Crashlytics.