On Apple platforms, we rely on the system crash tracer, which collects a crash report once a process crashes and handles symbolication of the backtrace. It might be interesting to consider a similar out-of-process monitor-based approach for the server, since in-process signal handlers might fail to capture some forms of failure (particularly SIGKILLs) and could interfere with an app's own signal handlers.
We've also been looking into addressing shortcomings of backtrace symbolication itself in Swift, and looking for ways we can improve that which would likely benefit both Apple and server platforms. Traditional backtrace libraries which merely walk a callstack and rely on the symbol table for symbolication are limited in how well they can deal with inline frames. Something that uses DWARF debug info to symbolicate backtraces could give a more accurate account of inlined functions. On Apple platforms, the inessential debug info is separated from the binary so that customer machines don't need to download it, but the developer can use the debug info to symbolicate crash reports on their end; this separation of concerns may be less important on the server, though.
On a related note, Swift uses trap instructions for safety checks, and although these instructions are uniqued for each trap reason, and the instructions are associated with source locations for the trap reason in DWARF, there's no more detailed accounting of the reason for the trap. We've been discussing ways we might be able to record richer messages for these traps in debug info as well.