Hammer is a local-first story editor that syncs across five platforms

A simple promise, with the platform list doing the heavy lifting

The description of Hammer is two words long, a simple tool for building stories, and the project site is hammer.ink. The readme is not long either, and the parts of it that carry the most information are the badges and the availability table rather than the prose. The badges state the language and the licence, the build status, a Codacy grade badge, codecov coverage, platform badges for android, ios, windows, linux and macos, a Discord link and a Crowdin localisation badge. The platform badges are the real summary. This is a single Kotlin application that runs on a phone and on a desktop, which in practice means Kotlin Multiplatform with Compose for the user interface, and the repository layout backs that up with separate android/, ios/, desktop/, common/, base/ and composeUi/ directories, plus a shared build.gradle.kts, settings.gradle.kts, gradle.properties and a buildSrc/ directory for custom build logic. The repository default branch is develop, which is a signal that this is an actively developed project rather than a one-off experiment.

Five platforms means five different ways to install it

The availability table is where the engineering effort of a multiplatform app shows. Android is on Google Play and on F-Droid, and there is a direct .apk download from the GitHub releases, with the badge pointing at a hammer.apk asset. iOS is on the App Store and has no direct download. Windows is on the Microsoft Store. The table also lists a direct download column for Linux and macOS, and the repository shows how many shapes that takes: a docker/ directory, a flatpak/ directory, a snap/ directory, an msix/ directory for the Windows package, a fastlane/ directory for store submission, and a scripts/ directory to drive the packaging. So a user on Linux can take a flatpak or a snap, a Windows user can take the MSIX or the store build, and an Android user can sideload the APK. The F-Droid listing matters more than it looks, because it means the app is built from source rather than wrapped by a store, which is the usual reason a privacy conscious writer ends up there in the first place. The routes worth bookmarking are these.

https://f-droid.org/en/packages/com.darkrockstudios.apps.hammer.android/
https://hammer.ink

Local-first is the design, sync is the addition

The repository topics are the clearest statement of the philosophy, and they are worth reading in order: local-first, offline, sync, writing, writing-software, writing-tool, story-creation, multiplatform, compose, compose-desktop, android, kotlin. Local-first comes before everything else, which is the convention in that movement for an application where your data lives on your device and the network is an optimisation rather than a requirement. Offline appears next to it, and sync after that, so the ordering says the same thing. The repository carries a server/ directory, which is where a sync backend would live, and a PRIVACY.md file, which is what a project that stores your manuscripts on your own machine and still has a server component needs to publish. There is also a wear/ directory, which is a Wear OS target, and given the tool is for writing, a watch companion for capture is a plausible reason for it to be there.

The toolchain is a full multiplatform production setup

The build system and the repository files show a project with a real release process rather than a build script. There is a gradlew and gradlew.bat wrapper, so the build is versioned with the project, and a gradle/ directory alongside it. The .run/ directory holds IDE run configurations, and DEVELOPMENT.md is present as a separate document, which is the right place for the contributor-facing instructions. The CI and quality setup is unusually broad for a writing app. There is a build.yml workflow badge, a .semgrep/ directory for static analysis, a .gitleaks.toml for secret scanning, a .codacy.yaml configuration matching the Codacy badge, a codecov.yml matching the coverage badge, an .editorconfig, a .dockerignore, and a scripts/ directory. The integrationTests/ directory at the root indicates that there is a test suite that goes beyond unit tests, and a CHANGELOG.md and a SUPPORT.md round out the repository as one that expects outside contributions.

Translation is handled by Crowdin, and the version lines are uneven

Localisation runs through Crowdin, with a crowdin.yml in the repository root and a Crowdin badge in the readme, which is the standard arrangement for pulling translations from a crowd rather than maintaining them in pull requests. The release tags show a slightly untidy picture that is worth reading before you pin a version. There is v3.12.0 from 2026-10-05, v3.11.0 from 2026-09-25, and then v3.10.1+google-play from 2026-09-23, where the build metadata suffix indicates a store specific build of the same underlying version. So the same application is published through several channels and the versions across those channels do not line up exactly. For a user installing from the Microsoft Store or Google Play against a direct download, that is the situation to expect. The last push was on 2026-10-20, the same day as the tag, so the tree is current.

What the project does not claim to be

The readme for Hammer is short, and reading it as a document says as much about the project as what it contains. There is no feature list, no architecture description, no data format documentation and no statement about collaboration. There is also no release notes in the readme, though the repository carries a CHANGELOG.md, and no explicit statement about sync semantics, conflict handling or whether a project can be shared between two people editing at once. A collaborative writing tool would have to say something about locking, and this one does not. The safest reading is that Hammer is a personal writing environment with optional synchronisation, and that the sync feature is the one to test carefully before depending on it. The other limit is platform reach. A Compose Multiplatform desktop application on five operating systems carries a maintenance cost that shows up in small UI differences between platforms, and the repository does not describe how those are handled. The naming, the licence and the local-first stance are clear, but the product documentation lives on the project site rather than in the repository, so evaluating the tool properly means reading hammer.ink rather than the readme.

Editorial conclusion

Hammer suits a writer who wants to work on a laptop and a phone with the same project and no account, since the tool is local-first and offline with sync as an addition rather than a requirement. It is the wrong tool for a team that needs collaborative editing, locking and permissions today, because the sync story in the repository is a server directory and a topic tag rather than a documented conflict model. Before adopting it, check the direct download routes for your platform, because the store and the packaged build can be at different versions, and read PRIVACY.md, which the repository carries as a separate file. The last push was on 2026-10-20 and the current release is v3.12.0 from 2026-10-05.

Frequently asked questions

Official sources

1. Darkrock-Studios/hammer-editor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases