imessage-exporter reads the database and writes txt or html

Two crates share one workspace root

The repository is a Cargo workspace with exactly two members, and the split matters because they answer different questions:

[workspace]
resolver = "2"
members = ["imessage-database", "imessage-exporter"]

The imessage-database member is the library. It provides models that let you access iMessage information as native, cross-platform data structures, so a chat row becomes a Rust value rather than a row in a SQL table you have to shape yourself. The imessage-exporter member is the binary, and it is the part that produces files. The root README is a map rather than a manual: installation instructions for the binary sit in imessage-exporter/README.md and the library's documentation sits in imessage-database/README.md. Two other places hold detail as well, docs/features.md for the feature list and docs/faq.md for the frequently asked questions. Everything the root page offers is a pointer into those four files.

The binary writes txt or html and stops there

The output formats are the narrowest part of the whole project. The imessage-exporter binary exports iMessage data to txt or html formats, and can also run diagnostics to find problems with the iMessage database. There is no third format named in the README, which matters if your destination is a fixed format: a PDF, a spreadsheet or a database of your own is not something this binary is documented to write. The project does describe its own aims more broadly, saving, exporting, backing up and archiving iMessage data to open, portable formats, preserving multimedia content such as images, videos and audio, and facilitating migration of message history between devices and platforms. Read that as a description of what portability means here, which is text and markup, not as a promise about a file type. The library is the way out when you need a different shape.

Every operation the binary performs is read only

The key word in the project's own description is read-only. The crate ships a binary that performs read-only operations using iMessage data, and the listed capabilities line up with that: save, export, back up and archive; preserve multimedia; migrate; run diagnostics; hand you ownership and control of your communication history; and support compliance with data retention policies or legal requirements. Nothing in that list modifies a conversation, resolves a message, or writes to the database. The practical consequence is a pleasant one for an archive tool and a frustrating one for anything else: you can point it at a copy of your chat history without worrying that the run will change the source, and you cannot ask it to clean up duplicates, fill in a gap or convert the archive in place afterwards. A second consequence is where the output goes, which is entirely your choice, and the compliance framing makes clear that what happens to the exported copy is your responsibility.

Feature support is pinned to one macOS and one iOS build

The support boundary is stated in build numbers rather than in versions of the app: every iMessage feature as of macOS Golden Gate 27.2 (26B123) and iOS 27.2 (24B119). Inside that boundary the list runs from iMessage, RCS, SMS and MMS through multi-part messages, replies and threads, formatted text, attachments, expressives, tapbacks, stickers, Apple Pay, group chats, Digital Touch, URL previews, audio messages, app integrations, edited messages, business messages and handwritten messages. The wording is total for those two builds, which makes the boundary itself the important fact. Any message feature Apple adds in a later macOS or iOS build sits outside the claimed coverage until the pinned numbers move, and there is no statement in the root page about what happens to a message type the parser does not recognise. docs/features.md is where the detail lives if you need to know whether a specific construct is covered.

The format knowledge came from reverse engineering

The credits section is the most honest part of the project page, because it names where the hard knowledge came from. The iMessage database was explored and reverse engineered with SQLiteFlow, described as the SQL viewer used for that work. The payload_data plist format was reverse engineered with Xplist, called an invaluable tool for the job. Esoteric unicode questions were answered with Compart, and the typedstream format was worked on with source code referenced from the GNU Project and hosted on Archive.org. That list explains the structure of the project. Because Apple's storage formats are not a published specification, the library is maintained against observed behaviour and against archived copies of system source, and every new OS build can introduce a construct that has to be picked apart again. The default branch is develop, which is also a signal about how this work is organised.

The release profile aborts instead of unwinding

The workspace manifest is short, and the release profile is the part with consequences:

[profile.release]
lto = true
codegen-units = 1
panic = "abort"

Link time optimization is on, the whole build shares a single codegen unit, and panics abort the process rather than unwinding the stack. That last line is a real behavioural choice rather than a speed tweak. A recoverable failure that relies on catching a panic has no effect in a release build, and a crash takes the process down with it instead of unwinding through your frames, which also leaves less for any crash reporter to work with. The rest of the root is in the same spirit of a repository that builds binaries for people who are not looking at the source. A Cargo.lock is committed for reproducible builds, and build.sh sits beside it, while the rest of the tree is directories: docs, imessage-database and imessage-exporter.

No homepage, GPL-3.0, and releases with tree names

Three things about the project's presentation are worth a reader's attention. There is no homepage recorded for the repository, so the documentation is the whole surface, which is why the four internal links matter so much. The licence is GPL-3.0, which is what you inherit if you take this code into a program of your own. And the releases carry plant names: 4.3.0 (Shining Willow) on 2026-09-15, then 5.0.0 and 5.0.1 (both Speckled Clarkia) on 2026-10-29. The repository is not archived, and the last push is dated 2026-10-31, two days after 5.0.1. For a tool whose coverage is tied to specific macOS and iOS builds, that cadence is the thing to watch: the version number tells you the feature set, the pinned build numbers tell you whether your messages are in it.

Editorial conclusion

imessage-exporter fits someone who owns an iMessage database, wants it in an open portable format on macOS, Linux or Windows, and needs a second opinion on what is wrong with the database. It does not fit a workflow that needs PDF, does not fit anyone hoping the tool tidies or repairs the chat, and does not replace the reverse engineering work that keeps up with new Apple formats. Before you run it, read the two subdirectory READMEs rather than the root page, check the latest release, 5.0.1 (Speckled Clarkia), against the macOS and iOS builds it claims to support, and remember that the binary is read only and the repository is GPL-3.0.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. ReagentX/imessage-exporter on GitHub
5. Releases