kitshn: a Compose client for self-hosted Tandoor Recipes

A third party client for a self-hosted recipe server

kitshn is an unofficial multiplatform client for the self-hostable Tandoor Recipes application, and that word unofficial is load bearing. Tandoor is server software you run yourself, and kitshn is a separate app that talks to it.

The framing matters for anyone evaluating it. Tandoor Recipes is the source of truth for your recipes, meal plan and shopping list, and the server is what you deploy. kitshn is a client for that API, not a fork of it and not a replacement. If your Tandoor instance disappears, your data is still in your instance, and kitshn is the app that happens to talk to it.

The technology choice is the other headline. The app is built with Compose and the expressive design system that goes with it, and it is developed for Android, iOS and Desktop, in Kotlin. The repository layout shows the multiplatform structure explicitly, with an androidApp directory, an iosApp directory, a desktopApp directory, a composeApp directory and a shared directory, alongside a web directory and an e2e directory for end to end tests. There is also a flatpak directory, which is how the desktop build reaches Linux users outside the app stores.

The package id is de.kitshn.android, which appears in both the F-Droid listing and the Google Play listing, and the Apple App Store entry is under the name kitshn for Tandoor.

The project is GPL-3.0 licensed, the default branch is main, and the release history shows 2.1.3 on 2026-09-09 and 2.1.4 on 2026-09-16, with the last push on 2026-09-17. The release list also includes a nightly tag from 2024-11-03, which suggests nightly builds are a separate track from the versioned releases.

Cooking mode and the timer detection feature

The recipe features are where the client earns its place, because a self-hosted recipe server and a generic client give you the same data while the client gives you the cooking.

Cooking mode is the centrepiece. Within it, the app can create timers, and the README links a dedicated documentation page for timer detection. That is a feature worth understanding, because it is the difference between a recipe viewer and something you can actually cook from. A timer that has to be set by hand for every step is friction, and detecting times written in the step text and offering them as one-tap timers removes it. The details of how the detection works are on the project's own documentation site rather than in the README, which links to kitshn.app for each feature.

App links and share links are two halves of the same idea. The app links support lets you share links with kitshn for import, and the share wrapping feature is a separate page. Social media importing is listed under importing and is explicitly powered by AI, so a link to a recipe on a social platform can become an import candidate. That is a genuinely useful feature for a self-hosted collection, because most recipes begin life as a link somewhere and the friction of retyping them is what stops people adding them.

Two more recipe features are less exotic but more used. There is Markdown support, so a recipe written with formatting in Tandoor renders as formatting, and there is an easy ingredient allocation tool, which is the step where you decide how much of each ingredient you need for the number of servings you are cooking for.

Shopping mode, offline sync, and the rest of the app

The shopping list is the other half of a recipe app, and kitshn treats it as a first class feature rather than a plain list.

Shopping mode is a distinct mode, and the screenshots show a different layout for it from the ordinary list view, so it is a designed screen rather than a checkbox list with a different title. Underneath it there is offline sync, which is the feature that changes how usable a shopping list is in practice. A shopping list is used in a supermarket, which is exactly where a phone's connection is least reliable, so being able to tick items off without a network round trip and reconcile later is not a nicety.

The rest of the feature list covers the parts a recipe application is expected to have. A meal plan is present, along with recipe books and a favourites system with its own documentation page. The home screen is dynamic, and the UI layer includes dynamic colour customization, which lets the app take the system palette, and an adaptive layout for phones, tablets and foldables.

That last item is the one that reflects the multiplatform ambition. A single Compose codebase serving a phone, a tablet and a foldable means the layout has to adapt rather than scale, and the screenshots in the README are split into seven inch and phone sets, which suggests the same content is being laid out for two very different shapes.

The dark mode and light mode support is handled through separate asset variants, and the README ships both sets of screenshots so you can see the two themes side by side without installing anything.

Verifying the Android build, and where to get each platform

The installation section gives four destinations. GitHub releases is the primary one, with a badge linking there. F-Droid carries the package de.kitshn.android, Google Play carries the same package id, and the Apple App Store carries kitshn for Tandoor under a different identifier. The desktop build is not in a store, so the GitHub releases and the flatpak directory in the repository are the route.

The certificate fingerprints section is the part to read carefully if you sideload. The README publishes the SHA1 and SHA256 fingerprints of the signing key:

SHA1:
CC:1A:8C:30:9B:DF:36:67:CE:E6:AC:FA:5D:74:FA:6A:56:70:73:A4

SHA256:
5D:1A:9A:D4:16:24:6D:76:75:3F:51:57:7E:00:CD:6D:72:DC:7C:3F:36:F5:F3:EC:1F:CB:DB:2B:C8:DD:31:7D

Publishing these is a small courtesy with a real purpose. If you install an APK from the releases page, you can confirm that it was signed by the same key as the one in the README, which is what tells you the build came from this project and not from someone who repackaged it. A project with a published fingerprint has nothing to hide about its signing key, and that matters most for the GitHub release route where you are installing a binary yourself.

Localisation is handled through Weblate, with a hosted project and a widget showing the translation status. Contributions are invited there, which for a project with contributors across time zones is a more workable model than a translation file and a pull request.

Where kitshn is the wrong tool

The first wrong case is a team that needs a supported client for Tandoor. The app says it is unofficial, and that means there is no guarantee of API compatibility when Tandoor changes its endpoints. An unofficial client against a server you do not control is a normal arrangement in self-hosted software, and it is exactly the arrangement that breaks when the server moves and the client has not caught up.

The second is a user who does not run their own server. kitshn is a client for a self-hostable application, so if your recipes live in somebody else's instance, you have to be happy to use a third party app pointed at a server you do not administer, with a third party app's idea of your account and your data.

The third is a project that needs the server side. The web directory in the repository is the project's own website and documentation, and the app is the deliverable. If you want to change how Tandoor stores or exposes data, you are in the wrong repository entirely.

The fourth is a strict platform requirement. This is a Kotlin Multiplatform project, and the platforms it supports are the ones named: Android, iOS and desktop, with the web directory serving the project site rather than a web client of the app. There is no browser version of the client itself, so a recipe app that has to run in a browser tab is not covered by this project.

The alternative worth weighing is the Tandoor web interface itself, which runs in any browser and needs no installation at all. You give up the native cooking mode, the timer detection, the offline shopping list and the adaptive layouts, and in exchange you have something that works on a shared computer or a locked down work laptop where you cannot install an app. For occasional use, that trade is often the right one.

Editorial conclusion

Adopt kitshn if you run your own Tandoor instance and want a native-feeling client on your phone, tablet and desktop with cooking mode, timers and an offline-capable shopping list. Keep away if you want an official client or a project with a clear upstream relationship, because the app is explicitly unofficial and ships from its own releases. Before you install the Android build, check the published certificate fingerprints against the SHA1 and SHA256 values in the README, since they are there so you can verify the signer, and note the release list is on a rolling schedule with 2.1.4 published on 2026-09-16 and the last push on 2026-09-17.

Frequently asked questions

Official sources

1. kitshn-app/kitshn on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases