Web app o app mobile: come scegliere la prima piattaforma

Scegliete tra web app e app mobile in base al compito che i vostri utenti devono svolgere. Una web app è spesso un buon punto di partenza per un lavoro raggiunto tramite un link ed eseguito su dispositivi diversi. Un’app mobile nativa diventa una candidata più forte quando il percorso principale dipende da funzioni specifiche del dispositivo o da un uso frequente sul telefono. Verificate i requisiti prima di impegnarvi con l’una o con l’altra.

«Le persone la useranno da mobile» non risolve la decisione. Un’applicazione web può funzionare in un browser mobile. Neanche «ci serve l’accesso offline» basta: il comportamento offline va progettato, e alcune applicazioni web possono supportarlo. La domanda utile è quale approccio può realizzare il vostro flusso reale con vincoli accettabili.

Qual è la differenza?

Un’applicazione web gira in un browser. Gli utenti di solito la raggiungono tramite un URL, e l’interfaccia può adattarsi a telefono, tablet o computer. Le sue capacità dipendono dai browser e dai dispositivi che decidete di supportare.

Un’applicazione mobile nativa è costruita per una piattaforma specifica, come iOS. Si installa sul dispositivo e usa le convenzioni di interfaccia e le API disponibili di quella piattaforma. Supportare un’altra piattaforma nativa comporta ulteriore lavoro di consegna e di verifica.

Una progressive web app, o PWA, usa tecnologie web con funzioni aggiuntive come l’installazione e un comportamento offline progettato. La documentazione MDN sulle PWA (in inglese) ne spiega le possibilità. Disponibilità e comportamento vanno comunque verificati sui dispositivi di destinazione; «PWA» non è una promessa che ogni funzione nativa funzioni ovunque.

Usate i requisiti qui sotto per scegliere il primo canale del prodotto.

Confrontate i vincoli prima della tecnologia

Su uno schermo stretto, scorrete la tabella in orizzontale per leggere tutte le colonne.

Requisito	Web app: cosa verificare	App nativa: cosa verificare
I clienti arrivano tramite un link	Possono completare il percorso nei browser supportati senza installare nulla?	Installare un’app è un passaggio accettabile prima che ricevano valore?
Il lavoro si svolge tra computer e telefono	Layout e interazioni sono adatti a entrambi?	Gli utenti da computer avranno bisogno anche di un’interfaccia web?
Una funzione del dispositivo è essenziale	L’API necessaria è disponibile e affidabile sui browser esatti che dovete supportare?	La piattaforma offre la funzione, e quali permessi e restrizioni si applicano?
La connessione non è affidabile	Quali azioni funzionano offline e come si sincronizzerà il lavoro salvato?	Valgono le stesse domande; l’installazione da sola non fa funzionare offline le azioni che dipendono dal server.
Servono più piattaforme	Verificate il comportamento sulle combinazioni di browser e dispositivi supportati.	Definite l’ambito di ogni piattaforma e i test, il lavoro di rilascio e la manutenzione che richiede.
I rilasci devono cambiare spesso	Pianificate deploy, compatibilità e ripristino per le modifiche al servizio in esecuzione.	Considerate anche distribuzione, revisione dove prevista e utenti con versioni dell’app più vecchie.

Non trattatela come un punteggio in cui vince chi ha più segni. Una sola funzione essenziale può determinare l’approccio. Molte preferenze non bastano a giustificare canali di prodotto in più.

Due esempi che portano a primi rilasci diversi

Un portale di approvazione per i clienti: i clienti ricevono un link, esaminano documenti, approvano il lavoro e a volte completano il compito dal telefono. Il personale gestisce i dati alla scrivania. Una web app responsive è una prima candidata ragionevole. Prima di costruire un’app, verificate se l’installazione migliorerebbe in qualche modo il percorso importante.

Uno strumento per la raccolta di dati sul campo: il personale registra informazioni durante la giornata in luoghi con scarsa connettività. Il prodotto richiede un comportamento specifico del dispositivo, dati locali e una sincronizzazione successiva. Valutate un’app nativa e una PWA rispetto a quei requisiti precisi. Un piccolo esperimento sulle capacità, fatto sui dispositivi reali, può risolvere la scelta più utilmente di un confronto generico tra funzionalità.

Sono flussi ipotetici, non affermazioni su risultati ottenuti per clienti di AL+. Il primo privilegia l’accesso semplice da più dispositivi; il secondo mette al centro il comportamento del dispositivo e della connessione. Nessuno dei due determina l’architettura di tutti i prodotti della sua categoria.

Il lavoro offline richiede un comportamento scritto, non un’etichetta

Descrivete cosa succede prima, durante e dopo la perdita della connessione:

Quali informazioni devono essere già presenti sul dispositivo?
Quali azioni può completare l’utente senza una risposta del server?
Come mostra l’interfaccia il lavoro salvato, in sospeso, fallito e sincronizzato?
Cosa succede se un’altra persona modifica lo stesso record?
Cosa succede se l’utente esce dall’account, perde il dispositivo o torna dopo una lunga interruzione?

Una schermata in cache e una transazione aziendale offline sono requisiti diversi. Per esempio, mostrare un appuntamento caricato in precedenza non dimostra che una nuova prenotazione possa essere confermata senza raggiungere il sistema che gestisce la disponibilità.

Sia le implementazioni native sia quelle web richiedono decisioni su dati, conflitti e ripristino. Consultate la documentazione della piattaforma interessata e verificate il comportamento critico, invece di darlo per scontato solo per il nome di una tecnologia.

Il backend è una parte separata della decisione

Un’app installata può comunque dipendere da account, record condivisi, pagamenti, notifiche e strumenti di amministrazione che girano altrove. Anche un’applicazione web può avere bisogno degli stessi servizi.

Per entrambi gli approcci, individuate quale backend esiste già, chi lo controlla, quali interfacce sono disponibili e cosa va costruito. Portare l’interfaccia sul telefono non risolve un’integrazione inaffidabile né una proprietà dei dati poco chiara.

Includete il flusso amministrativo. Se qualcuno deve correggere un record o assistere un cliente, decidete come lo farà. L’esperienza mobile del cliente e un’interfaccia web di amministrazione possono essere canali diversi dello stesso prodotto, ma entrambe rientrano nell’ambito di lavoro.

Confrontate stime di rilascio complete

Chiedete a ogni proposta di separare il lavoro di prodotto condiviso dal lavoro specifico della piattaforma:

Comportamento condiviso: regole aziendali, dati, accessi, integrazioni e gestione del server.
Lavoro sull’interfaccia: percorsi utente e layout per ogni canale supportato.
Verifica: i dispositivi, i browser, i permessi e i casi di errore che verranno controllati.
Rilascio: deploy o invio allo store, accesso agli account, informazioni per l’assistenza e ripristino.
Manutenzione: modifiche di compatibilità, correzioni, rilasci e costi continuativi dei fornitori.

Non esiste una percentuale universale e affidabile per cui un approccio costi meno dell’altro. Un backend esistente, una funzione del dispositivo indispensabile o una seconda interfaccia possono cambiare il confronto. Confrontate lo stesso rilascio utile, non due conteggi di schermate o tariffe orarie.

La nostra guida al costo di un’app mobile (in inglese) spiega il lavoro contenuto in una stima per un’app nativa iOS. È una checklist dell’ambito di lavoro, non la promessa di un prezzo standard per il progetto.

Un brief per decidere la piattaforma

Scrivete queste sei righe prima di chiedere a uno sviluppatore di scegliere uno stack:

Percorso principale: cosa deve completare un utente, dall’inizio al risultato.
Utenti e dispositivi: chi la usa, dove, quanto spesso e su quali dispositivi.
Funzioni essenziali: il comportamento esatto del dispositivo o le integrazioni da cui dipende il percorso.
Comportamento della connessione: cosa deve succedere quando la rete non è disponibile.
Sistemi esistenti: il backend, i dati, gli account e le interfacce già disponibili.
Confine del primo rilascio: le piattaforme supportate, le esclusioni, i vincoli di budget e il motivo di un’eventuale scadenza fissa.

Se una funzione potrebbe cambiare la decisione, chiedete una verifica tecnica mirata prima di una realizzazione completa. Se l’incertezza riguarda come le persone usano l’interfaccia, un prototipo può essere il primo passo giusto.

Parliamo del flusso prima di scegliere la piattaforma

AL+ sviluppa applicazioni web su misura e app native per iPhone e iPad, con la responsabilità dei servizi collegati e della manutenzione dopo il lancio. Possiamo parlare della prima piattaforma partendo dal compito, dai dispositivi di destinazione e dal sistema esistente.

Scrivete ad AL+ del vostro progetto web o iOS. Inviate il brief di sei righe, così la conversazione parte dai requisiti che determinano il lavoro.