ShichiZip is a native macOS 7-Zip that previews archives in Finder

A rewrite, not a wrapper around a command line tool

The project describes itself as the missing 7-Zip derivative intended for macOS, and the feature list says the 7-Zip File Manager experience, most of it, rebuilt natively for macOS. That word natively is doing the work, because the alternative for a Mac user who wants the full set of 7-Zip formats is a command line binary and a terminal window, or a cross platform GUI that implements a subset. Here the format support is complete, everything supported by upstream 7-Zip, because the upstream code is vendored as submodules rather than reimplemented, and the parts that are new are the ones that had to be. The tree reflects that division, with the application in `ShichiZip/`, the UI and unit tests in `ShichiZipTests/` and `ShichiZipUITests/`, the project configuration and scripts in `project/`, and the upstream sources under `vendor/`. The upstream code is not hidden, it is a set of submodules with their own licences, and the README points at them for the licensing terms.

The macOS specific behaviour is the point of the rewrite

Three features are specific to the platform and are what a Mac user would notice first. The first is one click smart extraction, which auto-picks the best destination and strips duplicate top-level folders, which is the sort of thing that turns a folder called `archive` containing `archive` into something usable. The second is previewing archives in Finder, and previewing the files inside archives, with Quick Look, without extracting anything, and that is the feature that changes how you use a computer with archives on it. The third is a set of smaller macOS details, including stripping resource forks and a best-effort integration with Finder, where the best-effort qualifier is doing honest work. The result is that the application behaves like a Mac application that happens to understand 7-Zip, rather than a port that behaves like a port.

Two variants, mainline and a Zstandard fork

The releases page publishes both arm64 and x86_64 builds for the mainline and the Zstandard fork variants, and the package managers carry both under different names. In Homebrew Cask the mainline variant installs as `shichizip` and the fork as `shichizip-zs`; under MacPorts the fork uses the `+zstd` variant:

# Homebrew Cask
brew install --cask shichizip # Mainline Variant
brew install --cask shichizip-zs # Zstandard Fork Variant

# MacPorts
sudo port install shichizip # Mainline Variant
sudo port install shichizip +zstd # Zstandard Fork Variant

There is one warning attached to the package managers that is worth reading, because it affects which binary you end up with. The MacPorts version is built from source separately and is not the same binary provided in the releases. So the release artefact and the MacPorts build of the same version are not the same code path, which matters if you are checking a hash or reproducing an install. The fork exists because Zstandard support was wanted on a different timeline, and the two variants are maintained side by side rather than one replacing the other.

A tap for nightlies, and a build you can read about

If you want the nightly builds or faster updates through Homebrew, the project points at a separate Homebrew tap with its own repository and its own README:

brew tap shichizip/tap
brew install --cask shichizip # / shichizip-zs / shichizip@nightly / shichizip-zs@nightly

Building from source is documented in `BUILD.md`, which covers the prerequisites, the build steps for both variants and an overview of the project layout, and the README makes a sensible point about which document to trust, that the CI workflow in `.github/workflows/build.yml` is the canonical reference if anything in the docs falls behind. Two details in the tree hint at the toolchain. There is a `build.zig` and a `build.zig.zon`, so parts of the build are driven by Zig rather than by a shell script, and there is a `project.yml` alongside a `.swift-version` file, which is the XcodeGen pattern, where the project file is generated rather than committed by hand. The combination is a project that is explicit about how it is assembled, which is what you want from something that vendors another project's code.

The localization is three layers, and one of them is generated

Localization is the part of the documentation with the most teeth, because the rule is that upstream text is upstream text. The project keeps localization in three places. The `project/localization/Lang` directory holds the original 7-Zip language files imported from upstream, and the instruction is to treat those files as upstream input and not edit them for ShichiZip wording. `Upstream.strings` is generated from them, and the generated files are ignored by Git, so you refresh them with `xcodegen generate` or, when you only need that output, with the `python3 project/scripts/generate_strings.py` script. `App.strings` is the manual application layer, holding ShichiZip specific text and overrides for upstream text that needs different wording here, and after changing those files you run `python3 project/scripts/format_app_strings.py` to keep the keys sorted and grouped. When you work on a single locale you can pass just that file:

python3 project/scripts/format_app_strings.py ShichiZip/Resources/Localization/zh-Hans.lproj/App.strings

The Quick Action text is the third layer, under `project/localization/quick-actions`, and it is expanded into generated `InfoPlist.strings` files during the project generation.

The licence, and what the project asks of LLM contributors

The licence is LGPL-2.1, and the README gives the reason, which is only to avoid any potential licensing conflicts with the upstream code. That is a narrow and sensible reason, since the upstream 7-Zip sources are vendored as submodules and their terms live in the `vendor/` directory. The contribution policy is short and unusually specific. All types of contributions are welcome, and the project is also happy to accept contributions from an LLM, with one requirement, that the work should be reviewed carefully by a human being before submission and that you must clearly know what you are doing. That is a reasonable position for a project that vendors other people's code and cares about the provenance of what it ships. On versions, the releases are v0.3.3 in October 2026, v0.3.2 in August and v0.3.1 in August 2026, so the project is shipping small increments often, with the last push to the repository on 2026-10-19.

Editorial conclusion

ShichiZip suits a macOS user who has been unpacking archives in the command line because it supports everything upstream 7-Zip supports and adds Finder and Quick Look integration. It is a poor fit if you want a single universal binary, since the MacPorts build is compiled separately from the release artefacts and there are two variants with different Zstandard support. Before you install it, check three things: which variant you want, the mainline one or the Zstandard fork, whether you are on Apple silicon or Intel, since both are published, and the licence, because the project is LGPL-2.1 specifically to stay compatible with the upstream 7-Zip code it vendors, with the upstream terms in the submodules under `vendor/`.

Frequently asked questions

Official sources

1. idawnlight/ShichiZip on GitHub
2. Issues
3. License: LGPL-2.1
4. README
5. Releases