I've spent quite a bit of time doing native desktop development in C++, and one thing that background has made me particularly aware of is that not every crash in a Flutter application is a Dart exception, something that became evident in my latest proprietary project, it being a desktop app relying on many native integration packages.

A segfault in a native library, an access violation in some FFI code, or a crash in the engine itself can take down the entire process before Dart gets a chance to do anything about it.

That's why I built fl_crashpad, a Flutter package that brings Google's Crashpad into Flutter applications.

Resources:

• Pub: https://pub.dev/packages/fl_crashpad
• GitHub: https://github.com/ConnectingTheDots-DCWK/fl_crashpad

Why not just use Sentry or Firebase Crashlytics?

Those are perfectly valid solutions, especially if you want a complete observability platform. But I didn't want another all-in-one service for my own applications.

I wanted something smaller and more independent: native crash capture, with fine-grained control over what happens to the resulting reports.

I'm also extremely attentive to user privacy and therefore the data my applications send outside the user's machine. I try to ship the absolute minimum necessary, and crash reporting is one of those areas where it's easy to collect far more than you actually need.

Features in detail:

• Privacy first: Minidumps can contain sensitive information, so the package includes built-in sanitization for data such as usernames and time zones to reduce the amount of potentially identifying information that leaves the user's machine.
• Full control over data flow: Keep reports on disk, inspect or delete them, or transfer them using your own infrastructure. An optional upload mechanism supports a purposefully configured remote minidump endpoint.
• Cross-platform support: Linux, Windows, macOS, Android and iOS, with platform-specific implementation details handled by the package.
• Diagnostic context: Add fixed and runtime annotations, along with attachments, to provide additional context for captured crashes.

Personal Notes:

• For my own apps, I don't even use the built-in remote minidump backend. I use my own Supabase Storage endpoint to transfer reports, the package doesn't need to know which storage provider you use. You know where the report lives on disk, and you decide how to move it, when to do so, and which endpoint receives it.
• Sanitization isn't a guarantee that every possible secret has been removed from a minidump. It's one layer of protection, and the data flow still needs to be designed carefully. But I wanted privacy to be a consideration in the implementation itself, not something left entirely to the application developer.

Feedback, questions, and criticism are very welcome!