Ich habe die Anonymitat aus meiner App entfernt, und es war richtig

Ich habe Wochen damit verbracht, ein System zur anonymen Authentifizierung aufzubauen, das die Nutzung von TAMSIV ohne Konto ermöglichte. Es war elegant, funktionierte gut, und ich war stolz darauf. Diese Woche habe ich alles gelöscht. Hier ist, warum es die richtige Entscheidung war.

Warum ich die anonyme Authentifizierung entfernt habe

Als ich TAMSIV in der Alpha-Phase startete, war die Lazy Registration eine Selbstverständlichkeit. Laut AppsFlyer brechen 40 bis 60 % der Nutzer den Registrierungsprozess ab. Indem ich diese Hürde beseitigte, dachte ich, die Retention zu maximieren. Und es funktionierte, eine Zeit lang.

Aber in der Produktion sieht die Realität anders aus. Anonyme Konten sammelten sich in der Datenbank an. Dutzende von Konten ohne E-Mail, ohne Kontaktmöglichkeit, ohne Wiederherstellungsmöglichkeit. Die Metriken des Admin-Dashboards wurden unleserlich: Es war unmöglich, einen echten Benutzer von einem Neugierigen zu unterscheiden, der die App 30 Sekunden lang geöffnet hatte.

Das Sicherheitsproblem war noch konkreter. Ein anonymes Konto ist ein Konto mit einer UUID und Daten, aber ohne überprüfbare Identität. Wenn jemand sein Telefon verlor, verschwanden seine Aufgaben und Notizen damit. Keine E-Mail zur Wiederherstellung. Kein Passwort zum Schutz. Nur ein kurzlebiger Token auf einem Gerät.

Wie hat diese Entscheidung den Code vereinfacht?

[PERSÖNLICHE ERFAHRUNG] Durch das Entfernen anonymer Sitzungen habe ich eine überraschende Anzahl von bedingten Pfaden im Code eliminiert. Kein if (isAnonymous) mehr in den Diensten. Keine Logik mehr für die Migration von anonymen zu echten Konten. Keine automatische Bereinigung von Zombie-Konten nach 30 Tagen mehr.

Der Commit 7a0101d betraf den gesamten Authentifizierungsfluss. Beim ersten Start gelangt der Benutzer nun zu einem Registrierungs- oder Anmeldebildschirm. Das ist einfacher, vorhersehbarer und stellt sicher, dass jede Person, die die App nutzt, eine bewusste Entscheidung getroffen hat.

Besteht die Gefahr, dass dadurch Benutzer während der Registrierung verloren gehen? Wahrscheinlich einige, ja. Aber diejenigen, die sich registrieren, sind engagierte Benutzer. Und genau diese Art von Metrik wollen wir in der Produktion verfolgen.

Der Modal-Flash-Bug, den niemand bemerkt hatte

Beim Testen der neuen Authentifizierung entdeckte ich einen heimtückischen Fehler. Bei jedem Start der App erschien das Modal für die Allgemeinen Geschäftsbedingungen für einen Bruchteil einer Sekunde, bevor es verschwand. Ein schneller, fast subliminaler Blitz. Die Art von Sache, die du nicht bewusst bemerkst, aber die einen Eindruck von mangelnder Sorgfalt vermittelt.

[ORIGINAL DATA] Das Problem lag im Timing. Die App lud das Benutzerprofil von Supabase, und während dieses Ladevorgangs war das Feld terms_accepted vorübergehend null. Die Modal-Komponente interpretierte dieses null als "der Benutzer hat die AGB nicht akzeptiert" und wurde angezeigt. Wenige Millisekunden später kam das Profil mit terms_accepted: true an, und das Modal verschwand.

Die Lösung im Commit 8979543: Warte auf das frische Profil aus der Datenbank, bevor der Status des Modals bewertet wird. Kein geladenes Profil = keine Entscheidung = kein Flash. Einfach, aber man musste es finden. Diese Art von Fehler tritt bei automatisierten Tests nicht auf, da die Mocks das Profil sofort zurückgeben.

Warum eine Version für "nur" 3 Commits bumpen?

[UNIQUE INSIGHT] Beim "Build in Public" ist die Versuchung groß, viele Änderungen in einem einzigen Release zu bündeln, damit es beeindruckend wirkt. Ich habe das Gegenteil getan. Der Bump auf Version 1.04 (Commit d900d21, versionCode 39) enthält nur diese drei Änderungen. Und das ist Absicht.

Eine Authentifizierungsänderung ist die Art von Änderung, die Dinge auf subtile Weise kaputt machen kann. Ein Benutzer, der ein anonymes Konto hatte, was passiert, wenn er die App aktualisiert? Sind die Tokens ungültig? Ist das Profil zugänglich? Indem ich diese Änderung in einem dedizierten Release isoliere, ist das Debugging einfach: Wenn etwas kaputt geht, weiß ich genau, wo ich suchen muss.

Kleine, häufige Releases sind besser als große, seltene Releases. Das ist ein Prinzip, das ich seit Beginn von TAMSIV anwende und das mir viele schlaflose Nächte erspart hat. Jeder Build ist ein testbarer Snapshot. Jede bereitgestellte Version hat einen klaren Umfang.

Was sich für die Benutzer ändert

In der Praxis ist die Änderung minimal für jemanden, der TAMSIV bereits mit einem Konto genutzt hat. Nichts ändert sich. Aufgaben, Notizen, Gruppen, alles bleibt erhalten.

Für neue Benutzer ist die Erfahrung anders, aber nicht unbedingt schlechter. Anstatt direkt in der App zu landen, durchlaufen sie einen Registrierungsbildschirm. E-Mail, Passwort, fertig. Und von da an sind ihre Daten sicher, auf mehreren Geräten synchronisierbar und im Falle eines Telefonverlusts wiederherstellbar.

Das QR-Code-Authentifizierungssystem für die Web-App funktioniert jetzt für 100 % der Benutzer, nicht nur für diejenigen, die sich die Zeit genommen hatten, ein Konto zu erstellen. Das ist ein konkreter UX-Gewinn für die Desktop-Version.

Die Lehren eines Solo-Entwicklers, der seine Meinung ändert

Die Meinung zu einer technischen Entscheidung zu ändern, ist unangenehm. Ich habe einen ganzen Artikel über die Vorteile der Lazy Registration geschrieben. Und heute mache ich das Gegenteil. Ist das peinlich? Ein bisschen. Aber es ist auch die Realität der Entwicklung: Was in der Alpha-Phase optimal ist, ist nicht unbedingt in der Produktion optimal.

In der Alpha-Phase, mit 12 rekrutierten Testern, reduzierte die Anonymität die Reibung. In der Produktion, mit echten Benutzern, die erwarten, dass ihre Daten sicher sind, ist die Registrierung ein Minimum. Der Kontext hat sich geändert, also ändert sich die Entscheidung.

Wenn du ein Produkt entwickelst und zwischen diesen beiden Ansätzen zögerst, ist meine Empfehlung einfach. Vor dem Start ist die Lazy Registration großartig, um dein Produkt zu validieren. In der Produktion ist die obligatorische Registrierung klüger. Du kannst immer eine großzügige kostenlose Testphase anbieten, um die Reibung auszugleichen.

FAQ

Verlieren bestehende anonyme Benutzer ihre Daten?

Anonyme Konten, die zu echten Konten (mit E-Mail) migriert wurden, sind nicht betroffen. Nur die rein anonym gebliebenen Konten ohne zugehörige E-Mail können sich nicht mehr anmelden. Eine Bereinigung dieser verwaisten Konten ist geplant.

Dauert die Registrierung lange?

Zwei Felder: E-Mail und Passwort. Keine SMS-Verifizierung, kein Captcha, kein langes Formular. Ziel ist es, unter 30 Sekunden zwischen dem Öffnen der App und der ersten Nutzung zu bleiben.

Hat der Modal-Flash-Bug die Sicherheit beeinträchtigt?

Nein. Es war ein rein visuelles Problem. Das AGB-Modal wurde kurz angezeigt und verschwand dann. Es wurden keine Daten offengelegt und die Bedingungen blieben in der Datenbank akzeptiert. Es war ein Schönheitsfehler, kein Sicherheitsproblem.