Edited and unsent messages: what survives in an iPhone export
An edited iMessage keeps its earlier wordings inside the backup, and a message the sender unsent leaves a row where the text used to be. Both survive a database read; neither survives a screenshot, because the phone shows you only the final state. What an export can put in a document is the current text, the fact that it was edited, when, the earlier wordings when you ask for them, and, on a backup whose database records it, a mark where a sender took a message back. What it cannot do is tell you what an unsent message said.
This is the detail behind the generic claim that an export is a better record than a photograph of a screen, and the method it belongs to is how to export an entire iMessage conversation.
What does the phone keep when somebody edits a message?
It keeps the earlier wordings, in a separate blob on the message row rather than in the column holding the text. The visible text is replaced; the superseded versions sit beside it, each with the time it was replaced, and the phone shows them behind the word Edited under the bubble. A tool that reads the text column alone gets the final wording and no idea there was another one.
Apple publishes the limits on both actions, and they decide what the database can ever hold. The Messages user guide states that you can edit a recently sent message up to five times within 15 minutes of sending it, and unsend one for up to two minutes. Both need iMessage with iOS 16, iPadOS 16.1 or macOS Ventura and later, and the same page says plainly that SMS and MMS messages cannot be unsent or edited at all. If your conversation is green rather than blue, that one line decides this whole page for you.
Once those windows close, what the database holds is settled, and it holds more than the screen shows.
Why is the edit history not in my document by default?
Because reading it costs an extra blob on every message row, so it is a switch rather than standing behavior. In the export options the switch is labelled Show edit history, it starts off, and its hint says what turning it on does:
Spells out earlier versions of edited messages and marks the ones their sender unsent.
With it off you still get the current text of every message, and an edited message is still
reported as edited in the CSV, with the time. What you do not get is the earlier wordings: the
previous_versions column stays empty and the PDF prints no history under the bubble. That is
a default rather than a limit, because the conversation and not its revision log is what an
export is usually for.
If the revision log is the point of your document, turn it on before exporting rather than after, since it changes what gets read out of the backup and not just what gets printed.
What happens to a message the sender unsent?
The row stays and the words do not. Unsending removes the text; it does not remove the message’s existence from the database, so the export can say a message was there and was taken back, in its correct place in the conversation.
Apple shows this on screen as well, and on both sides: its guide says a note confirming you unsent the message appears in both conversation transcripts, yours and your recipient’s. So the bare fact is not what an export adds. What it adds is the time as the database holds it, in the message’s own place in the conversation, inside a document somebody else can read and recount.
There is also a case where the two phones disagree. If the recipient’s device runs a system older than the feature, Apple’s page says the original message remains in that conversation, so a message that is gone on one phone can still be sitting on the other.
The export decides a message was unsent on any of three independent marks, which is worth knowing because they are not equally available:
- A dedicated retraction timestamp on the row. This one carries the time, and it is read only where the backup’s database actually has that column, which the program detects rather than assumes.
- A key inside the same summary blob that holds edit history, which appears whenever a part of a message was unsent. This one says it happened without saying when.
- A flag carried by the other source this program reads, a WhatsApp export file, which records the fact with no message database behind it.
Only the first of those is read on an ordinary export, because the second lives in the same blob as the edit history. So on a database whose schema has no retraction column, the mark appears only with edit history switched on, and even then without a time. Reading that as “the tool lost the timestamp” is the wrong conclusion: the timestamp was never written.
How do these show up in the export?
In the CSV as columns, which is the format to use if anybody is going to count or filter them, and in the readable formats as marks on the message itself. The PDF, the TXT and the HTML gate the history on the same switch, the HTML because it is the PDF’s document saved as a file rather than a second renderer. RSMF carries the fields for a review platform rather than for a reader.
| Column | What it holds |
|---|---|
edited | Whether this message was edited at all |
edited_at | When the edit happened, when the row records it |
previous_versions | The superseded wordings, one per line in the cell, each prefixed with the time it was replaced when known. Empty unless edit history was switched on |
retracted | Whether the sender unsent a part of this message |
deleted | Whether the message is marked deleted |
deleted_at | When it was deleted, when the row records it |
recovered_deleted | Whether this row came from the Recently Deleted store rather than the live conversation |
The full set of fourteen columns, and what the other seven mean, is exporting iPhone messages with their metadata.
Is a deleted message the same thing as an unsent one?
No, and they are worth keeping apart. An unsent message was withdrawn by the person who sent it: on devices new enough for the feature both sides lose the text, and where the recipient’s system is older Apple says the original stays in their conversation. A deleted message was removed by whoever holds the phone, from their own copy, and the other side still has theirs.
Deleted messages have a clock on them. On iOS 16 and later a message you delete goes to Recently Deleted for a window Apple documents as 30 to 40 days, and a backup made inside that window still holds it. Including those rows is a second switch, also off by default, and the rows that come in through it are marked as recovered and carry the date they were deleted, with a count of their own rather than being folded quietly into the total.
Off by default is deliberate: a document that silently mixes deleted messages into a conversation is a document making a claim nobody asked it to make. Turning it on is a decision, and the document records that you made it.
What none of this can do
- It cannot recover the words of an unsent message. The text is gone from your own database, so a tool that offers it back is reading something else, such as a notification log.
- It cannot date an unsent message on a database with no retraction column, for the reason above.
- It cannot turn a new message back into an edit. Where one side’s system is too old for the feature, Apple says an edit arrives as a new message carrying the updated text, so the backup holds two messages and no edit history between them.
- It cannot prove nothing was edited. Absence of edit marks means the database holds none, which is not the same statement and should not be written as if it were.
Questions people ask
Does an exported PDF show that a message was edited?
With edit history switched on, yes: the earlier wordings are spelled out under the message and unsent ones are marked. With it off the PDF shows the final text as the conversation reads today. The CSV reports the fact of an edit either way.
Does exporting touch the other person’s phone?
No. The export reads a backup of your own phone, on your own computer, with no account and no network call of its own, so nothing about it reaches anybody else’s device or anybody’s server. What it can read is bounded by what your own phone received.
Why does my CSV have edited set to true but previous_versions empty?
Because edit history was off for that run. The flag comes off the message row, which is read anyway; the wordings come out of a blob that is only fetched when you ask for it. Re-export with Show edit history on and the column fills.
If a message was unsent, is my conversation incomplete?
Your document is as complete as the record is. The honest description of such a document is that it holds every message the backup holds, including the place where one was withdrawn, and the document states its own scope in those terms rather than leaving you to explain it.
Where to go next
- How to export an entire iMessage conversation, the method this detail sits inside.
- Exporting iPhone messages with their metadata, for the rest of what travels beside the words.
- Saving an iMessage conversation before it disappears, if the thread you need is one somebody is actively deleting from.