SURVIVAL APPSPWA, Capacitor o nativo? Una mappa concettuale prima di scegliere (senza codice)
Tre strade portano al palmo della mano di chi userà il tuo strumento. Una passa dal cielo aperto, una da un valico presidiato, una scala la montagna. I mercanti ti diranno che la loro è l'unica percorribile. I mercanti mentono per mestiere: la strada giusta dipende dal carico che porti.
Le tre strade in una frase ciascuna
Prima i nomi, senza sigle date per scontate. Una PWA (Progressive Web App)[1] è un sito web che si comporta da app: si "installa" dal browser, può funzionare offline, non passa da nessuno store. Capacitor[2] prende quella stessa app web e la impacchetta dentro un'app vera, installabile dallo store, con un ponte verso le funzioni native del telefono. Nativo significa scrivere l'app nel linguaggio della piattaforma — su Android, oggi, Kotlin — parlando direttamente con il sistema operativo, senza strati intermedi.
Cosa comporta davvero ogni scelta
| Criterio | PWA | Capacitor | Nativo (Kotlin) |
|---|---|---|---|
| Distribuzione | Un URL. Niente store, niente attese, aggiornamenti istantanei | Store (Play/App Store) e, volendo, anche il web | Store, oppure APK distribuito direttamente |
| Accesso all'hardware | Limitato a ciò che espone il browser (e su iOS il recinto è più stretto) | Ampio, tramite plugin; i casi esotici richiedono codice nativo | Totale: tutto ciò che il sistema offre |
| Competenze richieste | Solo web: HTML/CSS/JS | Web + rudimenti dell'ecosistema Android/iOS per build e store | Kotlin, Android Studio, ciclo di vita, un ecosistema intero |
| Prestazioni percepite | Ottime per contenuti e form; il limite è la UI complessa | Come una web app ben fatta: sufficiente per la maggioranza dei casi | Il riferimento: animazioni, liste infinite, grafica spinta |
| Costo di manutenzione (in uno) | Il più basso: una sola base di codice, nessun obbligo di store | Medio: una base di codice, ma due catene di build e le regole degli store | Il più alto: ecosistema da seguire, requisiti API annuali |
Le domande da farsi, in ordine
- 1. SERVE L'HARDWARE? — Bluetooth, sensori, servizi in background affidabili? Se sì, la PWA esce dalla mappa quasi subito: restano Capacitor e nativo
- 2. SERVE LO STORE? — lo store è visibilità e fiducia, ma anche recinto (vedi la trasmissione precedente di questa zona). Se il pubblico può arrivare da un link, la PWA torna prepotentemente in gioco
- 3. CHI MANTIENE, E PER QUANTO? — per chi lavora da solo è la domanda decisiva: ogni strato tecnologico in più è un debito di manutenzione che firmi oggi e paghi ogni anno
- 4. QUANTO DEVE ESSERE "APP"? — se il valore sta nei dati e nelle funzioni, l'utente perdona una UI web. Se il valore è l'esperienza d'uso, il nativo si ripaga
La mia bussola personale, dichiarata: partire dal gradino più basso che soddisfa i requisiti. Prototipo come web app; se serve lo store o un'API nativa, Capacitor; nativo quando il progetto lo giustifica per prestazioni o profondità di integrazione — o quando l'obiettivo è imparare il territorio, che è un requisito legittimo quanto gli altri.
> solo contenuti + offline leggero → PWA
> store + hardware standard → CAPACITOR
> prestazioni / integrazione profonda → NATIVO
> in dubbio → IL GRADINO PIÙ BASSO CHE BASTA
Nessuna delle tre strade è quella giusta in assoluto. Ma partire senza mappa è il solo modo garantito di sbagliarle tutte.
Note
- PWA — Progressive Web App: applicazione web che usa service worker (per l'offline), un manifest (per l'installazione) e HTTPS. Il supporto varia per piattaforma: è il punto tecnico da verificare per primo, caso per caso. ↑ torna al testo
- Capacitor — runtime open source di Ionic: incapsula un'app web in una WebView nativa ed espone API di sistema (fotocamera, filesystem, Bluetooth...) tramite plugin. Erede spirituale di Cordova/PhoneGap. ↑ torna al testo