4.4.8

This release resolves a dependency hell scenario when using this package along with swift-bson, due to a shared swift-hash dependency.

Full Changelog: 4.4.7...4.4.8

4.4.7

What's Changed

enable building the package on tvOS, visionOS, and watchOS by @tayloraswift in #80

Full Changelog: 4.4.6...4.4.7

4.4.6

What's Changed

• add support for static linux sdk by @ohbargain in #79

Full Changelog: 4.4.5...4.4.6

4.4.5

What's Changed

• validate docs by @tayloraswift in #75
• Support older Apple platforms by @stackotter in #76

New Contributors

• @stackotter made their first contribution in #76

Full Changelog: 4.4.4...4.4.5

4.4.4

this release works around a source compatibility bug in the Swift compiler, enabling the library to be used with the Xcode 17 beta. this release is a temporary accommodation for macOS users that will no longer be necessary after the Swift 6.0 release, as the upstream bug has already been fixed.

4.4.1

this release patches a critical vulnerability that occurs when the DEFLATE backend attempts to compress very short inputs (less than 3 bytes) causing a runtime crash.

for applications using the library for PNG compression, the attack is only effective if the server is asked to compress a 1x1 pixel grayscale image, as all other types of PNG images create data streams that are longer than 2 bytes.

all Swift PNG users are advised to upgrade to 4.4.1 immediately.

4.4

Swift PNG 4.4 adds gzip compression and decompression tools to the LZ77 module, and updates the documentation with examples of how to use gzip compression in your app.

Internally, Swift PNG 4.4 also adopts nested protocols (SE-0404), which makes the documentation easier to navigate but should be an API-transparent change, as all of these protocols were already informally namespaced via typealiases.

Swift PNG 4.4 requires Swift 5.10 or newer.

Why use Swift PNG’s gzip implementation?

Swift PNG’s native Swift gzip implementation is not as fast as some existing C libraries which are found on many systems. However, a lot of optimization work went into the LZ77 module long ago, and the Swift version should not be significantly slower than an equivalent C library.

Applications that compress large volumes of data and do little else may be better off calling a system C library instead of using LZ77. However the complexity of marshaling data through a C library can often be a disincentive to using compression in more peripheral use cases, and having a convenient, portable Swift library available that still performs reasonably well can help make applications more efficient overall.

Why is the gzip library still part of Swift PNG?

The compression backend was written long ago exclusively for Swift PNG, and the decision to expose it to external clients was only made recently. The PNG library helps us test the correctness of the gzip backend, as the PNG format is little more than a wrapper around an LZ77 data stream.

Applications that depend on the LZ77 target only will not pull in PNG-related code.

How can I help?

Rewriting the project’s benchmarks to use the more-modern package-benchmark framework would help us gain better visibility into how the library is performing relative to system C libraries. PRs that add benchmark integrations to the project are likely to be merged.

4.3.0

This release is almost entirely focused on documentation, as much of the library’s existing docs had rotted due to evolution of tooling. We have rewritten the package’s examples and tutorials and repaired scores of broken doccomments, and the package’s documentation is now available on swiftinit.org.

4.1

This release is focused on separating out the LZ77/DEFLATE implementation from the rest of the library, and making it available for use as a general-purpose data compressor. The package now vends a separate library target, LZ77, which exposes the DEFLATE implementation.

Currently, only the deflate wrapper format is supported, although we plan on supporting the gzip wrapper format in a future release. An example of how to use the new API can be found in the BasicCompression.swift snippet.

While preparing this release, it was discovered that SIMD-accelerated encoding backend was broken on Apple Silicon; a problem that was only uncovered upon upgrading the CI runners to macOS 14. This bug has been fixed in 4.1.

Swift PNG 4.0.1

Minor concurrency patch: Adds Sendable conformances to the built-in generic RGBA<T> and VA<T> types.