Il nostro team mobile utilizza SwiftUI dal 2022 per sviluppare l’applicazione Infomaniak Mail su iOS. Oggi è uno dei più grandi progetti open source scritti al 100% in SwiftUI. L’attrattiva del nuovo framework di Apple è indubbia, ma rimane una sfida per gli sviluppatori. Sono pochissime le aziende che hanno il coraggio di utilizzarlo al 100%. Da un lato, c’è la giovinezza del framework con una documentazione poco chiara o incompleta. Dall’altro, occorre cambiare radicalmente le logiche apprese. Nel presente articolo, gli sviluppatori di Infomaniak condividono il loro feedback sull’adozione di SwiftUI per Infomaniak Mail.

Perché scegliere SwiftUI per lanciare la nostra app Mail dedicata?

Volevamo favorire i rapidi sviluppi dell’applicazione e poter accedere alle ultime novità. SwiftUI è la base delle prossime innovazioni su tutte le piattaforme Apple: non solo su iOS, ma anche su macOS e VisionOS.

Questo nuovo framework comporta vantaggi di varia natura per gli sviluppatori:

  • La sintassi dichiarativa consente di descrivere le interfacce utente in modo più conciso e leggibile.
  • Il suo sistema di anteprima consente di visualizzare immediatamente le modifiche senza doverle compilare.
  • La suddivisione delle viste in componenti riutilizzabili ottimizza la manutenibilità dell’applicazione.
  • L’integrazione con Swift consente di utilizzare le ultime aggiunte del linguaggio, come l’API FormatStyle, direttamente nelle caselle di testo.
  • A differenza di UIKit, il supporto per l’internazionalizzazione e l’accessibilità facilita l’utilizzo dell’app da parte di tutti senza dover scrivere codici espliciti.

Se facciamo un bilancio, il modo storico di fare con UIKit convive ancora molto bene con SwiftUI, ma per quanto tempo? Come evidenziato da numerosi esempi, Apple promuove il suo nuovo framework con determinazione. Per essere implementate, le nuove funzionalità dei sistemi operativi richiedono SwiftUI, come nel caso dei widget o delle Live Activities. Il nuovo framework diventa quindi un must per supportare le ultime funzionalità. Volevamo anche evitare che l’applicazione si basasse su una tecnologia destinata a essere superata in tempi troppo rapidi.

Le sfide di SwiftUI rispetto a UIKit

Nonostante la formazione su SwiftUI, il nostro team ha dovuto affrontare errori, tentativi e ritardi, soprattutto per i seguenti motivi:

1. Continuare ad assicurare il supporto dei vecchi dispositivi

Per limitare l’obsolescenza programmata e sostituzioni troppo frequenti dei dispositivi, è necessario poterli conservare il più a lungo possibile. Rimaniamo volutamente con SwiftUI 3 rilasciato con iOS 15 anziché con SwiftUI 5 rilasciato con iOS 17 al fine di supportare i dispositivi di tutti i nostri clienti basati su iOS 15 (circa il 5% dei nostri utenti).

Questa volontà rappresenta tuttavia una sfida per il team mobile di Infomaniak: il framework, rilasciato nel 2019 con iOS 13 è ancora giovane e si sta evolvendo molto rapidamente. Anche se Apple colma rapidamente le carenze di SwiftUI nel corso degli anni, supportare iOS 15 limita l’uso delle nuove API.

2. La gestione del cambiamento

La svolta verso SwiftUI ha preso avvio nel 2022, mentre era già iniziato lo sviluppo di un POC con UIKit. Non avevamo nessuna esperienza di questo nuovo framework con le nostre applicazioni preesistenti. Alcuni dei nostri sviluppatori, che stavano già sperimentando un’attività di vigilanza tecnologica attiva, hanno preso l’iniziativa sulle buone pratiche fungendo da esempio anche per gli altri.

Anche se l’ambiente era familiare, abbiamo dovuto superare una certa resistenza al cambiamento e apprendere un nuovo modus operandi.

Abbiamo preso la decisione di sviluppare tutto utilizzando SwiftUI. Ogni nuova vista o componente utilizzava SwiftUI e le viste sviluppate in precedenza con UIKit sono state sostituite man mano che i modelli cambiavano e richiedevano sviluppo.
Philippe Weidmann, Tech Lead iOS – Infomaniak

La gestione del cambiamento è stata la prima grande sfida per un team formato e abituato a UIKit, perché la logica di sviluppo è fondamentalmente diversa con SwiftUI:

Con il metodo storico UIKit (il metodo imperativo) è possibile gestire manualmente la disposizione e il comportamento di ogni elemento dell’interfaccia con vincoli molto dettagliati. Occorre definire come le viste e i controlli debbano essere posizionati e dimensionati l’uno rispetto all’altro e rispetto ai loro contenitori. È inoltre necessario implementare una logica che consenta di reagire ai vari eventi come l’inserimento di un campo e quindi l’aggiornamento degli elementi.

Con il nuovo approccio SwiftUI, basta descrivere la vista che si vuole ottenere con gli stati e le relazioni tra gli elementi (il metodo dichiarativo). Il framework gestisce automaticamente il layout e le interazioni in base alle modifiche dei dati dell’applicazione (programmazione reattiva).

Alla fine, SwiftUI è più efficace e intuitivo quando si è riusciti a comprenderne la logica.

L’apprendimento passa attraverso varie fasi con la tendenza a conservare i nostri riflessi come:

  • Scrivere SwiftUI nel modo UIKit (pensavamo di fare bene).
  • Privilegiare la scrittura in UIKit per risolvere rapidamente un problema anziché affrontarlo con SwiftUI, che spesso richiede l’apprendimento tramite tutorial.

Poi la curva di apprendimento si raddrizza. Con UIKit, abbiamo il controllo su ogni dettaglio. Questo dà una comprensione completa di ciò che accade. Per contro, questa facilità apportata da SwiftUI nasconde i meccanismi interni. Senza disporre di una conoscenza approfondita dell’interno del framework, ciò può rendere inafferrabili alcuni bug visivi o problemi di prestazioni.

Per superare questo, il nostro team si è affidato alla comunità, alla ricerca e a moltissimi test. L’approccio empirico ci ha permesso di valutare le direzioni da prendere e di superare gli ostacoli.

3. La fluidità e le prestazioni

SwiftUI è un framework facile e rapido da usare, ma più complicato per creare interfacce efficaci e ottimizzate. Le ottimizzazioni non sono necessariamente ben documentate da Apple.

Nel nostro caso, l’applicazione Infomaniak Mail deve comportarsi nello stesso modo sia per gli utenti con 12 e-mail nella posta in arrivo che per quelli che ne hanno 50.000. Lo stesso vale per gli avatar dei contatti che devono essere visualizzati in modo fluido in tutte le discussioni, a prescindere dal numero di partecipanti. Non è stato questo il caso.

Come spiegheremo più avanti, ci siamo resi conto che ci sono cose che non si possono fare con questo Framework. Ma l’informazione deve esistere.

4. Personalizzazione dell’applicazione: i vincoli UI/UX

Infomaniak punta sulla propria identità visiva coerente su tutte le piattaforme, Android e iOS, a costo di allontanarsi dalle convenzioni di Apple.

A volte, SwiftUI è resistente alla personalizzazione dei componenti e offre poche opzioni. In qualche modo Apple spinge gli sviluppatori a utilizzare il suo design system, ovvero il look and feel che si ritrova nelle applicazioni native come Mail o Promemoria.

In varie occasioni abbiamo dovuto creare componenti propri anziché utilizzare quelli messi a disposizione, e talvolta anche lottare contro il framework per raggiungere i nostri obiettivi. Ad esempio, utilizzando i meccanismi nativi, le applicazioni visualizzano il titolo delle viste (nel presente esempio il nome della cartella Ricezione per l’app Mail) in modo centrato. Per visualizzare il titolo a modo suo, l’applicazione Infomaniak Mail deve utilizzare un proprio meccanismo:

Visualizzazione del titolo per Infomaniak Mail
Visualizzazione del titolo in un’applicazione nativa (qui Mail)

Per rendere più accessibile la scrittura delle e-mail, la nostra app dispone di un pulsante “Nuovo messaggio” chiamato pulsante flottante. Non esiste nel design system iOS, ma semmai nelle applicazioni Android. Lo abbiamo dovuto sviluppare partendo da zero.

Questo pulsante deve inoltre ritrarsi automaticamente per lasciare spazio all’utente affinché possa consultare l’elenco delle sue e-mail scorrendolo. È una sfida tecnica in quanto è necessario sapere quando l’utente sta scorrendo l’elenco e SwiftUI non offre un meccanismo semplice per farlo.

Pulsante flottante visualizzato
Pulsante mobile retratto

L’app Infomaniak Mail consente inoltre all’utente di selezionare le e-mail tramite pressione prolungata per poter agire su più messaggi. Questa meccanica non è offerta nativamente da SwiftUI, poiché si allontana dagli standard di Apple. Così abbiamo creato tutto da noi.

La personalizzazione ci ha richiesto di imparare a superare gli scenari previsti da Apple.

SwiftUI semplifica la creazione dei componenti e l’iterazione sul design, ma la personalizzazione resta difficile. Per i componenti, UIKit richiede più tempo ed è più prolisso, ma è molto più facile per quanto riguarda la personalizzazione.
Philippe Weidmann, Tech Lead iOS – Infomaniak

L’implementazione dei grandi componenti dell’applicazione Infomaniak Mail con SwiftUI

Tre grandi componenti dell’app Mail hanno posto sfide specificamente legate a SwiftUI:

1. L’elenco delle e-mail: la parte che richiede maggiori prestazioni

L’elenco delle e-mail è un punto centrale dell’esperienza utente. Può contenere un numero importante di elementi in diverse modalità di visualizzazione (compatta, standard, ampia). Nella pratica, alcuni utenti conservano tutte le loro e-mail in un’unica cartella. Dobbiamo quindi assicurarci che la navigazione sia sempre fluida ed efficiente, indipendentemente dal numero di e-mail presenti nell’elenco dell’utente.

Nella sua documentazione, Apple fa pensare che l’uso del componente “List” di SwiftUI sia semplice: si prende ogni elemento dal nostro elenco e lo si visualizza. Teoricamente, lo sviluppatore non dovrebbe porsi ulteriori domande.

Ma la realtà è più complessa. Quando ci sono molti elementi, i vincoli di uno smartphone possono influire sulle prestazioni. I meccanismi integrati in iOS esistono da sempre per visualizzare lunghi elenchi senza interferire sulla fluidità. Si parla di riutilizzo delle celle di un elenco quando il sistema visualizza solo gli elementi visibili sullo schermo e riutilizza gli elementi man mano che appaiono e scompaiono dallo schermo. SwiftUI nasconde questi meccanismi agli sviluppatori e il framework stesso assicura il riutilizzo delle celle per motivi di semplicità.

Il modo in cui avevamo inizialmente implementato il nostro elenco non consentiva a SwiftUI di garantire il corretto riutilizzo degli elementi e di calcolare le differenze in caso di modifiche. In pratica, un elenco di 50.000 e-mail poteva impiegare più di un secondo per essere visualizzato sui dispositivi più vecchi, rallentando notevolmente il resto dell’interfaccia. La documentazione del componente List non dava alcuna spiegazione sul problema.

I problemi di performance sono un tema ricorrente con SwiftUI. La documentazione per sviluppatori non menzionava esplicitamente l’impatto sulle prestazioni legato all’uso di un controller di flusso direttamente all’interno di un elenco. È stato solo grazie ai suggerimenti di un breve passaggio di un video (Demystify SwiftUI Performance) per il WWDC 2023 che siamo riusciti a risolvere i nostri problemi e a migliorare significativamente le nostre prestazioni.

La documentazione Apple è generalmente di buona qualità, ma raccomandiamo vivamente agli sviluppatori di seguire le sessioni video di WWDC, che contengono informazioni interessanti e sono prodotte molto bene. Il tutto disponibile gratuitamente.

2. Scrivere un messaggio

La scrittura dei messaggi è composta da due elementi principali:

  • L’intestazione (che contiene i destinatari e l’oggetto della e-mail)
  • Il corpo del messaggio (che è una WebView)

Nell’intestazione, l’app Mail suggerisce i contatti con il nome e l’avatar visualizzati. Una volta selezionato e convalidato il contatto, il suo nome diventa un componente chiamato “chip” (piccolo pulsante) e viene aggiunto all’elenco dei destinatari. Se attivato dall’utente, il chip visualizza una finestra di dialogo che consente di rimuovere il destinatario. Questi elementi non sono previsti da SwiftUI e hanno richiesto uno sviluppo su misura.

Nel corpo del messaggio, l’utente scrive il proprio testo in una WebView. In altre parole, scrive una pagina HTML senza rendersene conto. Per quanto riguarda gli sviluppatori, è necessario stabilire il collegamento tra il contenuto del messaggio così come viene visualizzato nella WebView e ciò che verrà inviato al destinatario (il codice nativo) tramite il server.

La scrittura di un nuovo messaggio è uno dei principali punti di accesso a un’applicazione di posta elettronica. Quindi è un punto di attrito potenzialmente importante nell’esperienza utente. Dato che la WebView su dispositivi mobili è piuttosto pesante, nel corso dell’anno, il nostro team svilupperà un nuovo contenitore da zero con l’obiettivo di ottenere prestazioni migliori.
Philippe Weidmann, Tech Lead iOS – Infomaniak

3. Il menu laterale personalizzato

Proprio come il pulsante flottante “Nuovo messaggio”, il menu laterale a scorrimento che può essere aperto premendo il pulsante “hamburger” in alto a sinistra non è un componente abituale sulle piattaforme Apple. Si tratta semmai di un elemento del “Material Design” di Google (Android). Si basa su una libreria che consente di ottimizzare e uniformare il comportamento degli elementi su tutti i dispositivi. Ma, a seconda di come viene progettato questo menu a scorrimento con SwiftUI, può essere molto poco performante. Per ottenere lo stesso look and feel lo abbiamo dovuto sviluppare partendo da zero.

Queste personalizzazioni richiedono uno sviluppo specifico di per sé, ma generano anche più lavoro nel tempo.

Dato che abbiamo realizzato diversi componenti non previsti da SwiftUI, dobbiamo posticipare sistematicamente queste aggiunte per le altre piattaforme come iPadOS ed eventualmente per macOS. Adattamenti che non avremmo dovuto fare se avessimo seguito alla lettera il framework di Apple senza integrare il nostro design system. L’arrivo di nuove piattaforme come VisionOS ad esempio spinge a riflettere, poiché rende più complesso l’adattamento delle nostre personalizzazioni.

Il comportamento naturale di un menu laterale è quello di aprirsi o nascondersi dal lato sinistro dello schermo seguendo il pollice dell’utente. Dato che non esiste un componente nativo in SwiftUI per questo comportamento, è stato necessario implementare questa vista da zero. In pratica, ciò significa sovrapporre la vista del menu a quella principale e spostarla a sinistra fino a renderla invisibile per nasconderla e viceversa per visualizzarla.

Inizialmente, il contenuto del menu non era separato dal contenitore del menu stesso, il che poneva grossi problemi in termini di prestazione. Infatti, per ogni variazione dello spostamento del menu (quindi ogni pixel di animazione a sinistra o a destra), l’intera vista è stata ridisegnata. Su un telefono di tipo recente, il rallentamento non era visibile, ma consumava comunque troppa CPU secondo i nostri criteri. Su un telefono di tipo meno recente, l’utente poteva percepire un rallentamento.

Il primo passo è stato identificare e misurare il problema con strumenti per assicurarsi che le modifiche realizzate portassero un beneficio reale.

Poi abbiamo separato la vista che contiene il menu (il contenitore) dal contenuto stesso. Ciò consente al framework SwiftUI di ridisegnare solo il contenitore senza toccarne il contenuto accrescendo enormemente le prestazioni.

Bilancio del passaggio da UIKit a SwiftUI

E se dovessimo rifarlo? Sceglieremmo sempre SwiftUI, ma procederemmo in modo più graduale.

Col senno di poi, è stato abbastanza audace e persino doloroso passare al 100% a SwiftUI in un solo colpo.

All’inizio ero piuttosto contrario a sviluppare l’app Infomaniak Mail interamente in SwiftUI. È stata una decisione difficile da prendere, ma oggi, se dovessimo rifarlo, lo rifaremmo. Questo ci dà un bel vantaggio sulla manutenzione e l’evoluzione dell’applicazione nel futuro.
Joris Bodin, Developer Team Leader – Mobile e Desktop

Vediamo i vantaggi di SwiftUI tornando a lavorare sulle nostre vecchie applicazioni scritte in UIKit. Un ViewController UIKit che gestisce un elenco può facilmente ritrovarsi con centinaia di righe da scrivere e mantenere, mentre poche righe SwiftUI potrebbero bastare.

Sviluppando in SwiftUI, ci si concentra principalmente sui dati da visualizzare, mentre UIKit richiede numerosi rivestimenti (wrapper) per ottenere ciò che si vuole.

SwiftUI rappresenta il futuro. Il framework porta progressi che cambiano la vita, come l’anteprima del rendering live dell’applicazione nell’interfaccia di sviluppo. Storicamente, Apple ha dimostrato che quando offre una tecnologia di avanzata concezione come SwiftUI, la mantiene nel tempo. Quindi sappiamo che i nostri sforzi probabilmente non saranno spazzati via tra tre anni, a differenza di Google che offre più novità, ma che le mette da parte più velocemente. A questo proposito, l’equivalente SwiftUI su Android, JetPack Compose, è spinto da una società diversa da Google, JetBrains. Crediamo che questo offra a JetPack Compose maggiori possibilità di durare.

Anche se UIKit è ben lontano dall’essere superato e rimane una buona opzione in molti casi, SwiftUI si sta imponendo gradualmente da solo. I suoi numerosi punti di forza facilitano lo sviluppo e il futuro delle piattaforme Apple. Anche se fare il grande passo può fare paura, non bisogna esitare a lanciarsi.
Valentin Perignon, sviluppatore iOS Infomaniak

Una delle principali sfide che abbiamo dovuto affrontare è stata: “Come avere una propria identità pur rispettando le linee guida di Apple?” Abbiamo visto che ciò che non è previsto dal framework comporta un maggior volume di lavoro.

Vorremmo consigliare agli sviluppatori esitanti di iniziare a farlo poco a poco. Un insegnamento tratto da questa esperienza è che “se trovate che sia complicato, probabilmente state facendo qualcosa di sbagliato”.

La documentazione SwiftUI non contempla tutto e abbiamo dovuto fare ricerche per trovare risposte, in particolare per quanto riguarda le prestazioni. Consigliamo di guardare i video delle conferenze online (WWDC) di Apple che contengono informazioni chiave che possono sbloccare una situazione.

Per le nostre altre applicazioni, kDrive è stato originariamente sviluppato su iOS 12 con UIKit perché SwiftUI è arrivato solo da iOS 13 con componenti mancanti. Poiché all’epoca non siamo riusciti a utilizzare SwiftUI, non abbiamo la possibilità di riutilizzare i componenti di kDrive nell’app Infomaniak Mail. Avendo imparato dalla nostra esperienza con l’app Mail, abbiamo intenzione di migrare a SwiftUI poco a poco, a pezzi.

Dal punto di vista professionale, padroneggiare una tecnologia all’avanguardia come SwiftUI rappresenta un valore importante nel mercato del lavoro. Consigliamo comunque ai giovani sviluppatori di conoscere UIKit, perché molte imprese non hanno ancora fatto questo cambiamento. SwiftUI è una tecnologia giovane “alla moda” che pochi conoscono al momento e siamo felici che sia il nostro caso.

Scopri altro