# Yagni Launcher: a stock Android launcher built from scratch

> Yagni Launcher is a Kotlin and Jetpack Compose replacement for the Android home screen, split into clean architecture modules and distributed as an alpha build of roughly 2 MB. It fits users who want a tracker-free launcher, and it does not yet fit anyone who needs a stable release.

**T31n/YagniLauncher** — Stock Android Launcher From Scratch

- Repository: https://github.com/T31n/YagniLauncher
- Stars: 682 · Forks: 42
- Language: Kotlin
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/t31n-yagnilauncher

## A home screen replacement written in Compose, not a themed skin

Yagni Launcher describes itself as a stock Android launcher built from scratch. The word stock matters here: the intent is to match and extend what the Android system launcher already does, without the extra layers that third-party launchers tend to accumulate. The stated motivation is equally blunt, with closed-source launchers described as locking features behind paywalls and adding trackers, and the goal stated as offering features with no compromise on privacy.

The project takes its name from a piece of extreme programming doctrine. YAGNI, expanded in the README as You Aren't Gonna Need It, holds that functionality should not be added until it is deemed necessary. That principle explains the module structure better than any marketing description would.

The implementation is Kotlin with Jetpack Compose, and the repository topics list launcher3 alongside android-clean-architecture, kotlin-coroutines and jetpack-compose. So this is a modern rewrite rather than a fork of an older launcher codebase, with the Compose UI toolkit and coroutines doing the work.

The size claim is the headline number. The README puts the launcher at roughly 2 MB and describes it as 80 to 90 percent smaller than typical stock launchers, with minimal resource and battery use listed as a design goal. Whether that translates into a measurable difference on your device depends on what you compare against, but the stated intent is clear and the number is the one the project publishes.

## The module split: app, feature, domain, data, service and design-system

The top-level layout reads like a clean architecture textbook applied to an Android app. There is an app/ module for the application itself, a feature/ directory for individual screens, domain/ for business logic, data/ for persistence, service/ for background work, framework/ for platform integration, design-system/ for shared UI primitives, common/ for utilities, and ui/ for shared Compose code. Alongside those sit build-logic/ for Gradle convention plugins, spotless/ for formatting, fastlane/ for release metadata, docs/ for documentation, and the standard Gradle files including settings.gradle.kts and gradlew.

That separation has a practical consequence for anyone reading the code or contributing. A change to how a widget is laid out lands in feature/ or ui/, a change to what the launcher stores lands in data/, and a change to what the launcher decides lands in domain/. The launcher3 topic suggests the Android launcher role is modelled as its own concern rather than tangled with the home screen rendering.

Contributors are pointed at a specific document first. The README recommends reading the Yagni Launcher Architecture document in docs/ARCHITECTURE.md before contributing, which tells you the architecture is documented rather than implied.

The build tooling is standard modern Android practice. Kotlin build scripts, a Gradle wrapper, a separate compose_compiler_config.conf file for Compose compiler settings, and a dedicated spotless/ directory for code formatting all point to a build that expects Gradle and the Android toolchain rather than a bespoke script.

## Getting it onto a phone: F-Droid, IzzyOnDroid or an alpha release

There is no installation script to copy here, and the project does not need one. The README points to two app stores and to GitHub releases for the alpha build.

On F-Droid the package name is com.eblan.launcher, and the same identifier appears in the IzzyOnDroid listing, with a direct link to the package at apt.izzysoft.de. Both stores carry a version badge in the README, so you can check which build is current before installing. GitHub releases carry a separate badge, and the release list shows that the current line is a sequence of alpha tags.

So the practical sequence for a first run is short. Install com.eblan.launcher from F-Droid or IzzyOnDroid, grant it the home screen role when Android asks, and then look at what it gives you. Expect to spend a few minutes with the layout options, because the README does not enumerate individual features, only the general claim of matching and extending stock behaviour.

If you would rather build from source, the repository includes the Gradle wrapper as gradlew together with settings.gradle.kts and the build-logic/ module, which is the standard Android multi-module layout. The README does not document a specific build command, an Android Studio version, or a minimum SDK level, so those details have to come from the Gradle files themselves or from the architecture document in docs/.

One thing to check before you commit to it: the README carries a warning that this is an alpha stage build and tells users to expect bugs, instability and incomplete features. That is the project's own description of the software, not a reviewer's judgement.

## An alpha line that moves several times a week

The release history is short and dense. Three tags appear in recent history: v1.0.4-alpha on 2026-10-15, v1.0.5-alpha on 2026-10-15, and v1.0.6-alpha on 2026-10-18. The last push to the repository was on 2026-10-20, which is after the newest tag. The project is not archived.

That cadence has two sides. For someone who wants the launcher, frequent alpha tags mean visible progress and a current build whenever a F-Droid or IzzyOnDroid sync runs. For someone who wants stability, it means the version you install is a moving target, and an update can change behaviour without a stable release to fall back to.

The alpha labels are honest about this. The README warning names bugs, instability and incomplete features, and it is placed at the top of the file rather than buried. The project is not pretending the alpha tag is a stability guarantee.

There is also a stated contribution policy that shapes who can help. The README notes that AI tools such as CodeRabbitAI are welcome for reviewing pull requests, but that bot-submitted pull requests or unreviewed generated code are not, and every contribution must be understood and stood behind by a human. Translations are handled through Weblate rather than by direct edits, with the translation status widget hosted on the Weblate project page.

For an adopter, this is a small project with a fast release rhythm and an explicit human-review policy, which reads as a deliberate choice rather than an accident.

## Where Yagni Launcher is the wrong tool

The first case is obvious and the project says it outright: anyone who needs a dependable daily driver. If a broken home screen means a phone you cannot use, an alpha launcher is the wrong dependency, and the warning in the README is the reason, not a guess.

The second case is feature comparison. The claim is that the launcher matches and extends stock functionality, and the project lists three attributes, modern, small and efficient. What is missing from that list is a feature catalogue. There is no list of gestures, widgets, icon packs, search providers or notification behaviour anywhere in the README, and the documentation points to an architecture document for contributors rather than a user manual. If your must-have feature is something the stock Android launcher does not already do, you will have to read the source to find out whether it is there.

The third case is distribution and privacy in a workplace context. The privacy argument is about closed-source launchers adding trackers, which is a claim about what this project does not include rather than a guarantee about what a modified build does. If you are adding your own analytics or a proprietary widget, you leave the privacy story behind.

The fourth case is forking. A GPL-3.0 licence is a deliberate choice for a launcher that people might want to modify for their own device, but it is a real constraint for anyone planning to base a commercial product on the code.

## Licence, privacy posture and the cost of running an alpha on your phone

Yagni Launcher is licensed under the GNU General Public License v3.0, with the full text in the LICENSE file at the root of the repository. That means you can read, modify and redistribute the code under the GPL's terms, and if you distribute a modified build you have obligations that come with it. This article does not interpret what those obligations are for your specific situation, but the licence is the thing to check before you plan anything beyond personal use.

The privacy angle and the licence angle are related in practice. A launcher sits on the home screen, which means it can see which apps you tap and when, and it holds the list of what is on your device. The README's argument is that open source and a tracker-free build address that concern. The practical check for an adopter is what the app declares and does at install time on the device, which the documentation does not walk through.

Upgrade cost is low in the tooling sense and high in the tolerance sense. Because releases are published as alpha tags through the usual store channels, installing an update is the same action as any other F-Droid app, and the multi-module Gradle layout means a contributor has conventional build tooling to learn. What you are signing up for is periodic review of alpha builds, with the README explicitly promising bugs and incomplete features along the way.

## Conclusion

Adopt Yagni Launcher if you want a home screen replacement with no closed-source features behind a paywall and no trackers, and you are comfortable testing alpha software. Do not adopt it as a daily driver for a phone you cannot afford to break, and do not fork it into a product without reading the GPL-3.0 terms. Verify first that the launcher does what your workflow needs, since the README does not enumerate individual features, and that you can update it yourself, because the release line is a sequence of alpha tags and the last push was on 2026-10-20.

## FAQ

### Is Yagni Launcher available on F-Droid?

Yes. The README carries a F-Droid badge for the package com.eblan.launcher and a separate IzzyOnDroid badge for the same package, plus a GitHub release badge for the alpha builds.

### Is Yagni Launcher stable enough to use every day?

The README states that this is an alpha stage build and warns users to expect bugs, instability and incomplete features. Recent tags are v1.0.4-alpha, v1.0.5-alpha and v1.0.6-alpha.

### What licence does Yagni Launcher use?

It is licensed under the GNU General Public License v3.0, with the full text in the LICENSE file in the repository root.

### How small is the Yagni Launcher app and what is it built with?

The README describes it as around 2 MB and 80 to 90 percent smaller than typical stock launchers, built with Kotlin and Jetpack Compose and organised into modules such as app, feature, domain, data, service, framework and design-system.

## Sources

- [Issues](https://github.com/T31n/YagniLauncher/issues)
- [License: GPL-3.0](https://github.com/T31n/YagniLauncher/blob/master/LICENSE)
- [README](https://github.com/T31n/YagniLauncher/blob/master/README.md)
- [Releases](https://github.com/T31n/YagniLauncher/releases)
- [T31n/YagniLauncher on GitHub](https://github.com/T31n/YagniLauncher)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/t31n-yagnilauncher