any_share, a Flutter file transfer tool that keeps the traffic on your LAN

Speed Share moves files across the LAN without touching a server

The README states the design goal plainly: this is a completely LAN-based file transfer terminal. Speed Share does not use any servers, does not consume your mobile data, and does not collect any user data, and it enables peer-to-peer transmission.

The problem it addresses is concrete. Chat and messaging apps route the files you send through their own infrastructure, so a photo passed to a colleague leaves your network, is stored somewhere you do not control, and is subject to size limits and compression you did not ask for. A LAN transfer tool shortens that path to two devices talking to each other.

What you can send is broader than files. The README lists text messages, images, and files or folders, plus clipboard sharing, so the application is closer to a small chat and transfer client than a bare file mover. The feature list also covers resuming interrupted transfers, image preview, fast online video playback, and simultaneous sharing and viewing on multiple devices.

One naming point is worth clearing up before you look at the code. The repository is named any_share, the README title is Speed Share, the badges in the README point at nightmare-space/speed_share, and the Android application id visible in the build scripts is com.nightmare.sula. The project was renamed at some point and the documentation was not fully updated, so expect a mix of names in the tree.

Discovery over UDP, pairing over QR code, and browsers as second-class clients

Connecting two devices is the part that usually decides whether a transfer tool feels usable, and the feature list attacks it with three separate paths. There is UDP automatic connection, which finds peers on the network without typing an address. There is a QR code that you scan to connect. And there is manual input for the cases where discovery cannot help.

The fourth path is history: recent connections are kept so that the same pairing does not have to be redone each session.

The list also states that browser joining as clients is supported, and the repository tree contains a web/ directory alongside android/, ios/, linux/, macos/, and windows/. That means the pairing is not restricted to two instances of the mobile or desktop application. A device with only a browser can take part.

The practical limit of the UDP discovery path is the network you are on. Discovery relies on broadcast traffic that many managed networks and guest WiFi configurations block by default, and the README does not document a fallback address mechanism beyond manual input. On a network where UDP broadcast is filtered, the QR code and manual input become the working paths.

Remote file management and static deployment turn the sender into a file server

The two features that go beyond sending are remote file management and file static deployment.

Remote file management is described as visual browsing plus delete and rename, with screenshots named remote_file.png and file_manager.png in the repository. In practice this means the receiving side can browse what is on the sending side, and clean up files there, which is convenient when the sender machine is a shared workstation.

Static deployment is described as similar to Tomcat or Nginx, allowing devices to use browsers to view files and access web pages. The sending device therefore acts as a small web server for its local directory, and other devices pull from it with a browser. The repository contains res/ and assets/ directories alongside lib/, which is where such content would live in a Flutter project.

There is also file categorization by extension, so received files are sorted by type rather than dumped into one folder. On Android the feature list notes support for SAF, so files shared from any application can be received.

Folder sharing is the weak point here: it is listed as under reconstruction, which means the feature is present in some form but not finished. Treat it as unavailable when you plan how people will use the tool.

The build pipeline runs through a nic wrapper and build_runner generated models

The README does not give installation steps for end users, so the entry point for anyone wanting to build from source is the developer documentation at docs/DEVELOP.md and the script definitions in package.json at the repository root.

The Dart side of the project depends on Flutter, with pubspec.yaml and pubspec.lock at the root and a lib/ directory holding the application code. Models are produced by a code generator rather than written by hand:

dart run build_runner build --delete-conflicting-outputs

Localization strings are generated separately, which matches the l10n.yaml file and the translated README present in the tree:

dart run intl_utils:generate

Builds themselves are wrapped in a tool called nic, invoked through npm scripts. An Android release build is:

nic release -r

The same wrapper has separate targets for a split APK, an Android App Bundle, macOS application builds, and dmg generation, plus a clean target that clears the build cache. One script file also reveals how the app runs its background service on Android, since it is started over adb from a shell script inside the application data directory.

One Dart codebase across mobile, desktop, and the browser

The primary language is Dart, and the framework is Flutter, which is why the repository root carries the platform directories you would expect from a Flutter application: android/, ios/, linux/, macos/, windows/, and web/, with .metadata and analysis_options.yaml at the top level.

The feature list names multi-platform support as Android, Windows, macOS, and Linux, and adds background running on desktop. The presence of ios/ in the tree suggests work has been started for that platform, but the supported-platform list in the documentation does not include iOS, so treat the iOS directory as incomplete.

The responsiveness claim is specific: the layout adapts to different screen sizes and to orientation changes, with automatic adaptation for tablets and smartphones. For a phone-to-phone transfer tool this matters more than usual, since the receiving device is often held in a different orientation from the sender.

The JavaScript side is limited. package.json declares a single dependency, culori, which is a colour handling library, plus the script definitions. The web build exists as a Flutter target for the browser client role rather than as a separate front-end stack.

Where Speed Share is the wrong tool

Several situations rule this project out.

The first is any transfer that leaves the local network. The design is explicitly LAN-based and serverless, so there is no account, no relay, and no way to send a file to someone in another city without adding infrastructure that the project does not provide.

The second is a requirement for finished folder transfer. The feature list marks folder sharing as under reconstruction, and a tool that can move a folder reliably is a different tool from one that moves a folder experimentally.

The third is the maintenance picture. The README carries a notice saying the repository is still under development and maintenance, that the author no longer has much free time after starting a full-time job, and that screenshots and related assets have not been kept up to date. The last push was on 2026-05-14, but the most recent tagged releases, v2.2.8, v2.2.7, and v2.2.6, all date from 2024-10-17. A project can be alive in the branch while the artefacts people install stay put, and here they do.

The fourth is enterprise distribution. The build instructions assume a personal toolchain and a local npm wrapper, so shipping signed, store-ready builds means you take over the release process yourself.

MIT licensed, and a branch that moves faster than its release tags

The project is distributed under the MIT licence, with the licence text in the LICENSE file at the repository root. For a self-hosted utility that is the permissive end of the scale: you can read the code, change it, and redistribute it without the reciprocal obligations that a copyleft licence would impose.

The version story is where the friction is. The releases carry semantic version numbers and the CHANGELOG.md file at the root tracks them, but the newest tags are all from October 2024 while the branch itself received a push on 2026-05-14. That gap is the thing to plan around. If you build from source you get whatever the branch contains, which may be ahead of the last published artefact and may not have been tested by anyone else. If you install a published build you get v2.2.8 behaviour, which predates most of that branch activity.

For a small personal tool this hardly matters. For anything you intend to standardise on inside a team, decide now whether you are pinning to a release or tracking the branch, because the project offers no guarantee that the two stay in step.

Editorial conclusion

Adopt any_share if your file transfers happen inside one office or home network and you want the bytes to stay on that network instead of passing through a hosted service, and if the maintainer release cadence does not block you. Do not adopt it if you need folder sharing today, since the feature list marks that as under reconstruction, or if you need a signed mobile build, since the release artefacts come from a personal build script rather than a published pipeline. Verify three things first: that both devices are on the same LAN segment with UDP discovery unblocked, that the Flutter toolchain and build_runner match the pubspec.yaml at the repository root, and that the version you pick up from the release list, which stops in 2024, still behaves on your Android build.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nightmare-space/any_share on GitHub
4. README
5. Releases