Quando un'attività decide di «fare un'app», la prima domanda non dovrebbe essere quale funzione inserire, ma che tipo di app costruire. Le strade principali sono tre: app native, app multipiattaforma e Progressive Web App. Ognuna ha costi, limiti e punti di forza diversi, e la scelta sbagliata può significare spendere il doppio per un risultato che nessuno scarica.
App native
Un'app nativa è scritta con gli strumenti specifici di ciascuna piattaforma: Swift per iOS, Kotlin per Android. Si installa dallo store e ha accesso completo alle funzioni del sistema.
Punti di forza:
- prestazioni massime e animazioni fluide;
- accesso immediato a tutte le API: fotocamera avanzata, sensori, Bluetooth, NFC, widget, integrazione con orologi;
- aspetto e comportamento coerenti con il sistema, che gli utenti riconoscono.
Limiti:
- due basi di codice separate, quindi tempi e costi di sviluppo e manutenzione più alti;
- pubblicazione soggetta alla revisione degli store e alle loro regole;
- ogni aggiornamento deve essere scaricato dagli utenti.
App multipiattaforma
Framework come Flutter o React Native permettono di scrivere gran parte del codice una volta sola e generare app per iOS e Android. Il risultato si installa dallo store come un'app nativa.
Punti di forza:
- un solo team e una base di codice in gran parte condivisa;
- prestazioni buone per la maggior parte delle app aziendali e di servizio;
- accesso alle funzioni del telefono tramite plugin.
Limiti:
- per funzioni molto specifiche o appena introdotte serve comunque codice nativo;
- dipendenza dall'evoluzione del framework e dei suoi plugin;
- dimensioni dell'app spesso maggiori.
Esistono anche approcci «ibridi» più vecchi, che incapsulano una pagina web in un contenitore nativo. Funzionano per app semplici, ma l'esperienza d'uso è spesso meno fluida.
Progressive Web App (PWA)
Una PWA è un sito web progettato per comportarsi come un'app. Si apre dal browser e può essere aggiunta alla schermata Home, da cui si avvia a schermo intero, senza barra degli indirizzi. Due componenti la rendono possibile:
- il manifest, un file che descrive nome, icone, colori e modalità di visualizzazione;
- il service worker, uno script che lavora in background e permette il funzionamento offline, la memorizzazione dei contenuti e le notifiche push.
Punti di forza:
- un'unica base di codice per tutti i dispositivi, computer compresi;
- nessuna revisione degli store: gli aggiornamenti sono immediati per tutti;
- raggiungibile da un link e indicizzabile dai motori di ricerca.
Limiti:
- accesso più ristretto alle funzioni del telefono, con differenze tra browser e sistemi;
- su iPhone alcune funzioni, come le notifiche push, sono disponibili solo dopo l'aggiunta alla schermata Home;
- minore visibilità per chi cerca app direttamente negli store.
Confronto rapido
| Aspetto | Nativa | Multipiattaforma | PWA |
|---|---|---|---|
| costo di sviluppo | alto | medio | basso |
| prestazioni | massime | buone | buone per contenuti e moduli |
| funzioni del telefono | tutte | quasi tutte | limitate |
| distribuzione | store | store | link e store in alcuni casi |
| aggiornamenti | tramite store | tramite store | immediati |
| funzionamento offline | sì | sì | sì, se progettato |
Come scegliere
Nel mio lavoro parto da alcune domande concrete.
- Quali funzioni del telefono servono davvero? Se l'app deve comunicare con un dispositivo Bluetooth, usare l'NFC o lavorare a lungo in background, servono una nativa o una multipiattaforma. Se si tratta di consultare contenuti, prenotare o compilare moduli, una PWA è spesso sufficiente.
- Quanto spesso la useranno gli utenti? Un'app usata ogni giorno merita l'installazione dallo store. Un servizio usato due volte l'anno difficilmente verrà scaricato: un sito veloce o una PWA raggiungono più persone.
- Chi la manterrà? Un'app non è un progetto che si chiude con il rilascio. Sistemi operativi, store e librerie cambiano ogni anno, e serve qualcuno che aggiorni il codice.
- Esiste già un buon sito? Se sì, trasformarlo in PWA può essere il primo passo a basso costo, misurando l'uso reale prima di investire in un'app da store.
Errori frequenti
- Costruire un'app nativa che replica un sito, senza alcuna funzione in più: gli utenti non la installano.
- Sottovalutare i costi di manutenzione dopo il lancio.
- Ignorare l'accessibilità: dimensioni dei testi, contrasto e compatibilità con gli screen reader valgono per tutti e tre gli approcci.
- Dimenticare le prestazioni su telefoni economici e connessioni lente, dove si trovano molti utenti reali.
In sintesi
- Le app native offrono il massimo di prestazioni e funzioni, a costi più alti.
- I framework multipiattaforma condividono il codice tra iOS e Android con buoni compromessi.
- Le PWA sono siti installabili, economici da mantenere e aggiornabili all'istante.
- La scelta dipende dalle funzioni del telefono necessarie e dalla frequenza d'uso prevista.
- In ogni caso vanno messi in conto manutenzione, accessibilità e prestazioni su dispositivi modesti.
