Apple Archive vs zip: aa Kept 14 of 14 Attributes, zip 5

Apple Archive is the format behind macOS's aa command and the .aar files Archive Utility can open. Compared with zip on a Mac mini running macOS 26.4.1, it won on every Mac-side number I measured. On a copy of Slack.app (326 MB), aa archive made a 125.3 MB file in 0.40 seconds, and zip -r -y made 127.9 MB in 7.03 seconds. On a test folder with 14 kinds of file metadata, aa brought back all 14, zip brought back 5. The catch is outside the Mac. No tool I tried other than Apple's own could open the file. bsdtar, unzip and ditto all rejected it.

So the short answer: use .aar when the archive goes from one Mac to another Mac, or into your own backups. Use zip when anyone else might open it. The numbers below are why, plus two flags most people will need and one claim from a well-known article that didn't hold on 26.4.1.

What Apple Archive is

aa ships in /usr/bin (347,840 bytes on 26.4.1). Its man page lists five compression choices: lzfse (the default), lzma, lz4, zlib and raw. Apple documents the AppleArchive framework for Swift and C, but not the file layout. I looked at the bytes anyway. A default archive starts with pbze, the header of the block format described in the compression_tool man page: pbz plus one letter for the algorithm (e lzfse, x lzma, 4 lz4, z zlib). Piping the file through compression_tool -decode strips that layer and leaves a stream starting AA01, followed by fields like TYP, PAT, UID, MOD. A -a raw archive starts with AA01 directly.

$ aa archive -d . -subdir src -o a.aar      # default lzfse
$ head -c 4 a.aar; echo
pbze
$ compression_tool -decode -i a.aar | head -c 16 | xxd
00000000: 4141 3031 5000 5459 5031 4450 4154 5003  AA01P.TYP1DPATP.
$ aa extract -i a.aar -d out/

The block layer is also why aa is fast. Each block compresses on its own thread. The man page says the default is one worker per physical core, which is 10 on this M4. With -t 1, Slack.app took 2.19 seconds instead of 0.43, and the output was byte-for-byte the same size.

Size and speed: 3 folders, 11 methods

I archived three folders 11 ways, three runs each, and took the median. The folders were: Python 3.9's standard library from the Command Line Tools (1,635 files, 40.8 MB of mostly text), a copy of Slack.app 4.51.180 (322 files, 14 symlinks, 326.1 MB), and the 13 HEIC wallpapers in /System/Library/Desktop Pictures (256.3 MB, already compressed). The zip and tar tools were the macOS ones (Info-ZIP zip 3.0, bsdtar 3.5.3); zstd and xz came from Homebrew.

Method	Python stdlib (40.8 MB)	Slack.app (326.1 MB)	Extract Slack.app
aa lzfse (default)	10.73 MB in 0.15 s	125.3 MB in 0.40 s	0.23 s
aa -a lzma	7.93 MB in 1.28 s	89.9 MB in 9.93 s	0.49 s
aa -a lz4	16.27 MB in 0.11 s	174.7 MB in 0.11 s	0.19 s
aa -a zlib	11.79 MB in 0.18 s	128.8 MB in 0.92 s	0.20 s
ditto -c -k --sequesterRsrc	13.15 MB in 1.10 s	128.1 MB in 7.02 s	0.67 s
zip -r -y	12.55 MB in 0.63 s	127.9 MB in 7.03 s	1.52 s
tar -czf (gzip)	11.97 MB in 1.12 s	127.7 MB in 6.83 s	0.55 s
tar -cJf (xz)	7.63 MB in 6.18 s	86.2 MB in 57.4 s	2.81 s
tar | zstd -3 -T0	10.17 MB in 0.50 s	121.9 MB in 0.33 s	0.41 s
tar | zstd -19 -T0	7.92 MB in 4.83 s	96.1 MB in 14.3 s	0.46 s

Three things stand out. First, default aa beats zip on both axes: 14.5% smaller on the text-heavy folder and 2% smaller on the app, while finishing 4 to 17 times sooner. Most of the speed is threads. Single-threaded aa still beat zip on Slack.app, 2.19 s against 7.03 s, but by 3x, not 17x.

Second, aa -a lzma lands within 5% of xz on size and was 5.8 times faster on Slack.app (9.9 s against 57.4 s). macOS's tar -cJf used one core: 5.39 s of user time in 6.09 s of wall time on the stdlib folder. If you want small archives on a Mac and don't need them readable elsewhere, that is the setting.

Third, zstd is the honest competitor. At -3 with all threads it made a smaller Slack archive than aa lzfse (121.9 MB against 125.3 MB) in about the same time, and .tar.zst opens on any Linux box. It isn't on a stock Mac, though, and tar doesn't carry flags or creation dates (next section).

The HEIC folder came out at 1.000 of its input size for every method, as expected for already-compressed photos. What differed was wasted time: aa -a lzma spent 5.3 s and tar -cJf 48.4 s to save nothing, against 0.17 s for default aa. The block format in the compression_tool man page has a case for storing a block uncompressed, which fits the identical 256.32 MB output from every aa variant.

Metadata: 14 things, 5 ways back

Size is the smaller half of the comparison. The reason to pick a Mac-specific format is Mac-specific metadata, so I built a folder holding 14 kinds of it with a shell script: an executable bit, an old modification date (2005), an older creation date (2001, via SetFile -d), a custom extended attribute, a quarantine attribute, a Finder tag, a resource fork, an ACL (chmod +a "everyone deny delete"), the hidden flag, the locked flag (uchg), a symlink, a hard link pair, an empty folder, and a file name with a decomposed é. I archived and extracted it with each tool and checked every item with a Python script.

Round trip	Kept	Lost
aa archive / aa extract	14 of 14	none
Double-click .aar in Archive Utility	14 of 14	none
tar -cf / tar -xf	11 of 14	creation date, hidden flag, locked flag
ditto -c -k --sequesterRsrc / ditto -x -k	10 of 14	creation date, hidden, locked, hard link
zip -r -y / unzip	5 of 14	all 4 extended attributes, ACL, creation date, both flags, hard link
ditto's zip opened with unzip	5 of 14	same as zip, plus a __MACOSX/ folder of 16 ._ files

The last row is the one people send to Windows and Linux. My test folder had 17 files and folders, and ditto's zip held 16 AppleDouble ._ entries under __MACOSX/. I had added extended attributes to only four items. The other twelve ._ files are there because macOS 26 stamps com.apple.provenance on new files, and ditto carries every extended attribute. The ditto command on Mac post has the flag that leaves them out (--norsrc) and what zip without -y does to an app bundle's symlinks.

One more row worth knowing: aa keeps the quarantine attribute through a round trip, the same as ditto and tar. If you are cleaning a download with xattr -d and wondering why it came back after unarchiving, see No such xattr: com.apple.quarantine.

Two flags: sparse files and clones

My test folder also had a 64 MB sparse file using 16 KB on disk. Plain aa extract wrote it back as 65,536 KB, fully allocated. Adding -enable-holes brought it back at 0 KB. Archive Utility made the hole on its own (0 KB) when I opened the same .aar with open -a "Archive Utility". zip and ditto wrote it out at full size; tar restored it at 16 KB.

Clones went the other way from what I expected. Eclectic Light's 2022 look inside Apple Archive says an archive holding a file and its clone ends up "little larger" than the file alone, and that extraction writes clones out at full size. On macOS 26.4.1 with the command-line tool, I saw the opposite on both counts. Two 100 MB random files, one a cp -c clone of the other, made a 209.7 MB archive: the data stored twice. The aa man page agrees: "There is no way to deduplicate the data in the archive (by storing the data only once) from the command line." But aa list -v showed a CLC=0 clone-cluster field on both entries by default, and extracting used 100 MB of free disk space, not 200. The clone survived; the archive just doesn't save space on it. The 2022 article may have been describing the API or an older release. I only tested 26.4.1's CLI.

# sparse files come back sparse only with -enable-holes
aa extract -i backup.aar -d restore/ -enable-holes

# smaller archive, slower to make, same fast extract
aa archive -d ~/Projects -subdir site -o site.aar -a lzma

Outside the Mac

This is where .aar loses. On this Mac, bsdtar -tf a.aar said "Unrecognized archive format", unzip -l said "End-of-central-directory signature not found", and ditto -x said "cpio read error: bad file format". file calls it data. In an April 2024 developer forums thread about sending AppleArchive output to a server, Apple DTS engineer Quinn wrote that "there are no common third-party libraries for that format (IIRC the format is not documented for third-party use)".

There is one open-source reader: neoaa, an MIT-licensed CLI for Linux and macOS built on the same author's libNeoAppleArchive (11 and 43 GitHub stars when I checked, last pushed April 2026). I didn't build or test it, so I can't say how it handles the fields above. A recipient would have to install it on purpose, which is the opposite of zip.

Demand for the format outside Apple's world is also thin. A Stack Exchange API search for "Apple Archive" on Ask Different, Super User and Unix & Linux returned 0 questions, and the 4 on Stack Overflow were about other things. On Hacker News, 8 of the 10 stories matching the phrase were about Apple history archives; the 2 about the file format had 2 points each. That fits a format only Macs read.

Which one to use

• Mac to Mac, or backups you'll restore on a Mac: aa archive. It was the fastest, the smallest at default settings, and the only one that kept all 14 metadata items. Add -enable-holes on extract if you have sparse files.
• Smallest file, still Mac-only: aa -a lzma. Near xz size, far less time.
• Going to Windows, Linux or a server: zip. Use ditto -c -k --norsrc or zip -r -y so the recipient doesn't get __MACOSX.
• Going to Linux and you care about speed: tar piped through zstd -T0, if the zstd binary is installed on both ends.

For whole volumes or anything that needs to mount, a disk image is the other Mac-native option; the hdiutil on Mac post covers a crash I hit converting them. And if the archive is going over HTTP, the server's compression matters more than the format; Brotli vs gzip has what Cloudflare actually served for this site.

FAQ

Is Apple Archive better than zip?

On a Mac, yes in my tests on macOS 26.4.1: aa archive made a slightly smaller file than zip (125.3 MB against 127.9 MB for a 326 MB app, 10.7 MB against 12.6 MB for 40.8 MB of text) and was 4 to 17 times faster because it compresses on all cores. It also kept all 14 metadata items I tested, while zip kept 5. Outside a Mac, zip is better, because Linux and Windows tools can't open .aar files.

Can Windows or Linux open an .aar file?

Not with standard tools. bsdtar, unzip and ditto all rejected an .aar file on macOS 26.4.1, and Apple says the format isn't documented for third-party use. The open-source neoaa tool claims to read and write Apple Archive on Linux, but it has to be built and installed separately. If the recipient isn't on a Mac, send a zip.

How do I extract an .aar file on a Mac?

Double-click it, and Archive Utility extracts it next to the archive. In Terminal, run aa extract -i file.aar -d destination-folder. Add -enable-holes if the archive contains sparse files, or the command-line tool writes them out at full size. Archive Utility kept sparse files sparse without any option in my test.

Method: all tests ran on 2026-10-09 between 19:30 and 19:50 KST on a Mac mini M4 (Mac16,10, 10 cores, macOS 26.4.1 build 25E253) over SSH as a normal user, on the internal APFS volume with a warm file cache. Each of 11 methods ran three times per folder and the table shows medians; extract times are wall-clock with no sync, so they flatter all tools equally. Archive sizes are file sizes in bytes divided by 10^6. The metadata folder was built by a shell script and checked by a Python script using xattr, ls -le, stat and inode numbers; the provenance attribute was not counted. Slack.app was a ditto copy of the installed app and still passed codesign --verify --deep --strict after the aa round trip; diff -r against the source returned 0. Free space for the clone test came from df before and after extracting. The Stack Exchange and Hacker News counts came from their public APIs the same evening. I didn't test neoaa, encrypted .aea archives, network or external volumes, or any macOS release other than 26.4.1.