Crash analyzing tool in Framework

Question

My team is developing an iOS framework for the clients to use, and we came upon a bottleneck when we wanted to have some sort of crash reporting tool(such as Crashlytics, KSCrash, etc.) in our framework so we can track down the crashes when clients are using our framework in their app.

However, the problem was that these 3rd party crash reporting tools don't seem to work if both (framework and client) are using the same crash reporting tool. For example, if our framework and client app both depend on Crashlytics to report crashes, it wouldn't work because of restricted API. Most other open source projects almost all the time uses sharedInstance to initialize the class. So, this wouldn't work either.

My question is... I'm sure there are companies and software out there that use some sort of crash reporting tools to analyze crashes on their own frameworks that they distributed to many clients. How is this done? Any insights?

Answer 1

I'm a former maintainer of the Crashlytics SDKs for Apple platforms. I've been asked this a number of times, by some highly popular framework vendors in the past. And, I've devoted a significant amount of work into these areas - reporting tool interoperability and non-host app reporting.

I'd like to get into a little more detail as to why this is so difficult.

Problem 1: Crashes are inherently per-process

The problem you've noticed so far is related to the reporting frameworks' APIs, but the issues go way deeper. A crash brings down the entire process. The facilities that exist on iOS (macOS, tvOS) cannot be applied on a per-library basis. (I believe some can be per-thread, but I'm not sure that actually buys you anything.)

This is the core reason why interoperability, even with Apple's own ReportCrash, is so challenging. In-process reporting tools setup their machinery, and then expect their setup to remain unchanged when a crash actually occurs. Two copies of this machinery (ie, two Crashlytics) doesn't make sense. There can only be one, because the resources being used only exist on a per-process basis.

Often, a reporting tool needs to make trade-offs between the best possible reporting, and the best possible interoperability. On example, if I remember correctly, is that if you use both Crashlytics and KSCrash in the same process, Crashlytics' ability to correctly capture information about C++ exceptions is compromised.

Problem 2: Who owns the crash?

Ignoring problem 1, how should the reporter know that a crash is a library vs the app? This is broad topic, that basically gets down to the core issue of crash responsibility. A crash is an effect, but most developers don't immediately think of crashes this way. When you want to fix a crash, you need a cause. Determining that a library is the cause is not easy. Before you think "shouldn't it just give me the crashes with my library's frames in it?", imagine that was how it worked for UIKit or Foundation.

There are many ways to approach this issue. However, without digressing here too much, I believe a crash is always owned by a host application, but could also be interesting to third-parties. This brings up a whole other host of issues, including authenticating library owners and dealing with the privacy/security implications for the host app. It's a whole thing.

Regardless of how you approach this, I think the solution can only be done server-side, with the reporting service. They could, in theory, grab the report and do this analysis. Crashlytics' Insights system is a step in this direction. However, it currently does not offer a library vendor the ability to see these reports. Its focus is more on connecting the crash (an effect) with a well-known cause (or class of causes).

Summary

Trying to make your library as stable as possible is an excellent goal. Unfortunately, I just don't think it can be done with dedicated in-process reporting.

What you should actually do is help your client developers better understand what your library is doing. So, when it does crash, then can debug more easily and report it to you.

• Name all of your queues/threads
• Include some kind of logging facility
• Be aggressive about checking for valid parameters/input
• make errors you pass back from your APIs as descriptive and comprehensive as you can
• Don't ever Assert in production (I feel the opposite about this for host applications)
• Never throw ObjC and/or C++ exceptions
• Never, ever @catch/catch in your code
• check out the NSProcessInfo APIs, which can help better expose what your library is doing during debugging

I hope this is helpful, even though it doesn't really get you where you wanted.