Schalte die Funktion aus, ohne neu zu veröffentlichen

Was es ist und warum es zählt

Ein Feature-Flag, also ein Schalter, ist ein Ja oder Nein, das die App liest, während sie läuft. Ist er an, sieht der Nutzer die neue Funktion. Ist er aus, sieht er die alte. Der Code für beide Wege steckt schon in der App: Der Schalter entscheidet nur, welcher genutzt wird.

Das Problem, das er löst, ist einfach. Du veröffentlichst eine Funktion, etwas geht kaputt, und um sie loszuwerden, brauchst du eine weitere Änderung, ein weiteres Deployment, vielleicht wieder das Warten auf die Store-Prüfung. Mit dem Schalter änderst du einen Wert, und die Funktion ist weg. Dann reparierst du sie in Ruhe.

Wenn du mit Claude Code baust, zählt das noch mehr: Du veröffentlichst oft und hast nicht immer jede Zeile gelesen. Das gerade Veröffentlichte abschalten zu können, ohne den Code anzufassen, nimmt dir am Release-Tag viel Stress.

1. Wo ich sie aufbewahre

Ich nutze eine Tabelle „flags“ in der Datenbank, die die App schon verwendet: eine Zeile pro Schalter, mit Name, an ja oder nein, Prozentsatz und einer Liste von Nutzern. Die App liest sie beim Start und ab und zu, während sie offen ist. Ich ändere einen Wert, und die Funktion geht ohne neue Version an oder aus. Wer die App schon offen hat, bekommt die Änderung beim nächsten Lesen der Flags.

Die einzige echte Bedingung ist: Der Wert muss an einem Ort liegen, den du ohne Deployment ändern kannst. Es gibt drei Hauptwege.

• Eine Tabelle in der Datenbank. So mache ich es: nichts Neues zu lernen, und du kannst sie auch über eine eigene Seite ändern.
• Ein Dienst speziell für Feature-Flags oder Remote-Konfiguration. Er bietet dir ein fertiges Dashboard, Prozentsätze und Statistiken. Für den Anfang reicht die Tabelle.
• Eine Umgebungsvariable. Geht auf dem Server, aber bei vielen Hostern braucht eine Änderung ein neues Deployment oder einen Neustart: Prüf, wie dein Hoster sie übernimmt. In einer mobilen App steht sie meist fest im Build.

Als Erstes bitte ich Claude Code um die Tabelle und eine einzige Stelle im Code, über die jede Frage zu den Schaltern läuft, statt zwanzig verstreuter Prüfungen. Mit Claude Code ist alles, was folgt, in ein paar Minuten eingebaut.

Leg eine Tabelle flags an, mit Name, an ja oder nein, Prozentsatz und einer Liste von Nutzern, dazu eine einzige Funktion, mit der die App prüft, ob ein Schalter für den aktuellen Nutzer an ist.

2. Die Funktion kommt ausgeschaltet zur Welt

Jede neue Funktion kommt schon hinter ihrem eigenen Schalter in den Code, ausgeschaltet.

Pack die Funktion X hinter einen Schalter namens neu-x, standardmäßig aus, gelesen aus der Tabelle flags.

Dann veröffentliche ich so. Für die Nutzer ändert sich nichts: Der neue Code ist da, aber er läuft nicht. Das ist die erste der drei Regeln: Kein Wert in der Datenbank kann eine Funktion erscheinen lassen, die nicht in der installierten App steckt.

Bei iPhone-Apps ist das die zweite Regel, und Apple schreibt sie klar hin: Neue Funktionen müssen in den Notizen für die Prüfung beschrieben und für die Prüfer zugänglich sein, versteckte sind verboten. Wenn du eine Funktion ausgeschaltet veröffentlichst, schreib es in die Notizen und erklär, wie man sie sieht.

3. In Stufen einschalten

Ich schalte nie für alle auf einmal ein. Erst für mich, dann für etwa zehn Nutzer, dann für alle.

Sorg dafür, dass neu-x für eine Liste von Nutzern und für einen Prozentsatz eingeschaltet werden kann, immer gleich für denselben Nutzer.

Der Teil „immer gleich für denselben Nutzer“ ist wichtig. Wenn die App bei jedem Öffnen würfelt, sieht dieselbe Person die Funktion heute und morgen nicht. Meist berechnet man aus der ID des Nutzers eine feste Zahl: Liegt sie unter dem Prozentsatz, ist die Funktion an. So behält jeder, der sie schon hatte, sie auch, wenn du den Prozentsatz erhöhst.

Zwischen zwei Stufen schaue ich mir die Fehler und die Nachrichten der Nutzer an. Wenn alles ruhig ist, gehe ich hoch.

4. Wenn das Lesen fehlschlägt, bleibt alles aus

Der Schalter ist schon ein Kill Switch: Macht die Funktion Probleme, schalte ich sie aus, und die alte Version kommt zurück. Aber an einen Fall denkt keiner: Was, wenn die App die Flags nicht lesen kann? Langsame Datenbank, kein Netz, eine versehentlich umbenannte Tabelle.

Wenn das Lesen der Flags fehlschlägt, behandle alle Schalter als aus und zeig die alte Version.

So zeigt die App von selbst die Version, die schon funktioniert hat, wenn das Lesen fehlschlägt. Alles einzuschalten, wenn sie es nicht weiß, ist der schnellste Weg, allen eine halbfertige Funktion zu zeigen.

Dann gibt es die Verzögerung: Wer die App offen hat, sieht die Funktion, bis sie die Flags neu liest, und auch spezielle Dienste halten die Werte meist im Cache. Wie lange ich warten muss, frage ich.

Sag mir, wie lange es im schlimmsten Fall dauert, bis ein Nutzer mit bereits offener App einen Schalter sieht, den ich gerade ausgeschaltet habe, und wo diese Zeit festgelegt wird.

5. Die Tabelle ändere nur ich, und zwar vom Handy

Damit ich die Datenbank nicht am Computer öffnen muss, nutze ich eine Admin-Seite auf dem Handy. Aber vor der Seite kommt der Schutz: Einen Button zu verstecken reicht nicht. Wer die Tabelle ändern darf, muss der Server entscheiden, sonst schaltet jemand Schlaues deine Funktionen an und aus, ohne über die Seite zu gehen. Deshalb macht der Prompt beides in dieser Reihenfolge.

Schütz die Tabelle flags auf dem Server: Die App darf sie lesen, aber ändern darf sie nur mein Account. Dann erstell eine Admin-Seite, nur für mich, mit einem Schalter für jede Zeile.

6. Aufräumen

Ein Schalter, der seit Wochen für alle an ist und gut läuft, wird nicht mehr gebraucht. Bleibt er stehen, ist er alter Code, den keiner testet, und eine Zeile, die früher oder später jemand aus Versehen ausschaltet. Dazu kommt: Mit der Regel aus Punkt 4 fällt die App, wenn das Lesen fehlschlägt, auf die alte Version zurück, selbst bei einer Funktion, die alle nutzen.

Liste die Schalter auf, die seit mehr als einem Monat für alle an sind, und entferne sie aus dem Code, wobei die Funktion an bleibt.

Vor dem Veröffentlichen prüfe ich, dass die Funktion an bleibt, und lösche die Zeile auch aus der Tabelle.

Die drei Regeln

• Der Schalter schaltet nur Code ein, der schon in der veröffentlichten Version ist: Die Funktion muss zuerst ausgeschaltet veröffentlicht werden.
• Bereits veröffentlichten Code abzuschalten braucht keine Prüfung; aber die Stores erlauben keine versteckten Funktionen, die man später ohne Prüfung einschaltet. Flags sind zum Abschalten und zum Einschalten in Stufen da, nicht um neue Funktionen heimlich durchzuschmuggeln.
• Nichts Geheimes in den Flags: Die App liest sie, also kann sie jeder sehen, der will.

Auch der Name zählt: „geheimer-partner-rabatt“ verrät schon zu viel. Schlüssel und Passwörter bleiben auf dem Server.

Häufige Fehler

• Den Schalter einschalten, bevor die Funktion veröffentlicht ist: Nichts passiert, weil der Code nicht da ist. Erst ausgeschaltet veröffentlichen, dann einschalten.
• Einen Schalter, der sich nicht lesen lässt, als an behandeln: Wenn das Lesen fehlschlägt, ist der richtige Wert aus.
• Bei jedem Öffnen würfeln: Der Prozentsatz muss für denselben Nutzer immer dasselbe Ergebnis liefern.
• Nur die Admin-Seite schützen: Auch die Tabelle darf Änderungen nur von deinem Account annehmen.
• Alte Schalter nie entfernen: Die, die seit über einem Monat für alle an sind, gehören aus dem Code.

Checkliste

• Tabelle flags angelegt, eine einzige Funktion zum Lesen
• Die neue Funktion ist ausgeschaltet veröffentlicht
• Prozentsatz stabil für denselben Nutzer
• Wenn das Lesen fehlschlägt, alles aus
• Ich weiß, wie lange es dauert, bis es bei offener App aus ist
• Nur mein Account kann die Flags ändern
• Ab und zu entferne ich Flags, die seit über einem Monat an sind

Häufige Fragen