Apple actually tries to make sure that you are not sending data regarding the user, without the consent of the user. That’s why in HockeyApp’s SDK they present the user with a dialog that asks them whether the crash reports should be sent or not.
Now, this “gate” stops the SDK from submitting crashes to the service, until the user hits that “Allow” button. Problem is, my app was crashing on launch for a very small percentage of my users, which meant they didn’t reach a stage where they can even hit the allow button!
I was getting bad reviews, complaints, and just an angry mob running after me .. I had to do something about this Hell’s gate!
I was a bit desperate initially, so I went the HockeyApp SDK repo on github, since it is opensource, and decided, hey! I can hack the framework and try to block the main thread, pull the crash data, and submit it to my server. Then, I’ll be able to solve the problem.
Hours of running around the HockeyApp SDK yielded that I should play around with PLCrashReporter and crash signals .. To me, that meant new code I had to write, that might not even be stable enough!
I slammed my laptop in frustration..
Finally, it clicked in my head that I can go ahead with a universal approach that I can use throughout my apps! What if I just show a temporary view in the beginning with a spinner, just to wait till the user hits “allow”, and the crash is sent?
The users started seeing this screen instead of the app just crashing on launch. Even better, they were able to hit “allow”, and I get my crash report!
Time to see some code!
Let’s make one thing clear:
I am not relying on Storyboard initialization
If you rely on the app entry point being in the storyboard itself, that means your app may crash before even reaching the application did launch method! That is because the storyboard will initialize a few classes itself, before you get your chance to run your code… Now that’s no good, is it?
Please take note of these important points:
We initialize the window. We need to show something.
Then, we can create the normal app launch procedure in a closure, to save duplicate code. That code does not run immediately.
Finally, we check if the app crashed. Based on that, we either show the crash view, or call the launch procedure and resume normally.
One Last Advice
If you have a large user base, and your app actually matter, don’t use swift. Don’t even think about it. Consider it still in beta. Of course, I won’t just say that and leave, here is why.
I got about three common swift crashes that only happen with a subset of my users. The crashes are vague with a SIGTRAP signal, and to solve them, all I did was migrate away from swift closures to something else… Especially unowned self. That one’s a real pain.
Since I have more than 100k active users, a small subset of crashes is still significant! Here are a few swift crashes I got (somehow, they are also linked to FBKVOController):