Perché distribuiamo Swift e non SwiftUI
Ogni WWDC dal 2019 ha spinto SwiftUI un po’ oltre i limiti, e ogni volta che iniziamo a sviluppare una nuova app ci riuniamo come team per porci la stessa domanda: Si è già guadagnato un posto nelle nostre app? Finora la risposta è stata “no” per gli aspetti che contano — e probabilmente “sì” per quelli che non contano.
Questo non vuole essere un giudizio su SwiftUI in generale. Sono molti i team che realizzano app eccellenti utilizzando questo framework. Si tratta piuttosto di una descrizione di come lo utilizziamo noi: un piccolo studio che gestisce contemporaneamente diverse app per iPhone e iPad, senza margine per imprevisti in nessuna di esse.
Cosa funziona
SwiftUI è davvero ottimo per le schermate di impostazioni statiche, i layout dei moduli e qualsiasi situazione in cui l’albero delle viste sia piccolo e il flusso dei dati sia unidirezionale. Noi lo usiamo. Lo utilizziamo anche per le anteprime durante la progettazione: il ciclo di iterazione è più veloce rispetto a quello di UIKit.
In pratica, ciò significa che la schermata in cui si selezionano le unità o si esportano i dati è spesso realizzata con SwiftUI, integrata all’interno di un’app le cui schermate principali sono basate su UIKit. Le due tecnologie coesistono senza particolari attriti e la loro combinazione ci permette di utilizzare ciascuna di esse nei contesti in cui dà il meglio di sé, invece di dedicare l’intera app a un unico approccio.
Cosa non funziona (per noi)
Non appena una schermata richiede gesti personalizzati, elenchi sensibili alle prestazioni, stati di navigazione complessi o tempistiche precise nelle animazioni, torniamo a UIKit. Il motivo non è una moda del momento: è il tipo di bug che riscontriamo quando non lo facciamo. SwiftUI è migliorato notevolmente nelle ultime versioni, ma continua a riservarci sorprese in fase di esecuzione come raramente accade con UIKit.
I casi concreti aiutano. Un programma per imparare a digitare richiede che ogni battuta produca il carattere corretto senza ritardi visibili e che lo schermo stia al passo con le dita dell’utente. Una lunga cronologia di voci registrate in un’app di monitoraggio deve scorrere senza intoppi su un telefono di vecchia generazione. Un’agenda con funzionalità drag-and-drop richiede gesti che non entrino in conflitto con quelli del sistema stesso. Sono proprio questi i tipi di schermate in cui abbiamo riscontrato che UIKit è più prevedibile.
I compromessi
Continuare a usare UIKit ha un costo. Significa più codice per la stessa schermata e implica che chiunque si unisca al team debba sentirsi a proprio agio con un framework più vecchio che i tutorial tendono sempre più spesso a tralasciare. Alcune nuove funzionalità di sistema arrivano prima in SwiftUI e adottarle da UIKit richiede un lavoro di integrazione aggiuntivo. Dobbiamo anche ammettere che parte della nostra cautela deriva dalla familiarità: conoscere a fondo un framework ha il suo valore, ma può anche diventare una scusa.
C’è anche una questione ancora aperta. Le nostre app iPhone e iPad funzionano già sui dispositivi Mac con Apple Silicon, e abbiamo in programma di sviluppare app native per Mac. Se SwiftUI rendesse significativamente più semplice la condivisione del codice dell’interfaccia tra queste piattaforme, il quadro potrebbe cambiare.
Cosa abbiamo sbagliato
Una volta abbiamo usato SwiftUI per una schermata che sulla carta sembrava semplice, ma che poi si è rivelata tutt’altro: un elenco con azioni di scorrimento personalizzate e uno stato che cambiava durante lo scorrimento. Funzionava bene nelle anteprime, ma in modo strano sui dispositivi reali. Ricostruirla in UIKit ci ha richiesto più tempo di quanto ne avrebbe richiesto partire direttamente da lì. Ora decidiamo caso per caso, in anticipo, in base a ciò che la schermata deve effettivamente fare.
Questa è l'unica vera prova: Ci riserverà qualche sorpresa in fase di produzione? Per la maggior parte dei progetti che realizziamo, la risposta esclude SwiftUI come piattaforma principale. Ne riparleremo l'anno prossimo.