On Monday, April 6th, I documented more of my source code for Mancala, and tried to look at the crashlog I received from a tester in TestFlight. Usually when you get a crashlog from TestFlight you open it in Xcode and a backtrace will be shown just like when you are debugging and hit a break point, except not while the app is executing. However, my crashlog was pointing to lines of code that did not make sense. Several sources say you need to symbolicate the crashlog, which means translating the references to your code’s functions from the raw memory addresses in the crashlog to the meaningful identifiers of your classes and methods.
From what I researched it seems like this should only be the case when you are getting a crash log from a release build, i.e. from a user who downloaded your published app who sends you the crashlog from their physical device (requiring them to sync with iTunes). My crashlog came from a TestFlight user on build 1.2.2 and the backtrace seemed to be symbolicated incorrectly, even though I kept my archive of that build and I have the dSYM file. I realized that because I have edited the source code since releasing test build 1.2.2, my source code won’t line up with where the crashlog is expecting each line of code to be when I view it in Xcode.
The Solution
If I had been more regularly using Git, I could just revert to a commit from the time I released build 1.2.2. Unfortunately I have only been making commits whenever I made fundamental changes to the code base and created milestone branches. So the best thing I can do now is to release a new build, 1.2.3, and create a new branch for that build. Then, I will make a new branch for 1.2.4 and work on that one until I am ready to release that to TestFlight. This way, when any testers who are on 1.2.3 have a crash and submit a report, I can roll-back to 1.2.3 and the crash log will sync up with my code. As for the crash that just occurred for a user on 1.2.2, I can only hope that my changes have addressed the bug.
‹ ›