OpenList-Mobile: a Flutter file server for Android

The phone as the file server

OpenList-Mobile is described as a mobile file server application based on OpenList, built with the Flutter framework, supporting local network file sharing, remote access and online management.

The framing is unusual and worth being clear about. This is not a file manager that connects to a server somewhere else. It is a file server that happens to run on a phone, with a user interface for managing what it serves.

The audience follows directly from that. Somebody who wants to share a folder of files with a household, or get a large set of documents off a laptop without a cable, or serve media to other devices on the same network, can install this on a phone and skip the part where you set up a server on a machine that has to stay switched on.

The project is written in Dart with Flutter, licensed AGPL-3.0, and the README carries a Flutter badge pinned at 3.32.7, which tells you the toolkit version the current build targets. There is a Chinese and an English README, and the badge set at the top of the page names the three workflows that matter: release, build and a sync job for OpenList itself.

The name of the project in the repository is OpenList-Mobile, and the project it wraps is OpenList, which lives in the same organisation.

The server travels inside the application

The directory layout shows how the project is put together, and the key entry is openlist-lib.

That directory sits at the repository root next to lib, which is the Flutter application code, and it holds the OpenList server code. The application is therefore not a thin remote control: the server implementation is carried with it and runs on the device.

That single design choice explains most of the project's behaviour. It explains why the repository has an openlist_version file, which records the version of the bundled server. It explains the Sync OpenList workflow, which exists to move that bundled version forward. It explains why the app can serve files on the local network without a separate machine, since there is nothing to connect to until the phone starts serving.

The consequence is that the app inherits the server's own constraints, including its licence, and the AGPL-3.0 on the repository applies to the whole of it.

The rest of the tree is a standard Flutter application. There is an android directory and an ios directory for the platform projects, an assets directory and an images directory for bundled resources, a test directory, a pubspec.yaml with a pubspec.lock beside it, and an analysis_options.yaml for the linter configuration. A .metadata file marks the Flutter project version.

It is worth noticing what is not in the tree. There is no server configuration file, no deployment manifest and no container definition, because none of those concepts apply to an application that runs on a phone.

Pigeon and the generated platform channel layer

Two directories at the root stand out as the interesting engineering in the repository: pigeons and pigeon_config.yaml.

Pigeon is the code generation tool used for Flutter platform channels, and its presence tells you that this app talks to native code through a typed, generated interface rather than through hand-written method channel calls. The pigeons directory holds the message definition files, and pigeon_config.yaml configures the generation.

That approach matters for an application that has to do more than render widgets. OpenList-Mobile needs filesystem access, background work and network serving, and on Android those capabilities live in the platform layer rather than in Dart. Generating the channel bindings means the Dart side and the Kotlin or Swift side agree on message shapes, and the compiler catches a mismatch that would otherwise be a runtime error.

The two-platform structure follows the same logic. The android and ios directories hold separate native projects, and the pigeon definitions are shared, so a change to a channel interface is made once and generated for both.

The tests directory suggests the Dart side is covered by unit or widget tests, and the analysis_options.yaml means the linter rules are part of the project rather than left to defaults.

Android supported, iOS still experimental

The platform list in the README is short and honest: Android, and iOS marked as experimental and still in development.

That distinction matters more than it might look. A file server needs to keep running while the screen is off, needs broad filesystem access, and on Android typically wants to be exempt from the aggressive battery optimisation that the platform applies to background apps. Those are the parts that differ most between the two mobile platforms, and they are exactly the parts that are unfinished on iOS.

For an adopter, the practical rule is simple: if you need this on Android, the platform is there. If your only option is an iPhone, this is not the answer yet, and no amount of building from source changes the label the project puts on it.

The release workflow badges give a sense of the project's shape. There is a release workflow, a build workflow and the sync workflow, all running under GitHub Actions, so the build is continuous and the artefacts are produced by the project's own configuration rather than by a maintainer's laptop.

The twice-daily job that keeps the bundled server current

The most interesting line in the README is the note about automatic updates. It says that GitHub Actions checks the latest OpenList version twice a day, in the morning and in the evening, and automatically builds and publishes, so the app always uses the latest version.

Think about what that means for the architecture. The bundled server is a moving dependency that would otherwise have to be updated by hand, with a version bump, a dependency change, a rebuild and a release. Instead, a scheduled workflow reads the upstream OpenList releases, takes the newest version, and produces a new build of the app around it.

That is a good use of continuous integration for a project whose upstream moves fast, and it is also the thing to watch. The app is not a fixed artefact that you can evaluate once; a new build appears twice a day with a new server inside it. The version numbering reflects this, with releases like v4.2.7.26101517 and v4.2.6.26090117, where the trailing part encodes a date and time rather than a sequential number.

For someone who wants to evaluate the project, the build workflow is where the experimental versions appear, and the release page is where the stable ones are. The README labels the release build as recommended and the build artefact as carrying the latest features.

The toolchain and the current release in one place look like this:

Flutter 3.32.7
v4.2.7.26101517

The Flutter version is what you need to build from source, and the release tag is what a user would install.

Getting a build, and the limits of the platform

There is no build command in the README, and there is no package to install, so the install path is a download. The README points at the releases page for the stable version and at the build workflow for a development build, and the workflow is where the nightly artefacts appear.

For a developer who wants to build from source, the requirements implied by the tree are a Flutter SDK at the version the badge names, the Dart toolchain that comes with it, and either the Android toolchain or an Xcode setup for the iOS side. The openlist_version file tells you which upstream server version the current source expects.

The limits are the ones a mobile application cannot easily escape. The server lives on a device that also needs to be charged, and a phone that sleeps is a file server that stops serving, which makes the target use case a home network where the device stays plugged in. The AGPL-3.0 licence also matters if you plan to distribute a build of your own, since the bundled server code is part of what you would be shipping.

And there is the simpler comparison to keep in mind. If your goal is to browse files that are already on a network share, a general purpose file manager does that without running a server on your phone at all. OpenList-Mobile earns its place when the point is that the phone is the server, for example sharing a folder with other devices, or reaching your own files remotely without a home server.

Editorial conclusion

Use OpenList-Mobile if you want a phone or tablet to be the file server for a home network without running a server on another machine, and you are happy with Android as the platform. Do not adopt it for an iPhone, because the README marks iOS as experimental and still in development, and consider carefully before distributing it, since the AGPL-3.0 licence attaches to the bundled server code. Before your first build, decide whether you want the published release or a workflow artefact, and check the bundled server version in the openlist_version file, since the upstream server is refreshed twice a day by a scheduled workflow.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. OpenListTeam/OpenList-Mobile on GitHub
4. README
5. Releases