Il mio stack per una app mobile da solo

Questo è lo stack di CalAlly, l'app di tracking nutrizionale a voce che sto costruendo. È lo stesso di quello che uso per una web app sotto il cofano, e cambia solo il pezzo che disegna e consegna l'interfaccia.

Otto strumenti: due specifici del mobile e sei che restano identici. Il fatto che siano identici non è una coincidenza, è il punto: se avessi dovuto imparare un backend nuovo per fare una app, l'app non l'avrei fatta.

I due pezzi che rendono l'app una app

React Native: una base di codice per iOS e Android. Da solo non esiste l'alternativa di mantenere due app native, quindi la domanda non è se il nativo sia meglio, perché lo è: è quale delle due app riuscirei effettivamente a tenere aggiornata. La risposta onesta è nessuna delle due.

C'è anche un secondo motivo, meno nobile e più pratico: React Native è React. Il modello mentale dei componenti e dello stato è lo stesso che uso sul web, quindi il passaggio da un progetto all'altro non mi costa un cambio di testa.

Expo: la parte che rende React Native gestibile da una persona sola, ed è quella che sottovalutavo prima di provarci. Il codice dell'app è la parte facile. La parte che ti mangia le giornate è tutto quello che sta intorno: build per due piattaforme, certificati, profili di provisioning, versioni, caricamenti sugli store.

Expo prende quel pezzo e lo riduce a un comando. E soprattutto permette di mandare aggiornamenti senza ripassare ogni volta dalla revisione degli store, che quando sei solo è la differenza tra correggere un errore in mezz'ora e correggerlo la settimana dopo.

I sei che sono già quelli del web

Qui sta il vantaggio vero di aver ripetuto lo stesso stack per tre progetti: quando ho iniziato l'app, questa metà era già decisa.

Supabase: database, autenticazione e storage. Sul mobile conta una cosa in più rispetto al web: le regole di accesso stanno nel database, non nel client. Un'app la installi sul telefono di qualcuno, e qualunque controllo scritto solo nell'app è un controllo che si può aggirare. Con le regole a livello di database la superficie si riduce a un punto solo.

Resend: mail transazionali. Conferme, reimpostazione della password, tutto quello che parte da un'azione nell'app.

PostHog: prodotto e analytics. Sul mobile serve più che sul web, perché non puoi guardare qualcuno usare l'app da sopra la spalla: l'unica cosa che ti dice se qualcuno ha capito una schermata è il comportamento.

Featurebase: help center e raccolta feedback. In pre-lancio con dei tester è lo strumento che uso di più, perché tiene insieme richieste e segnalazioni in un posto pubblico invece che in venti messaggi separati.

Namecheap: domini. Anche una app ne ha bisogno: pagina di presentazione, link agli store, informativa privacy, che gli store chiedono e che deve stare da qualche parte.

GitHub: codice e cronologia, come su tutto il resto.

Cosa cambia davvero fra web e mobile

Il codice, meno di quanto pensassi. Il resto, parecchio.

• La distribuzione non è più tua. Sul web pubblichi quando vuoi. Sugli store c'è una revisione in mezzo, e va messa in conto nella pianificazione invece che scoperta al primo rifiuto.
• Le versioni vecchie restano in giro. Un sito lo aggiorni per tutti insieme. Un'app no: c'è gente che tiene la versione di due mesi fa, quindi il backend deve continuare a rispondere anche a quella.
• Non vedi niente senza analytics. Sul web ho i log del server e la Search Console. Su un'app installata, senza strumentazione sei cieco.
• Il primo utente costa di più. Aprire un link è gratis, scaricare un'app no. È il motivo per cui la pagina che spiega il prodotto conta ancora più che sul web.

Cosa non uso, di proposito

• Niente notifiche push nella prima versione. Sono la cosa che tutti mettono per prima e che quasi nessuno merita. Finché non so cosa riporta indietro le persone, una notifica è solo un modo per farsi disinstallare.
• Nessuna libreria di componenti pesante. Stessa ragione del web: da solo, il debito nascosto in una dipendenza costa più della riga in più.
• Nessun abbonamento prima di aver capito cosa si paga. I pagamenti in-app hanno regole, commissioni e casi limite che non vuoi imparare mentre stai ancora cercando di capire se il prodotto serve a qualcuno.