Audiobooks Not Syncing from Mac to iPhone: What Actually Broke

Finder said it was done. The progress ring finished, you unplugged the cable, and the audiobook is not on the phone. Or it is on the phone, sitting in the wrong app, with a title like 01_track and no way to get back to where you stopped.

That is not one problem — it is four. The book never left the Mac. Or it left, but was never a real audiobook. Or it arrived and your place did not follow. Or iCloud was never going to sync it at all.

When the file itself is the problem, a book built right — real chapters, right type, right shelf — is AudioBo’s job.

The fix depends entirely on which one you have. Here is how to tell, in the order that costs you the least time.

If you have not gotten as far as a successful transfer yet, the mechanics of getting a file onto the phone in the first place are a separate walkthrough. This page starts after the sync claims to have worked.

The Audiobooks tab shows your Books library, not your disk

The single most common version of this: the file is in a folder on the Mac, and the sync panel has never heard of it.

Finder’s device panel does not scan your drive. It reads the library of the app that owns that content type, and for the Audiobooks tab that is the Books app. A book that lives only in a folder — Downloads, or wherever you keep them — is not on that list, so it is not in the sync either. Nothing goes wrong when you press Sync. The sync does what it was asked, and it was never asked to copy your book.

When the panel cannot reach that library at all, it says so in as many words. The Books library could not be opened. is a literal string inside the sync interface on macOS 26.6, sitting next to the same message for the Music, TV, and Podcasts libraries.

Check your own Mac: open Books and look for the book under Audiobooks. Not in Finder. In Books.

If it is not there, drag it in, then go back to the device panel. The Audiobooks tab has one checkbox, labeled Sync audiobooks onto <your device>, and under it a choice between All audiobooks and Selected audiobooks. Under Selected audiobooks, only the books you tick get copied. So tick the new import before you sync. Check it rather than assume a fresh book inherited a selection.

One thing worth knowing before you experiment: turning that checkbox off is destructive, and the panel warns you in as many words — it asks whether you are sure, and says every audiobook already on the phone will be removed.

The other Mac took your books

If the audiobooks vanish from the phone every time you sync, and you own more than one Mac, this is your answer.

A device’s synced audiobooks belong to one Mac library. Connect it to a second Mac and the panel offers you a trade, spelled out before it acts: music and audiobooks synced from other libraries will be removed, and items will be synced from this library instead.

There is no merge. There is no “keep both”. Pick the Mac that holds your library and sync from that one.

What iCloud moves, and what it leaves behind

The expectation that wastes the most time is that adding a book to Books on the Mac makes it show up on the iPhone by itself, the way a PDF does.

It does not, and it is not a setting you have missed. For books you added yourself, an ebook and an audiobook are two different kinds of thing to iCloud: it takes the one and leaves the other where it is.

Here is what my own Mac shows: I looked at what Books had actually uploaded, and the iCloud Books folder held EPUBs and nothing else — no .m4b, no .m4a, no .mp3. The same library’s audiobooks — none of them store purchases, all imported by hand — every one stayed on the Mac.

That is the whole asymmetry. The EPUB went to iCloud. The audiobook was never a candidate.

What iCloud does carry is the library’s state. Books’ settings carry a Syncing group with exactly two toggles — Home, and Collections, bookmarks, and highlights, described as syncing collections, bookmarks, highlights, and recent book info across devices. Apple’s Books guide also says iCloud saves your spot in a book or audiobook. Note what is missing from all of that: the audio. State sync has nowhere to land until the same book exists on both devices, which brings you back to the cable.

Your place is a number in a database, not a tag in the file

This one surprises people who have already done everything right.

Where you got to in a book is not part of the book. It belongs to the app that was playing it, on the device that was playing it — which is why two devices holding the same book can sit at two different places, and why a book you carried across yourself starts from the beginning.

Books keeps your listening position in its own library database, as a plain fraction between zero and one, with a separate high-water mark for the furthest you have reached. It is a row in a table, keyed to the library item. The M4B on disk carries no such field. Nothing about your progress is written back into the audio file.

Two consequences follow.

Copying the file to another device copies audio, chapters, and metadata — and no position. If you moved a book by AirDrop, a USB stick, or a cloud folder and expected to resume where you left off, that was never going to happen; the information was not in what you copied.

And if you rebuild or re-export the book, the new file is a new library item. Your old position belongs to the old one. Finish the file first, then import it once, then start listening — which is the practical case for getting everything right in one pass, AudioBo’s whole job, instead of re-importing after every tag fix and losing your place each time.

When the file is the reason, not the sync

If the book reaches the phone but lands in the wrong place — plays like a random track, no chapter list, filed with music — the transfer is not where to look. The file is, and specifically what it declares itself to be.

An app does not work out what a file is by reading its name. Inside the file there are two small declarations that say, in effect, this is a book, not an album — and a file can be missing both while still ending in .m4b. The name on the outside convinces nobody. The phone reads what is inside and files the book accordingly.

Those two declarations decide how library apps classify it, and neither one comes from the filename: the ftyp brand in the header, and the iTunes media type tag. What an M4B file actually is is the canonical account of both, including what renaming an M4A does and does not change.

What matters here is that a file can be wrong in a way you would never notice until it reaches a phone. I measured a plain ffmpeg remux with default settings, writing to a name ending in .m4b: major brand M4A , the music brand, and no media type tag at all, despite the extension and three perfectly good chapters. A music file wearing an audiobook’s file name. That file is not lying about being an audiobook. It is not claiming to be one.

Want to fix it yourself? ffmpeg will set both if you ask, and this is the free fix. On a file that already contains the right audio and chapters, it is a stream copy:

ffmpeg -i yourbook.m4b -c copy -brand "M4B " -metadata media_type=2 fixed.m4b

I ran exactly that and confirmed the output: major brand M4B , media type Audiobook, chapters intact. AtomicParsley yourbook.m4b --stik Audiobook --overWrite sets the media type in place if that is the only flag you are missing. If this is your one broken file, use one of those — they are doing real work, correctly, for nothing. The rest of this page is for when it keeps happening.

A related detail that trips up re-syncing: Books does not sync the file where you keep it. It copies the book into its own container on import, so editing your original afterward changes a file Books stopped looking at. Pushing a corrected version through means deleting the book from Books and importing it again — and that delete is a real delete, because for a sideloaded audiobook the copy inside Books is the only one Books has. Confirm your master file exists somewhere outside the Books library before you touch it. The container path and the full procedure live on how to edit M4B metadata, cover art, and chapters.

If the file arrives, identifies itself correctly, and still shows no chapter list, that is a different fault with its own diagnosis — tell whether the chapters are missing or merely unreadable before touching anything else.

What AudioBo does about this: the file, not the sync

Every fix above is a command you can run, and if you have one bad book, running them is the right answer.

What makes this miserable is that a book needs all of it to be right at once, and a book that is wrong in one respect is usually wrong in three: nothing saying it is a book rather than an album, chapters only half the world can read, an author filed under the wrong letter.

AudioBo makes the file once with all of that already settled. What arrives in Books is a book: chapters, the title and author filled in, cover art, and a file that sits with your audiobooks rather than your music. It exports plain audio as well — M4A and MP3, for old car stereos and players that want nothing clever — formats where the audiobook flag and brand simply do not exist, so none of the above applies to them.

Fixing a book you already have does not mean rebuilding it, either. Since 1.2.2 the tags, cover art, and chapter names are written back into the original file, with the values in front of you before you commit and no re-encoding. The ffmpeg line above leaves the audio alone too — the difference is that it hands you a new container rather than correcting the one you have.

If you do want the mechanical version: its M4B export declares the M4B brand in the header, sets the media type to Audiobook, and writes chapters in both the QuickTime and Nero formats so the file reads the same whichever one the app on the other end looks for. I pulled one of its M4B exports out of my own Books library and checked: major brand M4B , media type Audiobook, sort tags filled in. Those sort fields decide where a book files itself alphabetically, and they have a page of their own.

Two boundaries, stated plainly. AudioBo builds and repairs files; it does not carry them to your phone, so the sync itself — the Books library, the second Mac, iCloud — is still yours to check. And AudioBo does not remove DRM. An Audible download or a protected store purchase is not a file any of this applies to, and no amount of tag repair reaches inside it.