Eigener App-Store — Android-Vertrieb in eigener Hand
Wir verteilen unsere Android-Apps über ein selbst gehostetes F-Droid-Repo plus signierte Direkt-APK, statt Reichweite gegen die Regeln und Provisionen eines fremden Stores zu tauschen. Bestehende unabhängige Kanäle ergänzen, die PWA bleibt überall der Default.
Die PWA-vor-Native-Lösung hält so viel wie möglich aus den App-Stores heraus. Wo wir auf Android trotzdem ein installierbares Paket ausliefern wollen, stellt sich die Anschlussfrage: über Google Play — mit dessen Regeln und Provisionen — oder selbst. Die Recherche zum App-Vertrieb hat sie zugunsten des Eigenbetriebs beantwortet, und diese Lösung hält die Antwort als Struktur fest.
Der Kern ist ein selbst gehostetes F-Droid-Repository. Es verwandelt lose APK-Downloads in einen echten Store: Wer die F-Droid-App hat und unsere Repo-URL einmal hinzufügt, bekommt Liste und automatische Updates — ohne dass ein Konzern dazwischensteht, ohne Provision, in jedem Land. Daneben bieten wir die signierte APK direkt zum Download an und unterstützen Obtainium für alle, die Updates ohne jede zusätzliche App ziehen wollen.
Wir benennen die unbequeme Voraussetzung offen: Voll-native Android-Apps haben wir heute praktisch nicht — unsere Android-Strategie ist bewusst PWA-first. Der erste Store-Inhalt kommt deshalb aus der TWA-Verpackung einer bestehenden PWA, nicht aus einer eigens gebauten nativen App. Diese Lösung ist daher zunächst der souveräne Zweitweg neben der PWA, kein Ersatz für sie — und sie startet als Pilot, nicht als Flotten-Rollout. Erst wenn die Reichweite den Pflegeaufwand trägt, ziehen wir nach. Der Weg dorthin steht im Vorhaben zum eigenen Android-Store.
Wie genau das funktioniert
- Selbst gehostetes F-Droid-Repository via `fdroidserver` (FOSS) unter `fdroid.mana.how/fdroid/repo/`: einmal die URL hinzufügen, danach Liste, Installation und automatische Updates wie in einem App-Store — unter unserer Kontrolle.
- Signierte `.apk` zusätzlich als Direkt-Download auf jeder App-Landing — für alle ohne F-Droid, weltweit und ohne Konto, auch in der Schweiz.
- Obtainium-Source aus den GitHub-Releases als Null-Infrastruktur-Zweitweg: Updates ohne eigenes Hosting, für wer das bevorzugt.
- Signing-Key getrennt vom Webserver, über den Secrets-Standard (SOPS/age) verwahrt; reproduzierbare Builds aus dem Quellcode als Vertrauensanker.
- Inhalte entstehen aus nativen Android-Apps, wo wir sie bauen, und aus TWA-Verpackung (Trusted Web Activity) für PWA-only-Apps — beides signiert und über dasselbe Repo ausgeliefert.
Was uns das kostet
Jeder Lösung hat einen Preis. Diese hier zahlen wir bewusst — weil das, was wir damit erreichen, mit nachgelagerten Tricks nicht ehrlich zu bauen ist.
- Heute haben wir praktisch keine native Android-App — der erste Store-Inhalt kommt aus PWA-Verpackung (TWA). Voll-native Apps wären zusätzlicher Bau, kein Nebenprodukt.
- Eigenbetrieb kostet Hände statt Gebühren: Repo-Pflege, reproduzierbare Builds und Schlüssel-Hygiene über Jahre. Geht der Signing-Key verloren, brechen alle Update-Pfade.
- „Aus unbekannter Quelle"-Warnungen schrecken ab; ein eigenes Repo gewinnt Vertrauen nur langsam und braucht ehrliche Erklärung statt Sicherheits-Theater.
- Die Reichweite ist ungewiss: ob Mitglieder den Eigenweg statt Google Play nutzen, ist unbelegt. Bis Zahlen vorliegen, ist es eine Wette auf Souveränität, nicht auf Masse.
Wo es im Code/in der Doku steht
- Dokuhttps://mana-ev.ch/recherchen/eigener-app-vertrieb-android/ — Recherche — eigenes Repo vs. fremder Kanal
- Dokuhttps://f-droid.org/docs/Setup_an_F-Droid_App_Repo/ — F-Droid — eigenes Repo aufsetzen
- Codehttps://github.com/f-droid/fdroidserver — fdroidserver — Repo- und Build-Tools
- Dokuhttps://github.com/mana-ev/mana/blob/main/docs/ANDROID_STORE.md — ANDROID_STORE.md — ausführbarer Bauplan
Welche Probleme dieser Lösung adressiert
Diagnose ohne Antwort ist Lamentation; Antwort ohne Diagnose ist Ingenieurs-Spielerei. Hier verbindet sich beides.
Offene Punkte
- Pilot-App und reproduzierbarer Build stehen aus; die Infrastruktur (`fdroid.mana.how`, Repo-Container, Signing-Key) ist noch nicht provisioniert.
- Offen: eigenes Repo allein oder zusätzlich ins F-Droid-Hauptrepo (Sichtbarkeit gegen Review-Zeit und ein Stück Kontrollverlust).
- Das Go/No-Go für den Flotten-Rollout hängt an gemessenen Installations- und Update-Zahlen aus dem Pilot.
Weitere Lösungen dieser Art
Wie die Daten fließen — strukturelle Entscheidungen.
- Event-Sourcing als Daten-ArchitekturStatt aktuelle Zustände in einer App-Datenbank zu mutieren, schreiben unsere Apps jede Änderung als unveränderliches Event in einen zentralen, signierten Ledger. Daraus folgt vieles, was sich sonst nicht bauen lässt: Audit-Trail, Cross-App-Timeline, vollständige Lösch- und Export-Pfade, transparente KI-Aktionen.
- Cross-App-Timeline — jede Änderung ist sichtbar, auch KI-ÄnderungenEine zentrale Zeitleiste über alle Vereins-Apps zeigt in Echtzeit, was sich in den eigenen Daten geändert hat — von wem, wann, in welcher App, und ob ein Mensch oder eine KI sie geschrieben hat.
- Föderation statt Lock-InDaten gehen über App-Grenzen hinweg über offene Plattform- Protokolle (Share, Links, Events, MCP, Search), nicht über hauseigene Vendor-APIs. Jede App kann zur Allmende beitragen, jede App kann fortgehen — der Export ist gleichwertig zur internen API.
- Was öffentlich ist, liefern wir statisch ausÖffentliche Lese-Inhalte rendern wir einmal zur Bauzeit zu fertigen HTML-Dateien — nicht bei jedem Aufruf neu auf einem Server. Was keinen Server zum Anzeigen braucht, kann auch nicht mit ihm ausfallen. Zitare ist die App, an der dieses Muster zuerst greift.
Lösungen sind die strukturellen Antworten des Vereins. Werte sagen, wonach wir uns ausrichten; Probleme sagen, wogegen; Lösungen sagen, was wir daraus baulich machen.