App nativa o web app: come scegliere

Si sceglie fra app nativa e web app in base a tre domande, in quest'ordine: chi la userà e in quale contesto, se servono funzioni del telefono che il browser non raggiunge bene, quanto tempo e budget puoi dedicare al primo rilascio. Se le persone lavorano in movimento e servono fotocamera, posizione, notifiche affidabili o uso prolungato senza rete, la strada nativa ha un vantaggio concreto. In tutti gli altri casi, e soprattutto per gli strumenti interni, una web app arriva in produzione prima, costa meno da mantenere e si aggiorna senza passare dagli store.

Se stai valutando di far sviluppare un'applicazione per la tua azienda e ti sei fermato su questa scelta perché ogni fornitore te la racconta in modo diverso, qui trovi i criteri in ordine di peso, i casi in cui una strada costa davvero il doppio dell'altra e un modo per decidere senza rimandare il progetto di sei mesi.

Cosa serve sapere prima di decidere

• Chi userà l'applicazione: dipendenti, clienti finali o entrambi. Un'app per venti persone della tua azienda e una destinata a diecimila clienti non hanno lo stesso problema, e la seconda ha vincoli di distribuzione che la prima non ha.
• Dove avviene il lavoro: alla scrivania, in magazzino, in cantiere, in auto fra un cliente e l'altro. È l'informazione che sposta la decisione più di ogni altra.
• Quali funzioni del dispositivo servono davvero: fotocamera per leggere codici, posizione, notifiche a schermo spento, lettura di tag, stampa su dispositivi collegati. Serve un elenco corto e onesto, distinguendo quello che serve da quello che sarebbe comodo.
• Quanti dispositivi diversi vanno coperti e con quali versioni di sistema operativo. In molte PMI convivono telefoni aziendali recenti e dispositivi personali di ogni età.
• Il tempo entro cui deve essere in uso. Una data reale cambia la scelta: alcune strade sono più corte per arrivare al primo rilascio, e i tempi tipici sono descritti nella guida sui tempi di sviluppo di un software.

Le tre strade a confronto

La tabella non decide da sola: serve a capire dove si sposta il costo. Nella pratica il fattore che pesa di più non è scrivere il codice, ma provare e pubblicare su più piattaforme a ogni modifica.

Come scegliere, passo per passo

Parti dal contesto d'uso, non dalla tecnologia. Descrivi in tre righe la scena tipica: dove sono le persone, cosa hanno in mano, quanto tempo hanno per completare l'operazione. Un magazziniere che registra colli con i guanti e una responsabile che approva richieste dal treno hanno bisogni opposti, e la scena chiarisce la scelta prima di qualunque discussione tecnica.

Metti alla prova l'elenco delle funzioni del telefono. Per ciascuna chiediti cosa succede se non c'è: il lavoro diventa più lento o diventa impossibile? Le funzioni della seconda categoria, se ci sono, spingono verso il nativo. Spesso l'elenco si riduce a una sola voce, e a volte quella voce ha un'alternativa accettabile.

Verifica il requisito della connessione. Chiedi per quanto tempo consecutivo le persone lavoreranno senza rete e con quanti dati. Minuti dentro un edificio con campo debole sono un problema risolvibile lato web; ore in una zona senza copertura sono un requisito che cambia la strada.

Guarda come arriverà agli utenti. Per uno strumento interno la distribuzione è un dettaglio: si manda un link. Per un'app rivolta ai clienti la presenza negli store può essere parte dell'aspettativa, e in quel caso va messa nel conto insieme ai tempi di revisione e agli aggiornamenti obbligatori.

Confronta il costo totale su tre anni, non il preventivo iniziale. Alla cifra di partenza vanno aggiunti manutenzione, adeguamenti alle nuove versioni dei sistemi operativi e il tempo di pubblicazione a ogni rilascio. Gli ordini di grandezza della spesa iniziale sono nella guida su quanto costa sviluppare un'app, mentre la parte ricorrente è descritta nella guida sulla manutenzione del software aziendale.

Scegli il perimetro del primo rilascio e rimanda il resto. Qualunque strada, la decisione più utile è ridurre: una funzione che risolve un problema vero, usata da un gruppo piccolo, in produzione entro poche settimane. Il resto si aggiunge quando c'è un uso reale da guardare.

Quando conviene l'app nativa

Il nativo si giustifica quando l'uso è intenso e mobile: rilevazioni sul campo, lettura continua di codici a barre, tracciamento della posizione durante i giri di consegna, notifiche su cui si basa un'operazione. Si giustifica anche quando l'applicazione è un prodotto rivolto al mercato, perché essere trovabili negli store fa parte del canale di acquisizione.

Un terzo caso, meno evidente, è l'integrazione con dispositivi fisici: stampanti di etichette, terminali, lettori collegati. Qui il livello di controllo che serve è quello che solo un'applicazione installata sul sistema operativo raggiunge in modo stabile.

Quando conviene la web app

La web app è la scelta naturale per gli strumenti interni: portali per collaboratori, gestione di ordini o commesse, approvazioni, consultazione di dati. Il vantaggio non è solo il costo iniziale, è la velocità di correzione: quando qualcuno segnala un problema, la modifica arriva a tutti nel giro di ore, senza attese di revisione e senza chiedere a nessuno di aggiornare.

Conviene anche in tutte le situazioni in cui i dispositivi non sono controllati dall'azienda, per esempio se lo strumento va usato da collaboratori esterni o clienti occasionali. Chiedere l'installazione di un'app a chi la userà tre volte l'anno è il modo più rapido per non farla usare. Sul rapporto fra sito, portale e strumento gestionale, il confronto è nella guida su sito vetrina o gestionale su misura.

Errori comuni

Scegliere il nativo per una funzione che si può ottenere altrimenti. Capita spesso con la fotocamera: leggere un codice dal browser oggi è possibile, e questo da solo sposta molti progetti sul web. Vale la pena verificarlo con una prova concreta prima di raddoppiare il perimetro.

Sottovalutare il lavoro di pubblicazione. Account sviluppatore, materiali richiesti, revisioni, aggiornamenti obbligatori quando cambiano i requisiti delle piattaforme: è lavoro ricorrente che non compare nei preventivi ma occupa tempo ogni anno.

Costruire per tutti i dispositivi dal primo giorno. Partire da una sola piattaforma, quella che usano davvero le persone coinvolte, riduce di molto il primo rilascio. L'estensione si valuta dopo, sui dati d'uso, e l'impianto va progettato perché regga quella crescita: il criterio è quello descritto nella guida sulla progettazione di software scalabile.

Quanto tempo serve per decidere e qual è il passo successivo

La decisione, con le informazioni della prima sezione in mano, richiede un incontro di un'ora e mezza con chi userà l'applicazione, non con i soli responsabili. Se il dubbio resta, di solito significa che il perimetro è troppo largo: dividere il progetto in due parti, una immediata e una successiva, quasi sempre scioglie anche la scelta tecnica.

Il passo successivo naturale è scrivere il documento di richiesta con il perimetro del primo rilascio, e da lì partire con la selezione del fornitore. La sequenza completa, dalla prima idea al rilascio in produzione, è descritta nella guida sulla roadmap per sviluppare un'app in una PMI.