When there is a crash in a iOS native app, we can get information from the customer to check where the error is.
What do we have to do?
First of all, before sending the .ipa to your customer you should have stored the dSYM file for this build.
It is not possible to trying to generate it afterwards. Although we move to the same commit where this build was done and the app has the same code, the dSYM file generated will not be useful.
This is said in the apple documentation about it:
The Debug Symbol file and application binary are tied together on a per-build-basis by the build UUID. A new UUID is generated for each build of your application and uniquely identifies that build. Even if a functionally-identical executable is rebuilt from the same source code, with the same compiler settings, it will have a different build UUID. Debug Symbol files from subsequent builds, even from the same source files, will not interoperate with binaries from other builds.
What does the customer should do when there is a crash?
We will need the customer to get the crash report file from the device, which extension is .ips.
Depending on the version, it is placed in one place or another. For ios 10 or above it is in Settings –> Privacy –> Analytics –> Analytics Data.
The name of the app contains the app name and the date.
If you had stored the dSYM file, you can keep reading this section. If not, you could go to the next section of the post.
What it is the next step?
Once the customer has sent us the .ips file, we modify the extension to .crash.
If we open it, we can see that it contains backtrace addresses.
Example:
Last Exception Backtrace:
(0x1fd1c7ea0 0x1fc399a40 0x1fd0ce674 0x1fdb46c64 0x1fdb46bcc 0x10227193c 0x10227257c 0x1fcc02484 0x1fcba46d8 0x1fdf7fa14 0x1fd1581cc 0x1fd15814c 0x1fd157a84 0x1fd1528fc 0x1fd1521cc 0x1ff3c9584 0x22a24d054 0x1022847cc 0x1fcc12bb4)
And then we have to symbolicate the file.
What is this?
In the apple documentation it is said:
Symbolication is the process of resolving backtrace addresses to source code method or function names, known as symbols.
This is the command that we can use to achieve that:
symbolicatecrash MyApp_2019-05-09_Device.crash MyApp.app.dSYM
If it works, it will return the crash file “translated”.
Example:
Last Exception Backtrace:
0 CoreFoundation 0x1fd1c7ea0 __exceptionPreprocess + 228
1 libobjc.A.dylib 0x1fc399a40 objc_exception_throw + 55
2 CoreFoundation 0x1fd0ce674 +[NSException raise:format:] + 115
3 Foundation 0x1fdb46c64 -[NSPlaceholderString initWithFormat:locale:arguments:] + 123
4 Foundation 0x1fdb46bcc +[NSString stringWithFormat:] + 67
5 MyApp 0x10227193c +[ABNotifier showNoticeAlertForNoticesWithPaths:] + 39228 (ABNotifier.m:693)
6 MyApp 0x10227257c __ABNotifierReachabilityDidChange_block_invoke + 42364 (ABNotifier.m:836)
7 libdispatch.dylib 0x1fcc02484 _dispatch_client_callout + 15
8 libdispatch.dylib 0x1fcba46d8 _dispatch_once_callout + 27
9 SystemConfiguration 0x1fdf7fa14 reachPerformAndUnlock + 539
10 CoreFoundation 0x1fd1581cc __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 23
11 CoreFoundation 0x1fd15814c __CFRunLoopDoSource0 + 87
12 CoreFoundation 0x1fd157a84 __CFRunLoopDoSources0 + 259
13 CoreFoundation 0x1fd1528fc __CFRunLoopRun + 1039
14 CoreFoundation 0x1fd1521cc CFRunLoopRunSpecific + 435
15 GraphicsServices 0x1ff3c9584 GSEventRunModal + 99
16 UIKitCore 0x22a24d054 UIApplicationMain + 211
17 MyApp 0x1022847cc main + 116684 (main.m:15)
18 libdyld.dylib 0x1fcc12bb4 start + 3
And then following this trace, we might be able to find the problem that causes the crashes.
But, what happens if we have not stored the dSYM file?
If we did not archive the dSYM file, the first thing we should do is to start storing them.
Now, we can see workarounds that might work to symbolicate the crash file.
Although we will need to use the same terminal that generated the binary, otherwise it is not going to work.
Import the file to XCode.
In order to do that, you’ll need to do two things first: modify the extension of the file to .crash and to have one device connected to your mac.
Then, using XCode, click in the Window menu and select Devices.
Then select the connected device to see the information panel. Click on “View Device Logs” button. Then select the “All logs” tab and drag&drop the .crash file into the left panel.
Click in the right button, and select “Re-symbolicate log”.
It might work and symbolicate the file, then you will be able to find the problem.
If it does not work, you can tried another option.
Attempt to use symbolicatecrash without the dSYM file
The command is generally use like this:
symbolicatecrash MyApp_2019-05-09_Device.crash MyApp.app.dSYM
But we can leave off the dSYM file parameter like this
symbolicatecrash app.crash
As in the tip above, it might work. If it does, you can now check where it fails.
Error when using symbolicatecrash
If you get an error saying command not found when executing symbolicatecrash, you can execute this
find /Applications/Xcode.app –name symbolicatecrash –type f
and select the full path to the command.
if you get another error saying that DEVELOPER_DIR is not found, you should run:
export DEVELOPER_DIR=‘/Applications/Xcode.app/Contents/Developer’
Were you lucky?
Anyway, remember to store the dSYM file from now on.
Besides you can think about integrating a monitoring service for logging the errors. We can talk about it in another article.
