Diciamolo francamente, sviluppare app, da quando esiste il linguaggio Swift è diventato un gioco da ragazzi.

Se gli aggiungiamo anche la presenza di Storyboard, Xib, Auto Layout… cosa vogliamo di più dalla vita noi poveri developers?

La risposta, oggi è semplicissima, SwiftUI.

Cos’è SwiftUI?

SwiftUI è il nuovo framework per lo sviluppo delle User Interface pensato per sostituire UIKit (o come complemento).

E se ti stai chiedendo perché Apple sentisse la necessità di tirar fuori un nuovo framework, le risposte sono molteplici e ti faranno tutte rimanere a bocca aperta.

Ora, prima di giocare al lancio del mac, fermati e guarda questo pezzo di codice. Poi confrontalo con l’equivalente UIKit e ti renderai conto che forse è il momento di passare a SwiftUI:

Ora, un bel respiro, e cominciamo ad analizzare gli aspetti principali di SwiftUI.

Cominciamo!

Live Rendering

Se con UIKit sembrava andare tutto per il meglio, bastava mettere piede fuori i confini Apple per vedere come il mondo dello sviluppo si stava muovendo da tutt’altra parte.

React Native e Flutter sono solamente due degli esempi più noti. E ti cito questi, perché oltre ad essere framework multipiattaforma hanno in comune un fattore che li rende altamente competivi (e famosi).

Il live rendering dei componenti (view).

Cioè quel processo che permette di compilare ed iniettare un cambiamento in maniera pressoché instantanea nell’app in esecuzione (si, non è fantascienza).

Modifichi il testo di un bottone, la forma etc e subito lo vedi comparire nell’app. Muovi un componente ed eccolo spostato anche in live…

In pratica hanno eliminato tutti quei tempi morti causati dal processo di: compilazione, building e attesa del simulatore (o meglio, avvengono ma non li noterai).

Se con UIKit tutto ciò è assolutamente impensabile, con swiftUI diventa realtà.

Ecco un assaggio:

La live preview vista su Xcode non è un rendering degli elementi, è proprio l’applicazione in run (come se fosse il simulatore, ma direttamente dentro Xcode).

La tecnologia utilizzata è una features del linguaggio Swift che si chiama Dynamic Replacement.

🔥 Per poter usare la live preview devi aver installato macOS 10.15.

Swift puro

Il core di UIKit è interamente scritto in Objective C. Noi sviluppatori Swift usiamo un layer che ci permette di interagirci tramite api swift friendly.

Questo processo porta inesorabilmente a scrivere tantissimo codice boilerplate.

Cioè codice che prescinde dalle funzionalità in sé ma serve solamente a far funzionare il componente (pensa, per esempio, ai protocolli UITableViewDataSource e Delegate della UITableView).

SwiftUI architettura

SwiftUI è un framework scritto interamente con il linguaggio Swift e scollegato da UIKit. Questo significa che ha nuove logiche e nuovi paradigmi di sviluppo.

Compatibilità con UIKit?

Si! Puoi usarli entrambi nello stesso progetto. L’uno non prescinde l’altro. Ovviamente metterli in comunicazione, dato che usano paradigmi differenti (vedi sotto) potrà comportare un po’ di mal di testa (ma si può fare).

UIKit deprecato?

No, per il momento. Significherebbe la ribellione ed Apple non vuole questo.

Però, probabilmente, tra qualche anno (molti) SwiftUI sarà la tecnologia di punta.

Declarative programming

Pur con tutte le tecnologie, framework, paradigmi e pattern continuiamo a programmare come programmavano i nostri nonni, cioè in modo Imperativo.

L’Imperative Programming definisce il cambiamento di stato di un elemento in maniera rigorosa. Da un’istruzione A sappiamo che ne deriverà sempre B.

Per farti un esempio:

var list: [User]
list = getList()
if (list.isEmpty) {
    showErrorAlert()
} else {
    refreshTableView() // chiama il cellForRow
}
func cellForRowAt(....) {
    let model = list[indexPath.row]
    cell.label.text = model.name
    cell.label.textColor = UIColor.black
    cell.image = model.image // lo stato dell'oggetto cell è mutabile
    //
    //
    return cell
}

Tutto è definito tramite “Ordini”. Se succede questo allora devi fare questo.

Con l’Imperative Programming si definisce il “come” ed il “perché” un oggetto dovrà cambiare.

Se non c’è, apparentemente, nulla di sbagliato in questo approccio (non starò qui a parlare di pregi e difetti) dall’altro lato la Declarative Programming cambia totalmente le carte in tavola.

Per la Declarative Programming lo stato di un oggetto non è definito a priori ma è solamente dichiarato.

Che significa? 🤔

Noi consigliamo ad un componente come questo dovrà apparire ma non definiamo mai il come ed il perché.

Per riproporti l’esempio di prima:

@State var model = Users.listModel
List(model.list) { item in
    Image(item.image)
    Text(item.name)
      .fontWeight(.light)
      .color(.black) // l'oggetto Text è immutabile, viene ridefinito ad ogni modifica
}

In pratica, abbiamo consigliato alla List (l’equivalente della UITableView) di mostrare gli elementi presenti dentro model.list. Ad ogni elemento chiediamo di creare una row con un’Image (simil UIImageView) ed un elemento Text (simil UILabel).

Declarative Programming: si definisce il “cosa” dovrà essere ma non il “come” ci dovrà diventare.

Multipiattaforma

SwiftUI è multipiattaforma (Apple si intende). Dato l’accesso diretto ai componenti nativi ed a delle nuove API, ci basterà definire il come dovranno essere gli elementi (Declarative Programming) e poi sarà il framework a trasformarli nei componenti nativi.

Quindi, una sola vera code base ed una compilazione multipiattaforma.

Xcode

Con il framework SwiftUI cambiano anche i tool di Xcode. Preparati a salutare definitivamente lo Storyboard, l’Auto Layout e le Size Class.

In particolare, proprio lo Storyboard non esisterà più (quanti mila likes per questa news?)

Ogni componente, View, avrà una live preview a se stante. Quindi, definirai i componenti in un file e li comporrai in altri.

Questo vuol dire che le Navigation (i vecchi segue per intenderci) dovranno essere gestiti da codice.

l’unico svantaggio è il non poter vedere tutto il percorso dell’app come accadeva con lo Storyboard.

ma dato gli enormi benefici di SwiftUI, pazienza 😂.

Considerazioni

Con il framework SwiftUI cambia totalmente il modo di sviluppare le applicazioni.

Dopo il linguaggio Swift e l’Open Source questa rappresenta la terza svolta nel reparto sviluppo di mamma Apple.

Sintomo che finalmente ha deciso di ascoltare la sua platea di sviluppatori che, da qualche anno ormai, lamentava servizi un po’ scadenti e tecnologie obsolete (pensiamo ai crash continui di Xcode, Storyboard impallati, versioning impossibile etc).

Urliamo ad alta voce, benvenuto swiftUI.

Documentazione

Prima di lasciarti, ti lascio i link alla documentazione ufficiale del framework swiftUI:

Buona Programmazione!