Getting iPhone text messages into Relativity

Sooner or later a matter turns on text messages, and someone has to get them off an iPhone and into review. The usual first attempts are screenshots and PDFs, and the usual result is a review team doing keyword search against pictures of conversations. This post is about the format that solves the problem, why iPhone data resists it more than most, and a concrete path from a phone to files a processing team will accept.

Why screenshots and PDFs fall apart in review

A screenshot has no extractable text, no reliable timestamps, no participant metadata, and no proof of completeness: nothing says what came before or after the frame. A PDF export is better, and for plenty of small disputes it is enough, but review platforms treat a PDF as a document, not as messages. Search hits land on a page, not on a message; there is no per-message sender, timestamp, or thread structure to filter, sort, or produce from. When the volume is real, both approaches turn a data problem into a manual-labor problem.

What RSMF actually is

RSMF, the Relativity Short Message Format, is Relativity's published format for ingesting chat data as data. An .rsmf file is a standard EML with two layers inside: a plain-text transcript, which becomes the extracted text reviewers search, and a zip attachment carrying rsmf_manifest.json plus every message attachment. The manifest holds the structure: participants, conversations, and events, with each message's sender, timestamp, direction, reactions, and attachment references. Relativity's processing engine consumes that structure, so messages arrive threaded, per-message searchable, and filterable, the way review expects.

Why iPhone data is harder than it looks

Anyone who has attempted a converter learns that Apple's message store is not a polite CSV waiting to happen:

• Message text is not always where it seems. Modern iOS keeps many message bodies in a binary typedstream blob (attributedBody), not the plain text column. Naive extraction reads empty messages where words plainly exist on the phone.
• Tapbacks are messages too. A thumbs-up "Liked" reaction is its own row in the store, pointing at the message it reacts to. Exported naively, reactions show up as cryptic standalone messages ("Liked an image") instead of annotations on the thing reacted to. RSMF has a proper place for reactions; the exporter has to do the aggregation.
• Edits and unsends exist now. Recent iOS versions let people edit and unsend messages, and a defensible export has to say what the store says about that rather than silently presenting the final text as if it were the only text.
• Recently Deleted is a real place. A message the custodian deleted may still sit in the store, content intact, flagged deleted. That flag belongs in the export, not erased by it.
• Attachments live outside the message rows, in a content-addressed file store that has to be joined back to the right messages and carried along with original filenames.

The path from phone to RSMF

With Text2Store on a Mac or Windows machine, the workflow is deliberately short, and everything happens on that computer; message content is never uploaded anywhere, which keeps the data-handling story clean.

1. Capture. Connect the iPhone and click Back Up & Archive. This takes a normal, complete iOS backup and lands it as a dated, integrity-checked archive. Already have an iTunes-style backup or a Text2Store archive from another machine? Import it instead. Encrypted backups work with the backup password.
2. Verify by looking. Open the archive and read the conversations, free. Confirm the messages at issue are actually present before anyone pays for anything or promises anything to a client.
3. Export as RSMF. Select a conversation, several, or the whole archive; each conversation exports as its own RSMF 2.0 file with participants, timestamps, direction, aggregated reactions, edit records, deleted flags, and attachments in the container. iMessage, SMS, and WhatsApp conversations all export, each labeled with its platform.

What a defensible exporter owes you

Three properties are worth demanding from anything that writes RSMF, ours included:

• Validation against the real thing. Relativity publishes an official validator library. Text2Store's exporter is tested against it on every change, including on real exported files, and held to the strict reading: warnings addressed as well as errors, since Relativity advises resolving both before ingest.
• Never fabricate. A handle with no contact card should stay a phone number, not become a guessed name. A field the store does not hold should be absent, not invented. Text2Store follows the store: what exports is what the phone's own database records.
• A provenance story. Archives are integrity-checked on import, and can optionally be anchored with an RFC 3161 trusted timestamp when created, so you can show an archive existed in its exact form at a point in time.

Reaching messages the phone no longer has

One iPhone-specific advantage of working from backups: if older backups exist, messages deleted from the phone since then are still inside them. Text2Store's merged view unifies every backup of a device into one deduplicated timeline, which means the export scope can include conversations as they stood years ago, not just as the phone stands today. What no backup ever held, no tool can conjure; what a backup held, you can still produce.

Nothing here is legal advice, and format validation is not a ruling on admissibility. Your matter's requirements and your review workflow govern.