Swiftpack.co - tsolomko/SWCompression as Swift Package

Swiftpack.co is a collection of thousands of indexed Swift packages. Search packages.
See all packages published by tsolomko.
tsolomko/SWCompression v4.0.0
A Swift framework for working with compression, archives and containers.
⭐️ 157
🕓 4 days ago
.package(url: "https://github.com/tsolomko/SWCompression.git", from: "v4.0.0")


Swift 5.1+ GitHub license Build Status

A framework with (de)compression algorithms and functions for working with various archives and containers.

What is this?

SWCompression is a framework with a collection of functions for:

  1. Decompression (and sometimes compression) using different algorithms.
  2. Reading (and sometimes writing) archives of different formats.
  3. Reading (and sometimes writing) containers such as ZIP, TAR and 7-Zip.

It also works on Apple platforms, Linux, and Windows.

All features are listed in the tables below. "TBD" means that feature is planned but not implemented (yet).

Deflate BZip2 LZMA/LZMA2 LZ4
Compression TBD
Zlib GZip XZ ZIP TAR 7-Zip

Also, SWCompression is written with Swift only.


SWCompression can be integrated into your project using Swift Package Manager, CocoaPods, or Carthage.

Swift Package Manager

To install using SPM, add SWCompression to you package dependencies and specify it as a dependency for your target, e.g.:

import PackageDescription

let package = Package(
    name: "PackageName",
    dependencies: [
        .package(url: "https://github.com/tsolomko/SWCompression.git",
                 from: "4.7.0")
    targets: [
            name: "TargetName",
            dependencies: ["SWCompression"]

More details you can find in Swift Package Manager's Documentation.


Add pod 'SWCompression', '~> 4.7' and use_frameworks! lines to your Podfile.

To complete installation, run pod install.

If you need only some parts of framework, you can install only them using sub-podspecs. Available subspecs:

  • SWCompression/BZip2
  • SWCompression/Deflate
  • SWCompression/Gzip
  • SWCompression/LZMA
  • SWCompression/LZMA2
  • SWCompression/LZ4
  • SWCompression/SevenZip
  • SWCompression/TAR
  • SWCompression/XZ
  • SWCompression/Zlib
  • SWCompression/ZIP

"Optional Dependencies"

For both ZIP and 7-Zip there is the most commonly used compression method: Deflate and LZMA/LZMA2 correspondingly. Thus, SWCompression/ZIP subspec has SWCompression/Deflate subspec as a dependency and SWCompression/LZMA subspec is a dependency for SWCompression/SevenZip.

But both of these formats also support other compression methods, and some of them are implemented in SWCompression. For CocoaPods configurations there are some sort of 'optional dependencies' for such compression methods.

"Optional dependency" in this context means that SWCompression/ZIP or SWCompression/7-Zip will support a compression method only if a corresponding subspec is expicitly specified in your Podfile and installed.

List of "optional dependecies":

  • For SWCompression/ZIP:
    • SWCompression/BZip2
    • SWCompression/LZMA
  • For SWCompression/SevenZip:
    • SWCompression/BZip2
    • SWCompression/Deflate
    • SWCompression/LZ4

Note: If you use Swift Package Manager or Carthage you always have everything (ZIP and 7-Zip are built with Deflate, BZip2, LZMA/LZMA2 and LZ4 support).


Add to your Cartfile github "tsolomko/SWCompression" ~> 4.7.


  1. If you use Xcode 12 or later you should run carthage update --use-xcframeworks. After that drag and drop both SWCompression.xcframework and BitByteData.xcframework files from from the Carthage/Build/ directory into the "Frameworks, Libraries, and Embedded Content" section of your target's "General" tab in Xcode.

  2. If you use Xcode 11 or earlier you should run carthage update. After that drag and drop both SWCompression.framework and BitByteData.framework files from from the Carthage/Build/<platform>/ directory into the "Embedded Binaries" section of your target's "General" tab in Xcode.

For Xcode 12 or later you can currently also use the xconfig workaround.

Please also note that support for non-xcframework method of installing SWCompression is likely to be dropped in the future major update.


Basic Example

For example, if you want to decompress "deflated" data just use:

// let data = <Your compressed data>
let decompressedData = try? Deflate.decompress(data: data)

However, it is unlikely that you will encounter deflated data outside of any archive. So, in the case of GZip archive you should use:

let decompressedData = try? GzipArchive.unarchive(archive: data)

Handling Errors

Most SWCompression functions can throw errors and you are responsible for handling them. If you look at the list of available error types and their cases, you may be frightened by their number. However, most of the cases (such as XZError.wrongMagic) exist for diagnostic purposes.

Thus, you only need to handle the most common type of error for your archive/algorithm. For example:

do {
    // let data = <Your compressed data>
    let decompressedData = try XZArchive.unarchive(archive: data)
} catch let error as XZError {
    // <handle XZ related error here>
} catch let error {
    // <handle all other errors here>


Every function or type of SWCompression's public API is documented. This documentation can be found at its own website or via a slightly shorter link: swcompression.tsolomko.me

Sophisticated example

There is a small command-line program, "swcomp", which is included in this repository in "Sources/swcomp". To build it you need to uncomment several lines in "Package.swift" and run swift build -c release.


Whether you find a bug, have a suggestion, idea, feedback or something else, please create an issue on GitHub. If you have any questions, you can ask them on the Discussions page.

In the case of a bug, it will be especially helpful if you attach a file (archive, etc.) that caused the bug to occur.

If you'd like to contribute, please create a pull request on GitHub.

Note: If you are considering working on SWCompression, please note that Xcode project (SWCompression.xcodeproj) was created manually and you shouldn't use swift package generate-xcodeproj command.

Executing tests locally

If you want to run tests on your computer, you need to do a couple of additional steps after cloning the repository:

./utils.py download-bbd-macos
git submodule update --init --recursive
cd "Tests/Test Files"
cp gitattributes-copy .gitattributes
git lfs pull
git lfs checkout

The first command will download the BitByteData dependency, which requires having Carthage installed. When using Xcode 12 or later, you should also pass the --xcf option, or use the xconfig workaround. Please note that when building SWCompression's Xcode project you may see ld warnings about a directory not being found. These are expected and harmless. Finally, you should keep in mind that support for non-xcframework method of installing dependencies is likely to be dropped in the future major update.

The remaining commands will download the files used in tests. These files are stored in a separate repository, using Git LFS. There are two reasons for this complicated setup. Firstly, some of these files can be quite big, and it would be unfortunate if the users of SWCompression had to download them during the installation. Secondly, Swift Package Manager and contemporary versions of Xcode don't always work well with git-lfs-enabled repositories. To prevent any potential problems test files were moved into another repository.

Please note, that if you want to add a new type of test files, in addition to running git lfs track, you have to also copy into the "Tests/Test Files/gitattributes-copy" file a line this command adds to the "Tests/Test Files/.gitattributes" file. Do not commit the ".gitattributes" file to the git history. It is git-ignored for a reason!

Please also be mindful of Git LFS bandwidth quota on GitHub: try to limit downloading lfs'd files using git lfs pull. In CI we use some caching techniques to help with the quota, so if you're going to add new tests that require several new test files you should try to submit them all together to reduce the amount of times CI needs to recreate the cache (recreating the cache requires to do git lfs pull for all test files).


Using whole module optimizations is recommended for the best performance. They are enabled by default in the Release build configuration.

Tests Results document contains results of benchmarking of various functions.


First of all, existing solutions for working with compression, archives and containers have certain disadvantages. They might not support a particular compression algorithm or archive format and they all have different APIs, which sometimes can be slightly confusing for users, especially when you mix different libraries in one project. This project attempts to provide missing (and sometimes existing) functionality through the unified API which is easy to use and remember.

Secondly, in some cases it may be important to have a compression framework written entirely in Swift, without relying on either system libraries or solutions implemented in other languages. Additionaly, since SWCompression is written completely in Swift without Objective-C, it can also be used on Linux.

Future plans

  • Performance...
  • Better Deflate compression.
  • Something else...


MIT licensed



Stars: 157
Last commit: 4 days ago
jonrohan Something's broken? Yell at me @ptrpavlik. Praise and feedback (and money) is also welcome.

Release Notes

4 days ago

Big thanks to @philmitchell for finding a solution (#29) to the problem of high memory usage in the new APIs!

  • Added the TarReader and TarWriter structs which allow for more iterative work with TAR containers while helping to reduce the peak memory usage (#28).

Comment: It is highly recommended to review the documentation for the new functionality (TarReader and TarWriter), as there are some limitations on how it can be used.

  • Fixed a crash that could occur when decompressing Deflate and BZip2 inputs truncated in a certain way (#30).

Comment: Unfortunately, this fix has a negative impact on performance, but there are plans to mitigate this issue in the near future.

  • In the API reference documentation website the Container category has been split into separate categories for each container type.
  • swcomp changes:
    • Certain error messages were made a bit clearer.
    • Added reader-tar and writer-tar subcommands to the benchmark command.
    • Changed the printing format of the benchmark speed. Comment: Arguably, the new way of speed printing format is worse than the previous one (only one digit of precision, non-adjustable locale-awareness, etc.), as such there are plans to revert to the previous behavior in the near future.

Swiftpack is being maintained by Petr Pavlik | @ptrpavlik | @swiftpackco | API | Analytics