plappa plays Jellyfin and AudioBookShelf audiobooks on iPhone and iPad

plappa needs a Jellyfin or AudioBookShelf server before it does anything

plappa is an audiobook player written in Swift and SwiftUI for Apple hardware, and the first thing to understand about it is that it is a client rather than a library host. The project is explicit on this point: a Jellyfin or AudioBookShelf server has to exist for the app to work at all. If you do not run either of those systems, plappa has nothing to connect to and nothing to display, and no amount of configuration on the device side changes that. The homepage is plappa.me and the app is distributed through the App Store, but the server requirement is the part that decides whether the project is relevant to you in the first place.

The audience is narrow and reasonably well defined. It is for people who already self-host a media server, or who pay for a hosted Jellyfin or AudioBookShelf instance, and who listen to books on an iPhone or an iPad. That is a different proposition from a general-purpose media player that treats every audio file as a music album. The upside of the narrowness is that the app can assume the server already speaks the audiobook domain: it already knows about authors, narrators, series and cover art. The downside is that the first step of using plappa is never installing plappa. It is having a working server and a library in it.

Recursive audio search means the folder layout barely matters

The discovery side of plappa is deliberately forgiving about how files sit on disk. According to the README, plappa searches for audio files recursively and groups them by album, so a library with a different structure from the usual one still shows up. The author states that testing happens against the common Jellyfin organization scheme, where each book occupies its own directory, and says other folder structures should work fine.

The grouping rule is where that tolerance has a visible consequence. Grouping happens by album, which means the app derives a book from a set of files sharing a directory rather than from a server-side entity with a title, an author and a narrator attached. In a library where several books share one folder, or where one book is split across subfolders, the boundaries the app draws will not necessarily be the boundaries you chose. Chapters and titles are then recovered from file tags and server metadata, which means a poorly tagged folder produces a badly labelled book. The README says plappa handles the common audio file formats, but that it is built and tested mainly with MP3 and M4B files, so those are the two you can expect the author to have exercised.

The composer field doubles as the narrator name

Most of what plappa shows comes from the server, since Jellyfin and AudioBookShelf both maintain the bibliographic details that an audiobook client needs. On top of that, plappa reads two things from the file metadata itself: the composer field, which it uses as the narrator name, and chapters, when they are present in the file.

This is a practical shortcut and it carries a practical risk. Narrator credits are often stored in the composer slot by audiobook producers, because that is the field tooling has carried for a long time, and reading it there gives plappa a narrator for libraries whose server metadata never learned one. Where a library tags the composer field with the actual composer of the music in the file, the same mechanism will display that person as the person reading the book. Chapter support has the same shape of dependency: it exists when the individual file carries chapter markers, so two copies of the same title can behave differently depending on how they were produced. If your library has inconsistent tagging, the display will be inconsistent in the same places.

iCloud sync and offline downloads go beyond plain playback

Beyond starting playback, plappa does two things that distinguish it from a bare player. Playback status syncs through iCloud, so the position in a book can follow you between Apple devices signed into the same account. And audiobooks can be downloaded for offline listening, which is the feature that matters most on a commute or on a flight with no usable network.

Both features are stated in a single line each in the README, and the README does not go further. It does not document how a sync conflict is resolved when two devices move through the same book at the same time, which iCloud container is used, whether downloaded books are stored in a shared location or per device, or how much space a set of downloads occupies. The absence of those details is not a defect in the feature but it is a limit on what you can plan around. The sync route is also firmly inside the Apple ecosystem, since it depends on iCloud, which is one more reason the planned Mac and Apple TV versions matter to anyone whose listening happens on a television.

iPhone and iPad today, Mac and Apple TV only on the roadmap

The roadmap makes the platform story plain. The iOS app with the basic features is checked off. CarPlay support is checked off but marked work in progress. AudioBookShelf support is checked off and also marked work in progress. The Apple Watch app, the Mac app and the Apple TV app are not checked off at all, and the README says the current build runs on iPhone and iPad while a Mac and an Apple TV version are planned.

For most people that is the whole adoption decision in one line. If your audiobooks are consumed on a handset or a tablet, plappa fits the platform you already use. If your library is a living-room or shared-household thing, plappa currently does not cover the devices where that listening actually happens, and the Apple TV entry being unchecked means even the shortest path to a television is not in the shipped build. The Mac entry is the same story for anyone with an Apple Silicon desktop. The full roadmap lives in the author's GitHub projects view rather than in the repository itself, so the checkboxes here are the shorter summary the README presents.

AudioBookShelf support is the newest and least settled feature

The two supported server platforms do not sit at the same level of confidence. Jellyfin support is the case the project was built around: the README describes testing against the common Jellyfin organization scheme for books and links to Jellyfin's own documentation for that layout. AudioBookShelf support is checked off in the roadmap and still carries a work in progress marker, and the README explains the AudioBookShelf project as a separate system with its own site and repository.

That distinction matters if you are choosing a server rather than an app, because the app is where the compromise shows. plappa reads the composer field for the narrator and pulls chapters from file metadata in the same way regardless of which backend is behind the connection, so any differences between the two servers surface as missing or mismatched metadata in the app rather than as a different feature set. The short version for an evaluator is that a Jellyfin setup is the case the author has exercised most, and an AudioBookShelf setup is the newer path where oddities are more likely to appear.

A browser player versus a native app on iPhone

There is an obvious alternative approach to the one plappa takes: open the server's own player in a browser and listen there. The difference is structural rather than cosmetic. A browser player keeps the book on the server and streams it, so there is no persistent copy on the device, which means no offline listening and no equivalent of iCloud position sync. The trade runs the other way too, since a browser player imposes no install and no Apple platform requirement at all, and it works on platforms that plappa's roadmap does not plan to reach yet.

The native route buys concrete things instead: a purpose-built audiobook interface with server and file metadata combined, the composer field promoted to narrator, chapters read from the file, downloads on the device, and CarPlay support for driving playback from a car. plappa's own framing is that it is an audiobook client for these two servers rather than a general media player, and that specialisation is the entire value proposition. If your listening is mostly at a desk with a browser open, the browser route covers the same library at a lower cost. If your listening is on a phone in motion, the native route is the one that adds capabilities the browser path cannot offer.

Bug reports go to issues, feature requests go to discussions

The feedback process is split, and knowing which door to use saves a round trip. Bugs belong in the GitHub issue tracker, where the project asks you to follow the issue guidelines, to provide as much information as possible without revealing personal data, and to check whether the bug was already reported. Feature requests live in the repository discussion area, where you can create a request and vote on other people's ideas, with the same expectation that you search for an existing duplicate and vote on that instead of opening a new one.

The maintenance picture is thin on the repository side. There are no GitHub releases, so there is no release notes file or changelog to consult, and the last push to the repository was on 2026-08-08. The top-level entries are a GitHub configuration directory, an images directory and the readme, and no license file appears among them, which leaves the terms for redistribution and reuse unconfirmed from what is shown here. The homepage plappa.me and the App Store listing are the practical first stops for anyone deciding whether the project fits, and the issue tracker is where you will find out whether the newer parts of the roadmap are settling down.

Editorial conclusion

plappa suits anyone who already hosts a Jellyfin or AudioBookShelf library, owns an iPhone or iPad, and wants a listening-focused app with offline downloads and cross-device progress. It does not suit Apple Silicon Mac owners, Apple TV viewers, or anyone without a compatible server, because those paths are still unchecked roadmap items. Before adopting, confirm three things on your own setup: that the composer field in your files carries the narrator you want displayed, that your books carry chapter metadata if you rely on chapters, and that your server is reachable from the device over the network you use, since the README documents no setup guide, no license file, and no release history to fall back on.

Frequently asked questions

Official sources

1. Issues
2. LeoKlaus/plappa on GitHub
3. Project website
4. README