Paperback iOS: a release and issue tracker for an ad-free comic reader

A repository with two entries and no source code

The top level of this repository holds exactly two things, a .github/ directory and a README.md. There is no source tree, no build script, no package manifest, and the primary language is not even recorded. The repository description says it plainly: a repository to host app releases, issues, and feature requests for Paperback.

So the useful question is what such a repository is for. The answer is that it is the public, versioned, searchable front door of a project whose code lives somewhere else, and it exists because issues and releases need a permanent, linkable home.

The application behind it is Paperback, described as an ad-free comic and manga reader for Apple devices. The homepage is paperback.moe. The distinguishing feature for a comic reader is not the reading interface, it is the source support: it supports Komga and other third-party extensions, which means it is designed to pull content from servers the user already owns rather than from a catalogue baked into the app.

That single fact drives almost everything else in the repository, because a reader with a plug-in extension model has a support surface that is naturally split. The app and the extensions fail independently, and a user reporting a problem cannot always tell which side broke. The README is written around that boundary, and the rules for who to contact are the most carefully specified part of it.

Where to install, and the website that holds the actual documentation

There are no installation steps in the repository, and that is deliberate rather than an omission. The Installation and Troubleshooting section points to the website for help with installing and troubleshooting common issues.

This is worth pausing on as a design decision. A README in a repository like this could have carried a sideloading walkthrough, a signing profile note, or a step-by-step install guide, and any of those would age badly. The website can be updated without a release, and it can be localised, and it can hold the kind of visual instruction that a repository README handles poorly.

The site also hosts the troubleshooting FAQs, which the support rules tell you to check before opening an issue. The website and the Discord server are therefore the two places where a question gets answered quickly, and the issue tracker is the third and last resort.

That ordering is the whole workflow the project wants, and it is worth understanding before you decide that something is broken. The rule list below is not bureaucracy for its own sake, it is a funnel: check the FAQ, check Discord, search existing issues, then file.

One detail of the release naming is worth noting while you are here. The public releases are named with a build suffix, for example 0.8.11 (2), which reads as a version plus a second public build of that version. That naming implies the public release is a repackaging of an internal build, and it means there can be more than one public build of the same version number.

The seven rules, and what they reveal about where the boundary sits

The support disclaimer is the substance of the repository, and it is presented as rules you need to follow to make it easier for the developers to help you out.

The first rule is to use your common sense, which is blunt but sets the tone for a small team. The second is a version recommendation: it is recommended that you use the latest available version of the app, currently 0.8, and 0.7 and lower is deprecated. The third is the boundary rule, and it is the one that matters most for anyone running extensions: do not make GitHub issues regarding third party extensions, those will not get any support here and will get closed, and instead contact the extension developer.

The remaining four are about how to file well. Check that your issue has not been answered in the troubleshooting FAQs or the help-desk channel on the official Discord. Check the issue tracker so you do not make duplicates. Make sure that all the info you provide is accurate, because if it is not the developers will not be able to help and the issue will be closed. And understand that fixing bugs and adding new features may take some time.

Read together, the rules separate three questions that users routinely conflate. Is the app broken? That is what this tracker is for. Is my extension broken? That goes to the extension author, and an issue filed here will be closed. Is this something already known? That goes to the FAQ, the Discord channel and the existing issue list, and filing it again wastes the maintainers' time.

The accuracy rule is the strictest one. An issue closed for inaccurate information is not a judgement on the reporter, it is a statement that the maintainers cannot act on a report they cannot verify. Given a small team, that is a rational triage policy rather than a hostile one.

The release list, and what it says about the pace of the project

There are three public releases in the list, and the gaps between them are informative.

The most recent is v0.8.11-r2, described as Public Release 0.8.11 (2), published on 2025-05-20. Before that, v0.8.6-r2 from 2023-11-06 and v0.7-r51 from the same day earlier in November 2023. Two of the three releases share a date, which suggests a burst of public builds rather than a steady release train, and the build numbers confirm it: the 0.7 line reached a fifty-first build and the 0.8.6 line a second build.

A version with fifty-one public builds is a version that shipped many iterations, and the recommendation to use the latest available version with 0.7 and lower deprecated follows from that. If you are on 0.7, you are on a line that the maintainers have moved past, and bug reports from that line are hard to act on because the code that produced the bug is no longer the code that ships.

The last push to the repository was on 2026-04-18, and the repository is not archived. So the tracking repository itself is being maintained, and the fact that the most recent public release is from May 2025 rather than April 2026 tells you the releases are less frequent than the commits, which is what you would expect for a repository that also tracks issues and feature requests.

The version numbering also tells you the project has not reached 1.0, which for an app distributed outside the store is a signal about its stability expectations rather than about its quality.

Why a separate issue tracker and a Discord, and what each is good for

The README recommends the GitHub issues system as the best way to keep the developers up to date with found bugs or wanted features and to receive support on it, with a link to create a new issue and a note to follow the support disclaimer.

There is also a contact section, and it points at the official Discord server for quick support from the community, using the support channel. There is a separate invite link for the Discord, which is the one used in the rules, and a discord.paperback.moe link in the contact section, which is the server address.

So the division of labour is: Discord for quick answers and conversation, GitHub issues for tracked, durable, searchable reports. That is the right split for a project of this size. A Discord answer is fast but disappears into scrollback, while an issue is a permanent record that the next person with the same problem can find, and the rules ask you to search the tracker for that reason.

The rules also give the Discord a specific role in the funnel. Issue number four asks you to check whether your issue has already been answered in the troubleshooting FAQs or in the help-desk channel, and the README says the FAQ lives at paperback.moe/help/faq/. The channel named in the rules is help-desk, while the contact section points at a support channel, so both names are in use.

The rest of the contact surface is the website, which handles installation and troubleshooting, and the issue tracker. There is no email address and no contact form mentioned, which is a deliberate narrowing of the channels a small maintainer team has to watch.

Editorial conclusion

Adopt this repository as your starting point if you run Paperback on Apple devices and want to know which build to use, where the extension-specific questions end, and how to file a bug that will actually be read. Do not look here for source code, because the repository contains none, and do not file extension bugs here, because the support rules state those issues will be closed and redirected to the extension developer. Before you file anything, check the troubleshooting FAQs and the help-desk channel, use the current 0.8 line rather than 0.7 or lower, which is deprecated, and search the issue tracker for duplicates.

Frequently asked questions

Official sources

1. Issues
2. Paperback-iOS/app on GitHub
3. Project website
4. README
5. Releases