How to view an iPhone backup on Mac and extract messages
Start by locating the backup in Finder, then copy its entire folder before inspecting anything inside. Finder can manage and restore backups, but it does not offer a reader for individual messages, contacts or notes. For an unencrypted backup, SQLite can show the file index; for readable conversations and single-record exports, Yado can browse the local backup, including an encrypted one when you have its password.
Find the backup with Finder first
In Finder, choose Go, then Go to Folder, paste the following path and press Return.
~/Library/Application Support/MobileSync/Backup/
To identify a particular backup, connect the iPhone, select it in Finder, open General, then Manage Backups. Right-click the backup and choose Show In Finder. Apple also provides Archive, which keeps later backups from replacing that backup. These are the steps in Apple's backup location guide.
If you only need to locate or archive a backup, Finder is enough. Opening the folder reveals the backup's files, rather than a readable conversation history.
Wait for any backup operation to finish, then copy the entire individual backup folder to a separate working location, leaving its contents and names intact. Keep the original untouched throughout the inspection. If no local backup exists yet, follow back up an iPhone to Mac first.
How the backup's file index works
A local backup stores file payloads under hashed names. Its Manifest.db database connects each fileID to a domain and relativePath, which together identify the file's role and original location. A domain distinguishes areas such as the phone's home data and an app group's shared data.
The databases used for the records discussed here are these.
| Records | Domain | Relative path |
|---|---|---|
| Messages | HomeDomain |
Library/SMS/sms.db |
| Contacts | HomeDomain |
Library/AddressBook/AddressBook.sqlitedb |
| Notes | AppDomainGroup-group.com.apple.notes |
NoteStore.sqlite |
The notes filename is NoteStore.sqlite, with no extra “s” after “Note”. Searching the backup folder for a visible sms.db filename will miss its hashed payload. Use the manifest mapping to find it instead.
For the layout Yado reads, a payload sits in the subfolder named after the first two characters of its 40-character fileID, with the full ID as its filename. Finding that payload identifies a database, but interpreting its records still requires understanding its tables and encoded fields.
Inspect an unencrypted backup without changing it
The following command reads the index in your working copy. Replace /path/to/copied-backup with the individual backup folder containing Manifest.db, keeping the quotes around paths with spaces.
sqlite3 -readonly -header -column "/path/to/copied-backup/Manifest.db" \
"SELECT fileID, domain, relativePath
FROM Files
WHERE flags = 1 AND (
(domain = 'HomeDomain' AND relativePath IN (
'Library/SMS/sms.db',
'Library/AddressBook/AddressBook.sqlitedb'
)) OR
(domain = 'AppDomainGroup-group.com.apple.notes'
AND relativePath = 'NoteStore.sqlite')
);"
SQLite's -readonly option opens the database for reading, while -header and -column label and align the output. This query only selects index entries, so a matching row proves the file is listed, rather than proving every message or note can be decoded.
A more useful follow-up than opening a random hashed file is to check the message database and its companions.
sqlite3 -readonly -header -column "/path/to/copied-backup/Manifest.db" \
"SELECT fileID, relativePath
FROM Files
WHERE flags = 1 AND domain = 'HomeDomain'
AND relativePath LIKE 'Library/SMS/sms.db%';"
Alongside sms.db, this can locate sms.db-wal and sms.db-shm when present. SQLite may keep committed changes in the write-ahead log, so copying only the main database can omit records. If you manually reconstruct a database in another working folder, copy its mapped companions too and give them their original matching filenames, leaving the backup copy intact.
These commands stop at inspecting the index. Producing a transcript needs more than selecting the text column from message: Yado also reads an encoded attributedBody field when plain text is absent, and joins messages to conversations and senders.
Why an encrypted backup needs its password
An encrypted backup protects both the manifest database and individual payloads. Yado uses the password to unlock the backup's keybag, then uses the recovered keys to decrypt the manifest and the files being read. The SQLite commands above apply only to an unencrypted backup.
Enter the password used to encrypt that backup. Yado's unlock operation cannot bypass it, and changing a filename does not decrypt a file. Apple explains that resetting a forgotten backup password allows a new backup of current data, but does not make previous encrypted backups usable.
Browse and export individual records in Yado
In Yado's Overview tab, open the backup tile's Manage button. Under Existing Backups, move the pointer over the desired row and click Browse Contents. With no phone connected, open the Yado logo menu and choose View Backups when local backups are listed.
Yado scans its configured backup location, which is separate from Finder's default folder. To inspect a copied Finder backup, open Settings, use Change beside Backup Location, and select the parent folder containing your individual backup copy. This also changes the destination for future Yado backups, so record the previous location and restore it afterward if needed. For a backup stored elsewhere, see iPhone backups on an external drive.
- If the backup is encrypted, enter its password and click Unlock.
- Open Messages, Contacts or Notes to see individual records.
- Use Search to find a conversation by its identifier or by words in its messages. Results appear as matching conversations; open one to read it.
- Export the open record with Export Text for a conversation or note, or Export vCard for a contact, then choose a destination folder.
A conversation exports as a .txt transcript with message times, senders and text. A note exports as .txt, and a contact as .vcf. Here, a single message record means one conversation, rather than one selected message bubble. Export All exports the entire category, including records outside the current search results.
The browser keeps decoded records and search results in memory while the backup is open, without building a persistent search index. Database copies, including decrypted copies, temporarily exist in a scratch folder and are removed after the browser closes and its readers finish. Local backup browsing works without the iPhone attached and remains available after the trial expires.
Check the result and understand missing content
Open an exported transcript and compare a known passage, sender and date with the conversation shown in the browser. For a contact, check the fields you needed before importing it elsewhere. Keep the backup as well as the export, because a readable extract serves a different purpose from a restorable backup.
The record browser has specific limits. Contacts, notes and messages support individual browsing; the other categories provide exports rather than the same record pages. Message attachments can appear as [Attachment], but the text transcript does not embed their photos or videos. Notes are extracted as plain text, with locked notes and notes marked for deletion left out; note attachments and rich formatting are not reproduced.
An empty category does not establish that the phone had no such data. Apple's computer backup documentation excludes data already synced and stored in iCloud, including iCloud Photos and messages. Also check that you chose the intended device's backup and date.
If the backup cannot be read, preserve it and compare the working copy with the complete original folder before trying again. An incomplete or unsupported backup and a wrong password are different failures. If an export fails, check that the destination folder is writable, then verify the resulting file yourself. Successfully reading a conversation does not prove the whole backup will restore on an iPhone.