App e software: sviluppo rapido, experience scadente

Oltre il 60% della popolazione globale è collegata ad Internet ed una percentuale assimilabile utilizza almeno uno smartphone, ma nei Paesi sviluppati la media di device digitali cui si accede alla Rete nel corso della giornata è superiore e gran parte della popolazione, anche in Italia, utilizza oltre a smartphone e pc, anche un device dotato di schermo con una diagonale compresa tra i 7 e i 12 pollici.
Il ‘consumo’ di applicazioni, fino anche solo a una ventina di anni fa, avveniva esclusivamente tramite lo schermo di un pc (e di fatto su 2/3 sistemi operativi); oggi la stessa applicazione deve essere declinata e fruibile su sistemi operativi diversi e diagonali di schermo anche molto eterogenee tra loro. Se ne deve prevedere quindi l’utilizzo almeno per Windows e MacOs, iOS e Android (solo per limitarci alle piattaforme più diffuse), con upgrade e update rilasciati ad una frequenza decisamente superiore rispetto al passato. Significa un notevole incremento di complessità.

Lo sviluppo negli ecosistemi complessi

Non ha ‘semplificato’ il percorso degli sviluppatori nemmeno l’utilizzo delle Web app che di fatto si “aggiunge” alle release da installare, ma senza rappresentare – se non in pochi casi – un vero e proprio cambio di paradigma, che a nostro avviso sarebbe invece virtuoso, se fosse in grado di indirizzare pienamente le esigenze di responsive design.

Questa ‘varietà’ dell’ecosistema di piattaforme, modalità di consumo, dispositivi e sistemi operativi di fatto oggi si riflette su una qualità complessiva delle app che è serenamente possibile definire scadente e denuncia tutti i limiti della “fretta” nello sviluppo, pur riconoscendo che è proprio grazie all’approccio DevOps che oggi è possibile beneficiare di una ricchezza applicativa come mai abbiamo avuto.

Anche le applicazioni più conosciute, come quelle di Microsoft 365, a seconda di OS e diagonali mostrano limiti evidenti, o differenze nelle possibilità d’uso. Basterebbe citare la possibilità di utilizzare le Categorie per classificare e gestire le email (assente sulle app mobile con qualsiasi sistema operativo) o, in Word, la mancanza della funzione di trascrizione da file audio direttamente nel documento di testo (disponibile in Word per Windows ma non in Word per Mac), e ancora si potrebbero citare le diverse gestioni dei protocolli anche dell’app Gmail a seconda dell’OS mobile su cui si usa (per esempio su iOS non sempre è consentita l’autenticazione corretta agli account Microsoft 365) ma anche per le app di messaggistica e praticamente tutte le applicazioni business. Ecco, in tantissimi casi gli sviluppatori sono soliti ‘rimodellare’ disposizione dei menu, limitare o declinare diversamente funzionalità, includere o escludere feature a seconda delle ‘esigenze’ e – ci verrebbe da dire – anche della fretta…O dei limiti imposti dalla stessa piattaforma che ospiterà poi il rilascio dell’applicativo.

E’ difficile, oggi, trovare un’applicazione che sia perfettamente ‘allineata’ e declinata in modo coerente per tutto l’ecosistema di device per cui ne è previsto l’utilizzo, quindi che sia davvero cross-platform. E questo si riflette nell’esperienza negativa dell’utente finale. Tanto più, quanto più l’utente segue di fatto il consiglio di “sfruttare a fondo tutte le potenzialità della soluzione”, mantra tanto caro ai vendor, quanto non realizzabile (e frustrante per chi sceglie le app anche in base alla loro disponibilità cross-platform e on-line), proprio per i limiti funzionali di applicazioni sviluppate sempre più velocemente e… Male. 

Le problematiche dello sviluppo

Tentando di modellizzare quali sono le principali problematiche sul tema di sicuro sussistono le differenze di piattaforma che si legano al fatto che i sistemi operativi hanno architetture diverse, espongono linee guida e funzionalità di sistema diversi per cui gli sviluppatori si trovano a dover adattare le applicazioni in questo senso.

A queste differenze si aggiungono quelle relative ai linguaggi di programmazione. Le applicazioni per iOS sono spesso scritte in Swift o Objective-C, mentre le applicazioni Android sono scritte in Java o Kotlin. Questi linguaggi hanno sintassi e strutture diverse, il che rende necessaria la ri-scrittura di codice specifico per ciascuna piattaforma.
Oltre a questi intervengono proprio gli aspetti di progettazione della user interface imposti da Apple Google e Microsoft che definiscono gli standard di design UX che impattano anche a livello di “comportamento” finale dell’applicazione. Ogni sistema operativo inoltre espone poi le proprie funzionalità tramite Api (Application Programming Interface) di accesso che variano, per esempio per il collegamento delle funzionalità relative con quelle degli assistenti digitali, o anche semplicemente per l’autenticazione di accesso all’applicazione, che è gestita hardware/software da OS e sensori biometrici, ed infine anche per le notifiche.

Direttamente collegato proprio a quest’ultimo aspetto vi è quello relativo all’hardware di approdo, per cui che si parli di tablet, smartphone, computer, l’applicazione sarà utilizzata su hardware diversi – a volte anche ‘sensibilmente diversi’ a livello di sensoristica, fotocamere e schermi che possono influenzare le caratteristiche e le prestazioni delle applicazioni – e gli sviluppatori dovrebbero tener conto anche di queste differenze hardware. In ultimo, intervengono le aspettative degli utenti che variano con il variare delle piattaforme, mentre è necessario tenere sempre più in conto che nessun OS è oggi best of breed ed in grado di prevalere sugli altri anche quando si cambia device. Per questo gli utenti di iOS potrebbero avere diverse aspettative sull’aspetto e il comportamento delle applicazioni rispetto agli utenti di Android, ma un utente Android è anche spesso un utente Windows o MacOS. 

Vantaggi e criticità nello sviluppo cross-platform

Lo sviluppo multipiattaforma, ovvero la creazione di applicazioni che possono essere eseguite su più sistemi operativi, offre diversi vantaggi in termini di efficienza e costi, ma comporta anche alcune sfide significative, se l’approccio di sviluppo non è ottimale. Per esempio, le app multipiattaforma tendono a essere meno performanti rispetto alle applicazioni per cui è stato curato lo sviluppo nativo, poiché in tanti casi si ricorre all’utilizzo di livelli aggiuntivi di astrazione per adattarle a diverse platform e questo ritarda poi la reattività dell’applicazione.
In questi casi poi eventuali aggiornamenti del sistema operativo o delle librerie utilizzate dalle applicazioni multipiattaforma possono causare problemi di compatibilità e questo si riflette a valle in ulteriore lavoro per gli sviluppatori che devono essere pronti a rilasciare aggiornamenti e patch.

Lo sviluppo multipiattaforma spesso poi richiede l’uso di framework e strumenti che aggiungono complessità al codice dell’applicazione. Questo può rendere il codice più difficile da gestire e richiedere competenze specializzate, ma vi sono anche casi per cui specifiche funzionalità avanzate potrebbero non essere disponibili o essere limitate su altre piattaforme e gli sviluppatori devono valutare se sacrificare alcune funzionalità o creare implementazioni personalizzate per ciascuna piattaforma che, proprio perché non ‘native’ potrebbero appesantire l’app nel suo insieme. Ecco allora che lo sviluppo multipiattaforma – che a nostro avviso è sempre strategico – richiede però una pianificazione e una gestione attente delle sfide tecniche e delle differenze tra OS e bisogna essere pronti a investire risorse ed energie nella risoluzione di problemi specifici concedendosi il tempo per verificarli e risolverli. Diversamente impatteranno sull’esperienza utente in modo più pesante rispetto a quanto ci si potrebbe aspettare.

Ripensare l’approccio DevOps

In questo ambito l’approccio DevOps continua ad offrire vantaggi specifici, per esempio in fase di automazione dell’implementazione nei diversi OS, a patto di continuare ad utilizzarlo anche in fase di testing. Se è vero che le distribuzioni dell’applicazione grazie alla metodologia DevOps avvengono in modo rapido su tutti i sistemi operativi, non sempre questo garantisce che le nuove funzionalità o correzioni di bug vengano consegnate simultaneamente su tutte le piattaforme. Per questo è importante puntare sulla collaborazione tra team di sviluppo, operations e sicurezza e semplificare il più possibile i sistemi di feedback degli utenti per apportare modifiche e miglioramenti in modo tempestivo su tutte le piattaforme. L’esperienza sul campo, al momento, lascia piuttosto pensare che l’approccio DevOps sia stato utilizzato per “monetizzare” lo sviluppo software, dimenticandosi invece, proprio dell’utente finale che è sempre più propenso all’utilizzo delle app su dispositivi e OS diversi, quando addirittura non vuole semplicemente “utilizzare tutti i servizi e le applicazioni con il browser con la stessa esperienza”, salvo poi rimanere deluso di non riuscire a spremere appieno il valore delle applicazioni.

© RIPRODUZIONE RISERVATA