Ho rimosso l'anonimato dalla mia app, ed e stata la decisione giusta

Ho passato settimane a costruire un sistema di autenticazione anonima che permetteva di usare TAMSIV senza un account. Era elegante, funzionava bene, e ne ero fiero. Questa settimana, ho cancellato tutto. Ecco perché è stata la decisione giusta.

Perché ho rimosso l'autenticazione anonima

Quando ho lanciato TAMSIV in alpha, la lazy registration era un'ovvietà. Secondo AppsFlyer, dal 40 al 60% degli utenti abbandona al momento dell'iscrizione. Rimuovendo questa frizione, pensavo di massimizzare la retention. E ha funzionato, per un po'.

Ma in produzione, la realtà è diversa. Gli account anonimi si accumulavano nel database. Decine di account senza email, senza mezzi di contatto, senza possibilità di recupero. Le metriche del dashboard admin diventavano illeggibili: impossibile distinguere un vero utente da un curioso che ha aperto l'app per 30 secondi.

Il problema di sicurezza era ancora più concreto. Un account anonimo è un account con un UUID e dati, ma senza identità verificabile. Se qualcuno perdeva il telefono, le sue attività e i suoi memo scomparivano con esso. Nessuna email per il recupero. Nessuna password per la protezione. Solo un token effimero su un dispositivo.

Come questa decisione ha semplificato il codice?

[PERSONAL EXPERIENCE] Rimuovendo le sessioni anonime, ho eliminato un numero sorprendente di percorsi condizionali nel codice. Niente più if (isAnonymous) nei servizi. Niente più logica di migrazione da account anonimo a account reale. Niente più pulizia automatica degli account zombie dopo 30 giorni.

Il commit 7a0101d ha interessato l'intero flusso di autenticazione. Al primo avvio, l'utente arriva ora a una schermata di registrazione o di accesso. È più semplice, più prevedibile e garantisce che ogni persona che utilizza l'app abbia fatto una scelta deliberata.

C'è il rischio che questo faccia perdere utenti al momento dell'iscrizione? Probabilmente alcuni, sì. Ma coloro che si iscrivono sono utenti impegnati. Ed è esattamente il tipo di metrica che vogliamo monitorare in produzione.

Il bug del flash modale che nessuno aveva notato

Testando la nuova autenticazione, ho scoperto un bug insidioso. Ad ogni avvio dell'app, la modale dei termini e condizioni d'uso appariva per una frazione di secondo prima di scomparire. Un flash rapido, quasi subliminale. Il tipo di cosa che non noti consciamente, ma che dà un'impressione di mancanza di cura.

[ORIGINAL DATA] Il problema derivava dal timing. L'app caricava il profilo utente da Supabase, e durante questo caricamento, il campo terms_accepted era temporaneamente null. Il componente della modale interpretava questo null come "l'utente non ha accettato i Termini e Condizioni" e si mostrava. Pochi millisecondi dopo, il profilo arrivava con terms_accepted: true, e la modale scompariva.

La soluzione nel commit 8979543: attendere il profilo fresco dal database prima di valutare lo stato della modale. Nessun profilo caricato = nessuna decisione = nessun flash. Semplice, ma bisognava trovarlo. Questo tipo di bug non si riproduce nei test automatizzati perché i mock restituiscono il profilo istantaneamente.

Perché aggiornare una versione per "soli" 3 commit?

[UNIQUE INSIGHT] Nel build in public, la tentazione è forte di raggruppare molti cambiamenti in un'unica release per farla sembrare impressionante. Ho fatto il contrario. L'aggiornamento alla versione 1.04 (commit d900d21, versionCode 39) contiene solo questi tre cambiamenti. Ed è volontario.

Un cambiamento di autenticazione è il tipo di modifica che può rompere le cose in modo sottile. Un utente che aveva un account anonimo, cosa succede quando aggiorna l'app? I token sono invalidi? Il profilo è accessibile? Isolando questo cambiamento in una release dedicata, il debugging è semplice: se qualcosa si rompe, so esattamente dove cercare.

Le piccole release frequenti sono meglio delle grandi release rare. È un principio che applico dall'inizio di TAMSIV, e che mi ha evitato molte notti insonni. Ogni build è uno snapshot testabile. Ogni versione distribuita ha un perimetro chiaro.

Cosa cambia per gli utenti

In pratica, il cambiamento è minimo per chi già utilizzava TAMSIV con un account. Nulla cambia. Le attività, i memo, i gruppi, tutto rimane al suo posto.

Per i nuovi utenti, l'esperienza è diversa ma non necessariamente peggiore. Invece di atterrare direttamente nell'app, passano attraverso una schermata di registrazione. Email, password, fatto. E da lì, i loro dati sono sicuri, sincronizzabili su più dispositivi e recuperabili in caso di perdita del telefono.

Il sistema di autenticazione QR code per l'app web funziona ora per il 100% degli utenti, non solo per quelli che si erano presi il tempo di creare un account. Questo è un vantaggio concreto in termini di UX per la versione desktop.

Le lezioni di uno sviluppatore solista che cambia idea

Cambiare idea su una decisione tecnica è scomodo. Ho scritto un intero articolo sui benefici della lazy registration. E oggi faccio il contrario. È imbarazzante? Un po'. Ma è anche la realtà dello sviluppo: ciò che è ottimale in alpha non è necessariamente ottimale in produzione.

In alpha, con 12 tester reclutati, l'anonimato riduceva l'attrito. In produzione, con utenti reali che si aspettano che i loro dati siano al sicuro, l'iscrizione è un minimo. Il contesto è cambiato, quindi la decisione cambia.

Se stai costruendo un prodotto e sei indeciso tra questi due approcci, la mia raccomandazione è semplice. In pre-lancio, la lazy registration è ottima per convalidare il tuo prodotto. In produzione, l'iscrizione obbligatoria è più saggia. Puoi sempre offrire una prova gratuita generosa per compensare l'attrito.

FAQ

Gli utenti anonimi esistenti perdono i loro dati?

Gli account anonimi che erano stati migrati ad account reali (con email) non sono interessati. Solo gli account rimasti puramente anonimi, senza email associata, non possono più accedere. È prevista una pulizia di questi account orfani.

L'iscrizione richiede molto tempo?

Due campi: email e password. Nessuna verifica via SMS, nessun captcha, nessun modulo lungo. L'obiettivo è rimanere sotto i 30 secondi tra l'apertura dell'app e il primo utilizzo.

Il bug del flash modale influiva sulla sicurezza?

No. Era un problema puramente visivo. La modale dei Termini e Condizioni appariva brevemente e poi scompariva. Nessun dato era esposto e le condizioni rimanevano accettate nel database. Era un difetto di rifinitura, non di sicurezza.