# GzipSwift: gzip and gunzip on Data through zlib

> GzipSwift is a small Swift package that adds gzip and gunzip to Data by wrapping zlib, installable through Swift Package Manager and working on macOS, iOS, watchOS, visionOS, tvOS and Linux. It needs no privacy manifest, and on Linux the only real work is getting zlib and its linker path right.

**1024jp/GzipSwift** — Swift package that enables gzip/gunzip Data using zlib

- Repository: https://github.com/1024jp/GzipSwift
- Stars: 594 · Forks: 153
- Language: Swift
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/1024jp-gzipswift

## What GzipSwift actually provides

GzipSwift is a framework with an extension of Data written in Swift, and it enables compress and decompress of gzip using zlib.

That is the entire scope, and it is worth being clear about it at the start. This is not a compression library in general. It is gzip, over zlib, exposed as methods on the standard Data type, so the language's own data container becomes the thing you compress.

The platform list in the project documentation is broad for a package this small. The badge names macOS, iOS, watchOS, visionOS, tvOS and Linux, and the repository topics add carthage, cocoapods, framework, gzip, spm, swift and zlib, which tells you the package has been distributed through more than one dependency manager over its life.

One detail that matters for App Store submission and for anyone auditing the app's privacy declarations: GzipSwift requires no privacy manifests, since it does not access any privacy information. For a compression library that is obvious, but it is documented explicitly, which means a team assembling a privacy manifest file for its app has one fewer dependency to reason about.

The users are Swift developers who need to interoperate with gzip data: reading a compressed response body, writing a compressed payload, or handling a file format that stores its content gzipped. The alternative for most of them would be writing their own bridging header and calling zlib by hand, which is exactly the work this package removes.

## The Data extension API and the isGzipped check

The usage example in the documentation is short enough to hold in your head, and it covers the whole surface.

```swift
import Gzip

// gzip
let compressedData: Data = try data.gzipped()
let optimizedData: Data = try data.gzipped(level: .bestCompression)

// gunzip
let decompressedData: Data
if data.isGzipped {
    decompressedData = try data.gunzipped()
} else {
    decompressedData = data
}
```

There are four things to notice. The import is Gzip, not GzipSwift, so the module name and the repository name differ, which is the kind of detail that catches people out when they add the dependency and then fail to compile.

Both operations are throwing, so a corrupt or truncated gzip payload surfaces as an error you have to handle rather than as silently empty data. There is a compression level parameter, with the example using.bestCompression, so the trade between size and time is under your control rather than fixed.

The isGzipped property is the most useful of the three, because real inputs are not uniformly compressed. A server that sometimes gzips a response and sometimes does not is a normal case, and checking the property before decompressing is more correct than assuming one or the other.

The decompression example does exactly that: it checks, and falls back to using the data as-is when it is not gzipped.

## Adding the package with Swift Package Manager

GzipSwift is SwiftPM-compatible, and the install path is to add the package to your Package.swift or to your Xcode project.

The manifest entry is:

```swift
dependencies: [
    .package(name: "Gzip", url: "https://github.com/1024jp/GzipSwift", from: Version(7, 0, 0)),
],
```

Two details to notice. The package is declared with the name Gzip, matching the module you import, and the version requirement starts at 7.0.0, so SwiftPM will resolve to the 7.x line and above.

The repository also contains a Package.swift at the root, a Sources/ directory, a Tests/ directory, a CHANGELOG.md, a CODE_OF_CONDUCT.md and a.swiftlint.yml file. The presence of the SwiftLint configuration tells you the project lints its own source, which is a small but useful signal about whether the maintainer keeps the code tidy.

Because the repository name and the module name differ, and because the version in the manifest is a minimum rather than a pin, it is worth checking the CHANGELOG.md before you bump the requirement.

## Linux needs zlib and a linker path

The Apple platforms need nothing beyond the package itself, but the Linux instructions are three numbered steps and the third one is where people get stuck.

First, install zlib if it is not there yet:

```bash
    $ apt-get install zlib1g-dev
```

Second, add the package to your package.swift, which is the same manifest entry as everywhere else.

Third, and this is the one to bookmark, is what to do if the Swift build fails with a linker error. Check whether libz.so is in your /usr/local/lib. If it is not, reinstall zlib as in step one. If it is there, the documentation says to link the library manually by passing the linker option -Xlinker -L/usr/local/lib with swift build. Those two values, the option and the directory, are what the build needs.

The root cause is that a Swift package built on Linux still has to find the native zlib library, and where the system puts it varies by distribution and by whether somebody built zlib from source into /usr/local. That is the entire Linux story, and it is a fair price for a package that wraps a C library.

## Where GzipSwift is the wrong tool

The first limit is format. GzipSwift handles gzip and nothing else. If you need zlib format without a gzip header, bzip2, xz, zstd, LZ4 or brotli, this package does not help, and the compression level parameter does not change that. A project that needs to negotiate content encoding with a server that offers several options needs a broader library.

The second is that there is no streaming API here. The API is Data in, Data out, which means a large file has to be held in memory as a whole on both sides of the operation. For a multi gigabyte archive on a device with limited memory, that is a real constraint, and the documented API gives you no way around it.

The third is the platform list, which is a strength and a limitation at once. The badge names macOS, iOS, watchOS, visionOS, tvOS and Linux, but there is no Windows in it. A Swift package that is also expected to run on Windows server would need another approach.

The fourth is the dependency on zlib itself, which on Linux means a system package that your deployment has to provide. In a container image or a Lambda style packaging, that is a build step someone has to remember.

A broader compression library covers several algorithms with a single interface, while GzipSwift is narrower and more focused, and it speaks gzip directly, including the isGzipped check that lets you branch on what a peer actually sent. If you need one algorithm and a throwing API, this package is the smaller dependency. If you need to cover several encodings uniformly, a broader library is less code overall.

## Licence, release cadence and the state of the tree

GzipSwift is distributed under the terms of the MIT License, with the copyright line reading 2014-2026 1024jp and the licence text in the LICENSE file. The MIT terms permit use, modification and redistribution in closed and open source products, and require the copyright notice and licence text to accompany copies. Read the LICENSE file yourself for the exact wording before you vendor it into a product, and keep the notice in your distribution.

The release history is short and recent. Version 6.1.0 was tagged on 2026-05-05 at 11:26 UTC and 7.0.0 on the same day at 13:54 UTC, which is worth noticing: a major version bump and its predecessor published within about two and a half hours of each other. That pattern usually means a breaking change was prepared and then shipped, so if you are moving from an older 6.x line you should read the CHANGELOG.md carefully.

The repository is not archived, and the last push was on 2026-05-10, a few days after the 7.0.0 tag. That is more than five months before the current date, so the code is not archived but the project is not being pushed to on a weekly cadence. For a package this small, that is a reasonable trade, but if you are shipping it in a product, pin the version you validated and be ready to vendor it if it goes quiet.

The tree itself is minimal and easy to audit. There is a Package.swift, the Sources/ and Tests/ directories, a README.md, a CHANGELOG.md, a CODE_OF_CONDUCT.md, a LICENSE and a .swiftlint.yml, plus .github/ and .gitignore. There is no example application and no benchmark directory, so the repository documents usage through the README example rather than through runnable samples.

## Conclusion

GzipSwift fits a Swift engineer who needs to read or write gzip data on a device or server and wants a three line API instead of a C interop layer, and the isGzipped check plus the compression level parameter cover most real uses. It does not fit a project that needs anything beyond the gzip format itself, and on Linux the zlib and linker setup is on you. Before adopting it, confirm your target platform is in the listed set, install zlib1g-dev and check that libz.so resolves on Linux, and read the CHANGELOG.md before moving past version 7.0.0, since the two most recent releases landed on the same day.

## FAQ

### How do I gzip and gunzip a Data value with GzipSwift?

Call data.gzipped() to compress and data.gunzipped() to decompress, and import the module as Gzip. You can pass a compression level such as .bestCompression to gzipped, and the isGzipped property tells you whether a payload is compressed before you try.

### How do I add GzipSwift to a Swift project?

The package is SwiftPM compatible. Add .package(name: "Gzip", url: "https://github.com/1024jp/GzipSwift", from: Version(7, 0, 0)) to the dependencies block of your Package.swift, or add the package in your Xcode project.

### What do I need to install GzipSwift on Linux?

Install zlib with apt-get install zlib1g-dev, then add the package to your manifest. If the build fails with a linker error, check whether libz.so is in /usr/local/lib and, if it is, link it manually by passing '-Xlinker -L/usr/local/lib' with swift build.

### Does GzipSwift need a privacy manifest for App Store submission?

No. The documentation states that GzipSwift requires no privacy manifests since it does not access any privacy information.

### Which platforms does GzipSwift support?

The project documentation lists macOS, iOS, watchOS, visionOS, tvOS and Linux. It is a Swift package with a SwiftPM manifest, a Sources directory, a Tests directory and a SwiftLint configuration.

## Sources

- [1024jp/GzipSwift on GitHub](https://github.com/1024jp/GzipSwift)
- [Issues](https://github.com/1024jp/GzipSwift/issues)
- [License: MIT](https://github.com/1024jp/GzipSwift/blob/main/LICENSE)
- [README](https://github.com/1024jp/GzipSwift/blob/main/README.md)
- [Releases](https://github.com/1024jp/GzipSwift/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/1024jp-gzipswift