SwiftUI — concetti chiave: View, State e Data Flow

Cos'è SwiftUI?

SwiftUI — il framework UI dichiarativo di Apple, radicalmente diverso da UIKit. Invece di creare controller, viste e gestire manualmente il loro ciclo di vita, lo sviluppatore descrive l'interfaccia come dichiarazioni: cosa dovrebbe essere sullo schermo, non come costruirlo. SwiftUI si basa sul principio della reattività: l'interfaccia è una funzione dello stato. Quando lo stato cambia, SwiftUI ricalcola automaticamente il body di tutte le Views dipendenti e aggiorna solo le parti modificate dello schermo. SwiftUI è disponibile su iOS 13+, iPadOS 13+, macOS 10.15+, watchOS 6+, tvOS 13+ e visionOS 1+. Il codice SwiftUI è multipiattaforma: un singolo file funziona su iPhone, iPad, Mac e Apple Watch con adattamenti minimi. Secondo Apple WWDC Session 101 (2024), SwiftUI copre oltre il 90% dei pattern UI standard dell'App Store.

SwiftUI vs UIKit

UIKit — framework imperativo (2008): lo sviluppatore crea un UIViewController, configura le subview in viewDidLoad, implementa delegate/datasource per UITableView e aggiorna lo schermo tramite reloadData o setNeedsLayout. SwiftUI sostituisce i controller con semplici strutture View, i delegati con binding e onChange, Auto Layout con HStack/VStack/ZStack e modificatori (padding, frame, offset). UIKit richiede la gestione manuale della memoria tramite ARC; SwiftUI utilizza strutture che non necessitano di conteggio dei riferimenti. Le prestazioni di SwiftUI sono paragonabili a quelle di UIKit: il framework utilizza un algoritmo di diffing per insiemi minimi di modifiche. In IT Sectr, SwiftUI viene utilizzato per nuovi progetti con target iOS 17+; i progetti con supporto iOS 14–15 richiedono UIKit a causa della compatibilità limitata di SwiftUI.

Sintassi dichiarativa di SwiftUI

In SwiftUI, l'interfaccia viene descritta tramite ViewBuilder — un result builder che trasforma un insieme di Views in una tupla o Group. I modificatori (.padding(), .font(), .foregroundColor()) creano nuove Views con impostazioni modificate invece di mutare l'oggetto originale. Ogni modificatore restituisce una nuova View, consentendo il concatenamento. ViewBuilder supporta if/else, switch, ForEach — rendering condizionale e ciclico senza controller separati. View in SwiftUI è un value type (struct), garantendo un comportamento prevedibile ed eliminando le race condition.

Protocollo View e computed property body

View — un protocollo con un unico requisito: la computed property body di tipo some View. Ogni struttura conforme a View descrive la sua parte di schermo in body. Il tipo some View è un tipo di ritorno opaco che nasconde il tipo concreto della View restituita (impilamento VStack, HStack, ZStack, Text, Image, ecc.). Il compilatore Swift deduce il tipo concreto in fase di compilazione, preservando le prestazioni delle chiamate dirette senza cancellazione del tipo.

import SwiftUI

struct GreetingView: View {
    var name: String
    
    var body: some View {
        VStack(spacing: 12) {
            Text("Ciao, \(name)!")
                .font(.largeTitle)
                .foregroundColor(.primary)
            
            Text("Benvenuto in SwiftUI")
                .font(.body)
                .foregroundColor(.secondary)
        }
        .padding()
        .background(
            RoundedRectangle(cornerRadius: 12)
                .fill(.ultraThinMaterial)
        )
    }
}

La struttura GreetingView accetta un parametro name e visualizza due blocchi di testo in uno stack verticale. I modificatori .font, .foregroundColor, .padding e .background configurano l'aspetto. SwiftUI chiama body ogni volta che i parametri di input (name) cambiano — il ridisegno avviene solo per le parti modificate. L'esempio utilizza RoundedRectangle con .ultraThinMaterial — uno sfondo sfocato nativo integrato in SwiftUI.

@State: stato locale in SwiftUI

@State — un property wrapper che dichiara lo stato locale appartenente a una singola View. SwiftUI gestisce automaticamente la memoria di State: quando il valore cambia, il body viene ridisegnato, ma solo per le Views che utilizzano quello State. State è la fonte di verità per i tipi semplici (String, Int, Bool, enum). Non utilizzare @State per modelli di dati complessi — usa invece @StateObject e @ObservedObject. State dovrebbe essere privato e archiviato all'interno della View stessa, non passato tra componenti.

import SwiftUI

struct CounterView: View {
    @State private var count = 0
    
    var body: some View {
        VStack(spacing: 20) {
            Text("Conteggio: \(count)")
                .font(.system(size: 48, weight: .bold))
            
            Button(action: { count += 1 }) {
                Label("Incrementa", systemImage: "plus.circle")
            }
            .buttonStyle(.borderedProminent)
        }
        .padding()
    }
}

Il valore iniziale di count = 0. Ogni pressione del pulsante incrementa count; SwiftUI ridisegna automaticamente l'intera CounterView (tutte le Views). In UIKit, uno scenario simile avrebbe richiesto IBOutlet, IBAction e aggiornamenti manuali di label.text. @State garantisce che una View venga ridisegnata solo quando cambia uno State specifico — l'algoritmo di diffing di SwiftUI trova le modifiche minime nell'albero.

@Binding: comunicazione bidirezionale tra Views

@Binding — un property wrapper che crea una connessione bidirezionale tra una View e dati che la View non possiede. Un Binding è un riferimento a State (o un'altra fonte di verità), che consente a una View figlia di leggere e modificare il valore memorizzato nel genitore. Binding è denotato dal prefisso $: $count passa un Binding<Int> alla View figlia. Senza Binding, una View figlia non può modificare i dati del genitore — può solo leggerli.

import SwiftUI

struct StepperControl: View {
    @Binding var value: Int
    let range: ClosedRange<Int>
    
    var body: some View {
        HStack {
            Button(action: { if value > range.lowerBound { value -= 1 } }) {
                Image(systemName: "minus.circle")
            }
            Text("\(value)")
                .frame(minWidth: 40)
            Button(action: { if value < range.upperBound { value += 1 } }) {
                Image(systemName: "plus.circle")
            }
        }
    }
}

struct ParentView: View {
    @State private var quantity = 5
    
    var body: some View {
        StepperControl(value: $quantity, range: 1...10)
    }
}

ParentView possiede lo State quantity e passa Binding tramite $quantity. StepperControl può modificare il valore, e quantity nel genitore si sincronizza automaticamente. Un Binding non è una copia dei dati, ma un ponte verso la fonte di verità. Usa @Binding per controlli personalizzati, editor e componenti riutilizzabili che devono modificare i dati del genitore.

@ObservedObject e @StateObject: modelli di dati esterni

@StateObject — un property wrapper per creare e possedere un'istanza di una classe conforme a ObservableObject. La View crea l'oggetto una volta per ciclo di vita e viene ridisegnata quando le sue proprietà @Published cambiano. @ObservedObject — un wrapper simile, ma la View non possiede l'oggetto — l'oggetto viene creato e archiviato all'esterno della View (passato tramite un inizializzatore). Apple raccomanda @StateObject per la fonte di verità in una gerarchia di Views e @ObservedObject per l'iniezione di dipendenze.

import SwiftUI
import Combine

class UserSettings: ObservableObject {
    @Published var username: String = "Guest"
    @Published var isLoggedIn = false
}

struct ProfileView: View {
    @StateObject private var settings = UserSettings()
    
    var body: some View {
        VStack {
            TextField("Username", text: $settings.username)
                .textFieldStyle(.roundedBorder)
            
            Toggle("Logged In", isOn: $settings.isLoggedIn)
            
            if settings.isLoggedIn {
                Text("Benvenuto, \(settings.username)!")
                    .font(.headline)
            }
        }
        .padding()
    }
}

UserSettings — un ObservableObject con due proprietà @Published. ProfileView possiede l'oggetto tramite @StateObject. Le modifiche a username o isLoggedIn ridisegnano automaticamente ProfileView. @Published utilizza Combine Publisher per notificare SwiftUI delle modifiche. Per passare settings alle Views figlie, usa @ObservedObject:

Data Flow in SwiftUI: quadro completo

Apple definisce quattro livelli di Data Flow in SwiftUI: @State (locale, value type), @Binding (bidirezionale), @StateObject/@ObservedObject (reference type con ObservableObject), @EnvironmentObject (globale, iniettato tramite l'ambiente). EnvironmentObject consente di passare dati attraverso l'intera gerarchia di Views senza passaggio esplicito nell'inizializzatore. Inoltre, @AppStorage funziona con UserDefaults, @SceneStorage con lo stato della scena, @FetchRequest con Core Data. La scelta del livello di Data Flow determina l'architettura dell'applicazione: gli schermi semplici usano State/Binding, quelli modulari usano ObservedObject, quelli su larga scala usano EnvironmentObject + soluzioni simili a Redux (TCA, Composable Architecture).