App mobile o web app? Quando serve davvero un’app sugli store
Partite da dove verrà usato, non dalla tecnologia
Se il prodotto si usa in ufficio, con una connessione decente, e il telefono serve solo a guardare o inserire dati, una web app basta nella grande maggioranza dei casi.
"Ci serve un'app" è una delle frasi che sentiamo più spesso nelle prime call. Si capisce, perché l'app sugli store sembra la versione seria di un prodotto. Però un'app nativa porta con sé dei vincoli prima ancora dei vantaggi. Sono due piattaforme da mantenere, iOS e Android, le regole di revisione degli store e gli aggiornamenti che una parte degli utenti non installerà mai. Sono costi che hanno senso quando il telefono deve fare qualcosa che il browser fa male.
Due parole sui termini, perché vengono usati in modo confuso. Una web app è un'applicazione vera, con login, dati, permessi e logica, che si apre dal browser. Una PWA (progressive web app) è una web app che si aggiunge alla schermata iniziale e funziona in parte anche senza rete. Un'app nativa si scarica dagli store e ha accesso completo al dispositivo.
Quando l'app nativa serve
Serve quando il prodotto dipende dal dispositivo. I casi sono pochi e si riconoscono subito.
Il primo è il lavoro senza rete. Pensate al tecnico in cantiere, all'operatore in uno scantinato, al magazzino dove il segnale va e viene. Se chi lavora deve poter compilare un intervento completo offline e sincronizzare più tardi, l'app nativa regge questo scenario molto meglio.
Il secondo è l'hardware. Bluetooth verso strumenti esterni, fotocamera usata tutto il giorno, lettura di codici, GPS in background. Il browser ne supporta una parte, ma in modo diverso da un dispositivo all'altro e da un sistema operativo all'altro.
Poi ci sono le notifiche. Su iOS quelle delle web app esistono, ma sono più limitate, e se il prodotto vive di promemoria che devono arrivare in tempo la differenza si sente. Infine gli store stessi: per un prodotto consumer, farsi trovare su App Store e Google Play è parte della distribuzione.
Due esempi dal nostro lavoro. Un'app per tecnici della manutenzione, che sul campo registrano interventi e ricambi. E un'app per operatori dell'assistenza domiciliare che si collega via Bluetooth ai dispositivi medici e rileva i parametri a casa del paziente. In tutti e due i casi il telefono era lo strumento di lavoro, non uno schermo per consultare dati.
Quando basta il browser
Basta quando il valore sta nei dati e nei processi. Gestionali, portali per i clienti, pannelli di amministrazione, strumenti interni usati dalla scrivania.
Qui la web app ha vantaggi netti. Un aggiornamento arriva a tutti nello stesso momento, senza passare dagli store. La stessa base di codice gira su computer, tablet e telefono. E non c'è niente da installare, cosa che conta parecchio quando dovete far usare il sistema a clienti o fornitori esterni.
Per un MVP è spesso la scelta più sensata anche se un giorno servirà l'app. Vi permette di mettere il prodotto in mano a utenti veri in poco tempo e di decidere più avanti, con dati reali, se l'app nativa si ripaga. Ne parliamo in cosa entra davvero in un MVP da 6-8 settimane.
Il costo che si vede dopo
Lo sviluppo iniziale di un'app nativa è la parte meno pesante del conto. Quella pesante è mantenere due piattaforme per tutta la vita del prodotto, perché ogni funzionalità nuova va portata, testata e pubblicata due volte.
Esistono strumenti che permettono di scrivere una sola base di codice per iOS e Android, e oggi funzionano bene. Riducono il lavoro, senza azzerarlo. Restano due store con regole diverse e due cicli di revisione, gli aggiornamenti dei sistemi operativi che ogni anno chiedono qualche adeguamento, gli utenti fermi su versioni vecchie.
In più un'app nativa raramente vive da sola. Accanto c'è quasi sempre una parte web, il pannello per chi gestisce o l'area riservata ai clienti. Il conto quindi va fatto sul prodotto intero e su più anni, come spieghiamo nell'articolo su cosa si paga davvero dopo il lancio.
Tre domande per decidere
Lasciate stare cosa fanno i concorrenti e guardate chi userà il prodotto, e dove.
- Dove si trova l'utente mentre lo usa? Scrivania, cantiere, strada, casa di un paziente. Se la risposta è "spesso senza rete", si va verso il nativo.
- Il telefono gli serve come schermo o come strumento? Se ci sono di mezzo Bluetooth, fotocamera usata di continuo o sensori, nativo. Se deve solo leggere e inserire dati, basta il web.
- Come arrivano gli utenti? Se li portate voi, dipendenti o clienti B2B, un link è sufficiente. Se devono trovarvi da soli, gli store contano.
C'è anche una via di mezzo, molto usata. Gestionale e pannelli come web app, app nativa solo per chi lavora sul campo. Nel tempo è spesso la combinazione che costa meno e che serve meglio tutti.
Domande frequenti
Una PWA può sostituire un'app nativa?
In molti casi sì. Si installa sulla schermata iniziale, funziona in parte offline e si aggiorna da sola. I limiti restano su hardware del dispositivo, notifiche su iOS e presenza sugli store, e se il vostro caso non tocca questi punti una PWA è una scelta solida.
Si può partire con una web app e fare l'app dopo?
Sì, ed è spesso l'ordine migliore. Backend e dati restano gli stessi, e l'app nativa diventa un altro modo di accedere allo stesso sistema. Conta progettare le API fin dall'inizio in modo che un secondo client sia possibile.
Serve pubblicare l'app sugli store anche per uso interno?
No. Per un'app usata solo dai dipendenti esistono canali di distribuzione privati, sia per iOS sia per Android, che evitano la pubblicazione. Resta il lavoro di gestire versioni e aggiornamenti sui dispositivi aziendali.
