1. 14
  1.  

  2. 1

    I think there’s a plausible, entirely benign explanation for Apple’s lack of documentation about the things that are required to implement a crash reporter. Perhaps they truly believe that crash reporting should be the responsibility of the platform, not the application. They clearly believe this is the case for app installation and updates, though they do tolerate sideloading on Mac.

    In general, I think it’s sensible for a platform owner, having learned the lessons of the free-for-all that is Windows, to conclude that apps should be sandboxed as much as possible while still allowing them to do useful work. Delegating the installation and update processes to the platform clearly enables increased sandboxing. I don’t know if this would also be the case for forbidding an app to catch an uncaught exception and gather all of the information to write a minidump, but I wouldn’t be surprised if it was. I do know that even iOS allows third-party crash reporters, but maybe it could have even better sandboxing if it didn’t.

    1. 2

      That may explain the lack of documentation for stuff to implement a crash reporter. But it doesn’t explain the complete lack of documentation for every thing else. Ports are not purely for crash handling only.

      1. 1

        Both iOS and macOS already collect crash reports for all apps. Even unsigned apps crashing on macOS would trigger system dialog to send crash report to Apple. So you might be right.

        It’s shame they don’t let easy integration to collect those reports by the devs or to extend reported information.

      2. 1

        This is actually a very in-depth write up about implementing a cross-platform crash reporter.

        I wonder how easy I could add acrarium as backend for this, so I’m not reliant on sentry.