Vikunja App: a Flutter client for your own to-do server

A client for a server you already control

This repository contains the cross-platform app for Vikunja, which the README describes as the fluffy, open-source, self-hostable to-do app. Vikunja helps you organize tasks, collaborate with teams, and view projects in multiple formats including list, Gantt, table and Kanban views, and it is built with privacy in mind so that you have complete control over your data whether you self-host or use Vikunja Cloud.

The separation matters. The main Vikunja repository, at go-vikunja/vikunja, is the server. This one is the client, and it is a Flutter application written in Dart, with android/, ios/ and web/ directories at the top level of the tree.

That makes the app a good example of the split between a self-hostable backend and a separately released mobile client. A team running its own server already has the data, the collaboration and the API; what it lacks is a phone client that talks to it well. That is the whole scope of this project.

The repository also carries the usual Flutter scaffolding: pubspec.yaml and pubspec.lock, analysis_options.yaml, a .metadata file, integration_test/ and test/ directories, assets/, lib/, a .vscode/ directory, a .drone.yml for CI, a .envrc, and devenv.nix with devenv.yaml and devenv.lock for a reproducible development environment.

The alpha warning is the most useful paragraph

The disclaimer is the most informative part of the README, and it should be read before the feature list.

The app is in alpha pre-release. You must absolutely expect things to not work, and sometimes even break something in the backend. Using the app on important production backends is possible but discouraged. At the same time, the maintainers rely on feedback about missing features and bugs and encourage people to try it out and report on GitHub.

Two conditions follow from that. The app requires the latest stable build of Vikunja to run, and the maintainers are not responsible for lost data and similar destruction.

The second condition is the one people tend to skip. A mobile client for a task server is usually trusted with the same data as the server, and a client that can put the server into a bad state is a different risk category from a client that merely fails to sync. If your server holds team projects that other people depend on, running an alpha client against it is a decision about other people's data, not just your own.

The project also asks contributors to open a pull request and to say so before starting development, so that overlapping work on the same feature can be discussed. For a small team that is a reasonable way to avoid two people building the same screen.

Beta tags from 2024, commits into 2026

The release list shows 0.1.6-beta on 2024-07-21, 0.1.7-beta on 2024-09-13 and 0.1.8-beta on 2024-10-01. The last push to the repository was on 2026-09-14. The repository is not archived, so work is continuing on the tree while the published tags stopped nearly two years ago.

Distribution is split by stability. The latest unstable builds are available on the Google Play Beta and on the download server, while stable releases are available on the download server and on the Releases page. Since every published tag is a beta, in practice the beta channels are where current work lands.

The version numbers explain the state of the project on its own. 0.1.x with a beta suffix means the app is pre-1.0 and pre-stable, which is consistent with the alpha disclaimer and with the fact that the maintainer says the app may break something in the backend.

There is also a community channel. The README links a Matrix room, so the people running the app are in a chat rather than behind a support portal, which is the right shape for a project that expects you to report the first thing that breaks.

Building the app is a Makefile of Flutter commands

The Makefile is short and shows exactly how the project is built and versioned.

GIT_LAST_COMMIT := $(shell git describe --tags --always | sed 's/-/+/' | sed 's/^v//')
FLUTTER ?= flutter

The version comes from the git describe output, and the FLUTTER variable can be overridden, which is what you want when your toolchain lives somewhere other than on the path.

The test target is a single Flutter invocation.

.PHONY: test
test:
	$(FLUTTER) test

The build targets cover the three Android build modes, and each passes the build number explicitly.

.PHONY: build-release
build-release:
	$(FLUTTER) build apk --release --build-number=$(VERSION)

There are matching targets for debug and profile APKs, an iOS release build and an iOS debug build, both with --no-codesign, and a build-all target that chains release, debug and profile. The VERSION variable is set from the Drone build number when one is present and falls back to 1 otherwise, so a local build without CI gets a predictable placeholder.

Code formatting is enforced through the same file, with a format target that runs dart format lib and a format-check target that uses the --set-exit-if-changed flag so a formatting difference fails the check.

Translations run through Crowdin

Localisation is not an afterthought here. The tree carries crowdin.yml and l10n.yaml, and the README points at the documentation page on how to contribute translations or add a new language.

That arrangement is worth understanding, because it is a different workflow from editing translation files by hand. Crowdin is a translation platform, so the workflow is that strings live in the repository, contributors and the community translate them through the platform, and the translated files come back into the repository as the l10n artefacts. The l10n.yaml file is the configuration for the Flutter localization tooling that consumes them.

For a self-hosted application with an international user base, this matters more than it would for a closed source app, because the community that runs Vikunja servers is exactly the community that maintains the translations. The same logic applies to the client app.

The rest of the repository follows the same community-project shape. There is a Renovate configuration for dependency updates and a.drone.yml pipeline rather than a GitHub Actions workflow, which is a detail worth noting if you are used to expecting CI in the.github directory.

The iPhone situation and where this is the wrong tool

The platform story has one large asterisk. If you want to try the app on an iPhone, the maintainer says support cannot be provided, because there is no iPhone to develop on. Contributors have confirmed that it works, and the README invites you to share any bugs you hit with the community.

That is an honest statement of a real constraint, and it is the kind of thing a user should know before planning on the iOS client. The ios/ directory and the iOS build targets exist, but the development loop behind them runs on somebody else's hardware.

The second question is whether you need this app at all. Vikunja is a web application, so a self-hosted installation already gives you a browser interface that works on any phone browser. The differences the app offers are the native ones: a home screen icon, native navigation, and platform integration handled by Flutter. If you do not need those, the browser interface costs you nothing in risk, and it is the version that is not in alpha.

The third consideration is ownership of the risk. Because the app can affect the backend state, the right way to evaluate it is against a server you can restore. A test instance, a snapshot of the database, or a separate instance for the team that wants to try the app are all ways to keep an alpha client away from data you cannot lose.

Editorial conclusion

The Vikunja app suits someone who already runs a Vikunja server and wants a native mobile client for it, and who is willing to file bugs against a pre-release. It does not suit a team that needs a dependable client for a production backend, because the README itself describes the app as alpha, says it may break something in the backend, and disclaims responsibility for lost data. Verify first that your server runs the latest stable build of Vikunja, which the app requires, and that the build you install matches your platform, since the iPhone version is explicitly unsupported by the maintainer.

Frequently asked questions

Official sources

1. go-vikunja/app on GitHub
2. License: MIT
3. Project website
4. README
5. Releases