paperless-mobile has an iOS directory and no App Store release, and 5.0 is still alpha

A native client for paperless-ngx, not a second document system

Paperless Mobile does not store documents. It is a client for paperless-ngx, and the README makes the relationship explicit by linking to the paperless-ngx repository rather than describing a competing backend. Its whole argument is that paperless-ngx is usable from a phone browser but that managing documents that way is tedious and slow, so the value of the app is the native surface around an API you already run.

The feature list is organised around that idea. Documents can be viewed, added, deleted and edited, shared, downloaded and previewed, and labels managed and assigned. Search uses a range of filter criteria rather than a text box alone. A dedicated inbox handles new documents so they do not sit unprocessed in the main list, and switching between multiple users is supported, which matters for a household or small office sharing one server.

Two capabilities stand out as the ones a browser cannot easily match. The first is a custom scanner built into the app, the second is biometric authentication on the device. A third, support for mTLS through client certificates, is the kind of feature that only becomes relevant once your paperless-ngx sits behind a reverse proxy that terminates TLS with a private certificate authority.

The build tree tells you how a Flutter app is actually maintained here

The primary language is Dart and the framework is Flutter. Beyond the usual android/ and ios/ directories, the top-level entries describe a project with a deliberate release pipeline. .fvmrc and a .fvm/ directory pin the Flutter SDK version through Flutter Version Management, so contributors and CI build against the same Flutter rather than whatever the machine has installed. flutter is also present at the root, which is consistent with that setup.

Then there is the test and release machinery. integration_test/ holds Flutter's integration tests, test/ and test_driver/ hold the rest of the test suite, specs/ is a separate directory for specification documents, hooks/ for git hooks, and devtools_options.yaml plus analysis_options.yaml for the Dart analyser. build.yaml is present alongside pubspec.yaml and pubspec.lock, and scripts/ holds project scripts. fastlane/ is the release automation, which is what feeds the Google Play listing.

Localization is handled as a first class concern rather than an afterthought. l10n.yaml configures Flutter's own localization, crowdin.yml points at the Crowdin project the README links for translation requests, and resources/ holds the translation assets. Seven languages are credited in the README: English, German, Polish, French, Catalan, Czech and Turkish, with Czech, Turkish, Polish, French and Catalan credited to named community contributors.

One inconsistency is worth noting for anyone reading the repository rather than using the app: the default branch is development, while several README links point at blob/main paths, including the licence link.

Where to get it, and what has not shipped yet

The README gives no build command, so the documented way to obtain this app is a store link. Two are provided: a Google Play listing and an F-Droid package, both under the identifier de.astubenbord.paperless_mobile. Anyone who wants to build from the repository has to read pubspec.yaml and the fastlane configuration rather than copy a documented invocation, and the FVM pin means the first thing to get right locally is the Flutter version recorded in .fvmrc.

The roadmap is the more informative document, and all three of its items are unchecked. The first is a fully custom document scanner optimized for common white A4 documents and for use with Paperless. The second is more languages. The third is publishing to the App Store.

That last item defines the current distribution reality. The repository contains an ios/ directory and Flutter builds for iOS from the same source, but the roadmap says the App Store publication has not happened, so the practical situation is that this is an Android client today. A team with iOS users has no supported install path, which is a much larger constraint than any missing feature in the list above.

Release timing supports the same reading. v4.5.0 was tagged on 2026-04-16, then v5.0.0-alpha1 on 2026-04-19 and v5.0.0-alpha2 on 2026-04-20. A stable major version is two alphas and counting, with the alphas landing within days of the preceding release.

Two authentication paths, and the one the README does not explain

Security is where a document client has to be specific, and the README lists three separate mechanisms without describing how they interact. Biometric authentication protects the app on the device. Two factor authentication is listed as supported. mTLS through client certificates is listed as supported.

What the README does not do is explain the login flow to a paperless-ngx instance, credential handling, or how a client certificate is provisioned onto the phone. There is no configuration file in the repository documenting server addresses or token storage, and no settings reference. For a deployment where the server sits behind a reverse proxy terminating TLS with a private certificate authority, the client certificate story is the feature to investigate first, because installing and rotating a certificate on a phone is not something the app's own documentation here explains.

The same thinness applies to backup and export. The feature list covers sharing and downloading files, but nothing about migrating data out of the app, and nothing about what state the app keeps on the device if you uninstall it. The underlying documents live on the server, so the risk is limited to cached previews and credentials, but the README does not say which of those are cached.

Maintenance pace, since the last push was on 2026-06-01

The repository is not archived, and the last push was on 2026-06-01. That is over four months before the date this article is being written, and it sits after the April release cluster rather than before it, so the sequence reads as a burst of 5.0 alpha work followed by a quiet stretch rather than an ongoing cadence.

The releases do not help fill the gap either. The three most recent tags are all from April 2026, two of them the same pair of alpha builds one day apart. There is no changelog excerpt in the README and no release notes file at the top level to check what changed between v4.5.0 and the alphas, so an adopter pinning a version has to read the commit history or the release page directly.

Set against that, the surrounding project is not small: a fastlane release pipeline, FVM pinned Flutter versions, integration tests, and a Crowdin translation project with named contributors in five additional languages. The infrastructure is in place for regular releases; what is missing is the evidence of recent ones.

Licence, funding and the alternative approaches

Paperless Mobile is distributed under the GNU General Public License v3.0, with the text in LICENSE as the README states. No legal advice is offered here; the practical read is that it is a copyleft licence, so a fork that you distribute carries obligations, while a fork you run internally for your own organisation is a different question that your own policy should answer.

Funding runs through GitHub Sponsors, and the README asks for donations to keep development going. That is worth weighing when you are assessing the risk of depending on it, particularly given the gap since the last push.

The alternative approaches split cleanly. The first is the browser, which the README itself names as the option this app exists to improve on: it requires no app install and offers no built-in scanning or biometric gate. The second is writing your own paperless-ngx client, which gives you exactly the workflow you need and costs you the scanner, the inbox triage pattern and the credential handling that this project already works out. The third is a different document management system entirely, which is a different bet rather than a different client, and the README gives no basis for comparing the two.

For most teams the choice is between accepting the Android-only, thin release history of this app and living in the paperless-ngx web UI.

Editorial conclusion

Adopt paperless-mobile if your document archive already runs paperless-ngx and your users are on Android, since scanning into an inbox, biometric unlock and client certificate support are the reasons the app is more than a browser wrapper. Do not expect an iOS install today, because the App Store entry on the roadmap is unchecked and the 5.0 line had only reached alpha2 by 2026-04-20. Verify first against the development branch, which is the repository default, and confirm the last push date of 2026-06-01 fits your tolerance for a stalled client.

Frequently asked questions

Official sources

1. astubenbord/paperless-mobile on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases