Feature Request: Support for Zstandard (zstd) Compression
đź’ˇ Feature Proposal
Is your feature request related to a problem? Please describe.
Currently, Firebase Crashlytics (both the backend and the upload-symbols / Gradle tooling) strictly requires standard .zip (DEFLATE) archives for symbolication files like dSYMs and ProGuard mappings.
For large-scale applications, dSYM files can easily grow to several gigabytes. Compressing them with standard single-threaded zip tools slows down CI/CD pipelines significantly, while multi-threaded tools or better algorithms cannot be fully utilized because the Firebase backend rejects anything other than standard ZIP files.
Describe the solution you'd like
We would like Firebase Crashlytics to natively support Zstandard (.zst or .tar.zst) compression for symbol files uploads (via Web Console, Fastlane, and CLI/Gradle plugins).
Zstd provides a dramatically better compression/decompression speeds and ratios compared to DEFLATE (Gzip/Zip). Integrating it into the upload-symbols binary and Crashlytics backend would allow:
1. Faster archiving stages on CI runners (saving expensive compute minutes).
2. Smaller payload sizes, reducing network transit times when pushing symbols to Firebase.
Describe alternatives you've considered
- Using multi-threaded ZIP alternatives like pigz -K, which helps with CPU times but doesn't solve the compression ratio limits of the older DEFLATE algorithm.
- Uncompressing .zst archives on intermediate CI stages just to feed raw directories into upload-symbols, which wastes disk I/O and runner storage.
Additional context
Many modern engineering pipelines and data lakes have already migrated to Zstd as their default compression standard. Bringing native Zstd support to Crashlytics symbol uploads would highly optimize modern mobile CI/CD workflows (especially for heavy enterprise iOS/Android apps).
Mikhail Khadarenka
shared this idea