Le opzioni
Native: Swift su iOS, Kotlin su Android
Ogni piattaforma ha la sua app, scritta con il linguaggio e gli strumenti di interfaccia della piattaforma: Swift e SwiftUI per iOS, Kotlin e Jetpack Compose per Android.
- Punti di forza: accesso completo e immediato a tutte le funzioni del dispositivo e alle novità del sistema operativo; aspetto e comportamento più naturali su ogni piattaforma; la base migliore per prestazioni impegnative.
- Compromessi: due basi di codice, due insiemi di competenze, funzionalità sviluppate due volte.
Cross-platform: React Native e Flutter
Una sola base di codice produce le app per entrambe le piattaforme. React Native, mantenuto da Meta, usa JavaScript o TypeScript e visualizza componenti di interfaccia nativi. Flutter, mantenuto da Google, usa il linguaggio Dart e disegna da sé la propria interfaccia.
- Punti di forza: un solo team e un solo codice per la maggior parte dell'app; nuove funzionalità su entrambe le piattaforme in una volta; con React Native si riutilizzano le competenze web.
- Compromessi: uno strato in più tra l'app e il sistema operativo; alcune funzioni del dispositivo possono richiedere codice nativo scritto a parte; dipendenza dall'evoluzione del framework e dal suo ecosistema di plugin.
Logica condivisa: Kotlin Multiplatform
Kotlin Multiplatform condivide tra le piattaforme la logica di business (modelli dati, validazioni, comunicazione di rete, archiviazione offline) mentre ogni piattaforma mantiene un'interfaccia nativa. È adatto ai team che vogliono interfacce native senza duplicare le regole sottostanti.
Progressive web app
Una progressive web app è un sito che si può installare sulla schermata iniziale, funzionare in parte offline e, sulle versioni recenti di iOS e Android, inviare notifiche. Non c'è nulla da pubblicare negli store.
- Punti di forza: un solo codice per web e mobile; aggiornamenti immediati; nessuna revisione degli store.
- Compromessi: accesso più limitato alle funzioni del dispositivo, con differenze tra browser e piattaforme; comportamento meno naturale di un'app nativa; meno visibilità di una scheda nello store, per le app rivolte ai consumatori.
Che cosa decide davvero
Che cosa deve fare l'app sul dispositivo
Elencate le funzioni del dispositivo di cui l'app ha bisogno: fotocamera e lettura di codici a barre, Bluetooth con hardware specifico, posizione in background, NFC, biometria, funzionamento offline per ore o giorni. Più un'app dipende da funzioni profonde o insolite del dispositivo, più conviene il nativo, oppure un framework cross-platform con moduli nativi dove servono.
Offline e sincronizzazione
Per le app sul campo e di magazzino il funzionamento offline è di solito il requisito più difficile: i dati raccolti senza copertura vanno salvati in locale, sincronizzati in seguito e riconciliati quando due persone hanno modificato lo stesso record. Questa logica conta molto più del framework dell'interfaccia e va progettata presto, insieme al back-end con cui si sincronizza.
Chi la usa e su quali dispositivi
Un'app interna usata da cinquanta tecnici su dispositivi Android aziendali ha vincoli diversi da un'app per i clienti che deve funzionare su qualunque telefono. Per le app interne, la gestione dei dispositivi (MDM) permette di distribuire l'app senza passare dagli store pubblici e di applicare le politiche di sicurezza.
Il vostro team e il lungo periodo
Il framework migliore è spesso quello con cui il vostro team, o il team che manterrà l'app, sa lavorare con sicurezza per anni. Un'app mobile non è finita al lancio: Apple e Google rilasciano ogni anno una nuova versione principale del sistema operativo e gli store alzano periodicamente i requisiti minimi per gli aggiornamenti. Questa manutenzione va messa a budget fin dall'inizio.
Che cosa conta più del framework
La maggior parte del lavoro in un'app aziendale non sta nelle schermate:
- Il back-end e le integrazioni. Un'app per il campo è utile quanto il suo collegamento con l'ERP, il sistema di gestione degli interventi o il magazzino: ne parliamo nelle note sulla system integration. Le API di cui l'app ha bisogno vanno progettate esplicitamente, invece di esporre direttamente ai dispositivi i sistemi interni.
- La sicurezza. Autenticazione con la directory aziendale, conservazione sicura dei token sul dispositivo, cifratura dei dati locali e possibilità di revocare l'accesso a un dispositivo smarrito.
- Il processo di rilascio. Build, test e distribuzione ai tester automatizzati rendono praticabili aggiornamenti frequenti, come per qualsiasi altro software: i principi del nostro articolo sulla CI/CD valgono per intero. La revisione degli store allunga i tempi di ogni rilascio pubblico e va pianificata.
- L'osservabilità. Segnalazione dei crash e statistiche d'uso, con attenzione a quali dati si raccolgono e con quale consenso.
Un modo semplice per decidere
- Nativo quando l'app è centrale per il vostro prodotto, usa molto le funzioni del dispositivo o deve risultare impeccabile su ogni piattaforma.
- Cross-platform quando servono entrambe le piattaforme con un solo team e le esigenze sul dispositivo sono comuni.
- Kotlin Multiplatform quando volete interfacce native ma molta logica condivisa.
- Progressive web app quando l'uso è occasionale, le esigenze sul dispositivo sono leggere ed evitare gli store è un vantaggio.
E prima di tutto questo, verificate se vi serve davvero un'app su misura o se basta il client mobile di un prodotto esistente. Ne parliamo nell'articolo su software su misura o pacchetto.
Da dove partire
Mettete per iscritto utenti, dispositivi, funzioni del dispositivo, esigenze offline e sistemi a cui l'app deve collegarsi. Quella pagina di solito rende ovvia la scelta della tecnologia. Il nostro servizio di software engineering progetta e sviluppa app mobili insieme alle API e alle integrazioni che stanno dietro, così che l'app e i sistemi da cui dipende vengano consegnati come un tutt'uno.