KSCrash used to be simple enough that a quick perusal of the source code would be enough to understand how it worked, but it's gotten big enough now that there should be some guideposts to help readers along. This document introduces you to the main code areas of KSCrash.
The heart of KSCrash lives in KSCrashC.c
This file contains all of the most important access points to the KSCrash system.
KSCrashC.c functions are also Objective-C/Swift wrapped in KSCrash.m
These are the main parts of KSCrashC.c:
kscrash_install() installs and prepares the KSCrash system to handle crashes. You can configure KSCrash using the various configuration functions in this file (kscrash_setMonitoring() and such) before or after install.
All of the main configuration settings are set via kscrash_setXYZ().
Apple operating environments offer a number of notifications that tell you the current app state. These are hooked into various kscrash_notifyXYZ() functions.
The function onCrash is the main function called after a crash is reported. It handles examining the application state, writing the JSON crash report, and then allowing the crash to take its natural course.
This file also contains the low level primitive functions for managing crash reports: kscrash_getReportCount(), kscrash_getReportIDs(), kscrash_readReport(), kscrash_deleteReportWithID()
You can use kscrash_setMonitoring() to effectively enable or disable crash reporting at runtime.
Crashes are detected via one of the monitors, which set up the data in a consistent way before passing control to the function onCrash(). These files are a bit tricky because some of them have to jump through a few hoops to get around OS differences, system idiosyncrasies, and just plain bugs.
Crashes are recorded to a JSON file via kscrashreport_writeStandardReport() in KSCrashReport.c. It makes use of a number of tools to accomplish this.
Report management is primarily done in KSCrashReportStore.c
Reporting is done using a probably-overcomplicated system of filters and sinks. Generally, to adapt KSCrash to your needs, you'd create your own sink.
The installation system was an attempt to make the user API a little easier by hiding most of the filter/sink stuff behind a simpler interface. Its success is debatable...
No code depends on the installation code, and KSCrash can actually work just fine without it.