SwiftUI: ce este, concepte cheie și View Protocol

Ce este SwiftUI?

SwiftUI este un framework declarativ, introdus de Apple în 2019 pentru a înlocui UIKit în proiectele noi. În loc să creeze manual instanțe UIView și să le adauge în ierarhie, dezvoltatorul descrie interfața prin structuri care implementează protocolul View. SwiftUI calculează automat diferența dintre starea curentă și cea nouă și redesenează doar părțile modificate, folosind propriul motor de randare.

Framework-ul este scris în Swift folosind value semantics (structuri, nu clase), ceea ce face componentele UI ușoare și thread-sigure. Spre deosebire de UIKit, unde UIViewController poate cântări 200+ bytes din cauza runtime-ului Objective-C, un View SwiftUI este doar o structură de câțiva bytes. Acest lucru este deosebit de important pentru watchOS cu memoria sa limitată.

Cross-platforma SwiftUI

Aceeași descriere View funcționează pe iPhone, iPad, Mac, Apple Watch, Apple TV și Apple Vision Pro. SwiftUI adaptează interfața la platformă: pe iOS — gesturi tactile, pe macOS — combinații de tastatură, pe watchOS — derularea Digital Crown. Aceasta reduce timpul de dezvoltare pentru companiile care lansează aplicații pe mai multe platforme Apple, dar necesită configurare suplimentară pentru elementele specifice fiecărei platforme.

View Protocol și corpul vizualizării

În SwiftUI, fiecare ecran este o structură care implementează protocolul View cu o singură cerință: proprietatea computată body de tip some View. Cuvântul cheie some (opaque type) ascunde tipul concret al view-ului, permițând SwiftUI să optimizeze randarea. În interiorul body, dezvoltatorul combină componente gata făcute — Text, Image, Button, List — cu ajutorul ViewBuilder, care colectează mai multe view-uri într-unul singur.

struct GreetingView: View {
    let name: String

    var var body: some View {
        VStack {
            Text("Salut, \(name)!")
                .font(.title)
                .foregroundColor(.blue)
            Image(systemName: "hand.wave")
                .imageScale(.large)
        }
        .padding()
    }
}

În exemplu, VStack (stivă verticală) conține Text și Image. Valoarea name este transmisă prin inițializatorul structurii — așa funcționează DI (Dependency Injection) în SwiftUI fără containere DI externe. Fiecare modifier returnează un nou view cu modificarea aplicată, fără a muta originalul. Acest lucru este posibil datorită imutabilității tipurilor value.

ViewBuilder și condiționale

ViewBuilder este un result builder, adnotat cu @resultBuilder, care colectează până la 10 view-uri într-unul singur. În interiorul body se pot folosi if/else, switch și ForEach fără împachetări suplimentare. ForEach funcționează cu elemente Identifiable — fiecărui view i se atribuie un id unic pentru animația corectă la inserare/ștergere.

Gestionarea stării: @State, @Binding, @ObservedObject

În SwiftUI, starea determină ce conținut este afișat pe ecran. Când starea se modifică, SwiftUI recolpă body-ul view-ului dependent și compară rezultatul cu anteriorul, aplicând algoritmul diff. Pentru stocarea stării se folosesc property wrappers — fiecare își rezolvă sarcina: stare locală, legătura cu un view copil sau un model de date extern.

struct CounterView: View {
    @State private var count = 0

    var var body: some View {
        VStack {
            Text("Contor: \(count)")
            Button("Mărește") {
                count += 1
            }
        }
    }
}

class UserViewModel: ObservableObject {
    @Published var name = ""
    @Published var age = 0
}

@State stochează o valoare locală simplă (Int, String, Bool) în interiorul structurii View. SwiftUI mută memoria din structură într-un depozit separat — de aceea proprietatea cu @State poate fi modificată (mutată), chiar dacă View este un tip value. @ObservableObject — pentru clase cu proprietăți @Published, ale căror modificări notifică automat SwiftUI despre necesitatea redesenării.

@Binding și legătura părinte-copil

@Binding creează o legătură bidirecțională cu sursa de date situată în view-ul părinte. Părintele transmite $variable (projected value), copilul citește și scrie valoarea prin binding. Acest lucru permite mutarea introducerii textului sau a comutatorului într-o componentă separată, păstrând starea în părinte. Fără @Binding, fiecare modificare ar necesita o închidere callback pentru transmiterea noii valori în sus.

Navigarea în SwiftUI: NavigationStack și NavigationLink

Înainte de iOS 16, navigarea în SwiftUI se baza pe NavigationView — un API învechit cu comportament complex pe iPad (split view, double column). Începând cu iOS 16, Apple recomandă NavigationStack — o alternativă simplificată cu rute tip-sigure. Dezvoltatorul definește un enum al rutelor posibile, iar NavigationStack gestionează automat stiva de ecrane cu suport pentru legături profunde și revenirea la rădăcină.

enum Route: Hashable {
    case detail(id: Int)
    case settings
}

struct ContentView: View {
    var var body: some View {
        NavigationStack {
            List {
                NavigationLink("Ecran detalii",
                               value: Route.detail(id: 42))
                NavigationLink("Setări",
                               value: Route.settings)
            }
            .navigationDestination(for: Route.self) { route in
                switch route {
                case .detail(let id): DetailView(id: id)
                case .settings: SettingsView()
                }
            }
        }
    }
}

Rutele de tip Route: Hashable permit utilizarea oricărui tip de date pentru transmiterea parametrilor. navigationDestination(for:destination:) leagă tipul rutei de view-ul țintă. Avantajul față de navigarea UIKit — nu este necesară redesenarea la adăugarea unei noi rute: este suficient să se adauge un case în enum și un handler în switch. Legăturile profunde sunt procesate prin processDeepLink pe NavigationStack.

Navigare programatică

Pentru tranziția programatică (după autentificare, timer sau răspuns server) se folosește @State cu inițializatorul NavigationLink: NavigationLink(isActive: $isActive). La setarea isActive = true, tranziția are loc fără atingerea utilizatorului. Alternativa — binding-ul array-ului $path în NavigationStack: $path.append(Route.detail(id: 1)).

View Modifier — configurarea aspectului

Modifier este o metodă care returnează o copie modificată a view-ului. Spre deosebire de UIKit, unde configurarea proprietăților se face prin mutarea view-ului existent, SwiftUI creează o nouă valoare cu modificarea aplicată. Lanțul de modificatori (chaining) construiește interfața finală din transformări secvențiale: font → spațiere → culoare → umbră → gest.

Apple oferă peste 200 de modificatori încorporați. Cei mai frecvenți sunt: .font(), .foregroundColor(), .padding(), .background(), .cornerRadius(), .shadow(), .opacity(), .offset(). Ordinea modificatorilor contează: .padding() înainte de .background() colorează zona cu spațiere, după — doar zona interioară. Modificatorii personalizați se creează prin protocolul ViewModifier.

Modificatori condiționali și animație

Modificatorii pot fi aplicați condițional prin operatorul ternar: .foregroundColor(isError ? .red : .primary). Pentru animație se folosește .animation(.easeInOut, value: state) — modificatorul de animație se leagă de o proprietate specifică a stării. La modificarea acestei proprietăți, SwiftUI animează tranziția între valoarea veche și cea nouă. Animația funcționează cu opacity, offset, scale, rotation, dimensiune și culoare — pentru fiecare proprietate este definit un AnimatableParameter corespunzător.

Pentru animații personalizate sunt disponibile .transition (apariție/dispariție) și .matchedGeometryEffect (tranziția lină a unui element între două containere). Acesta din urmă este folosit pentru animația hero în liste: pictograma dintr-o celulă a listei se transformă lin într-o imagine mare pe ecranul de detalii.

SwiftUI vs UIKit: compararea abordărilor

Alegerea între SwiftUI și UIKit este una dintre primele dileme ale dezvoltatorului iOS. Ambele framework-uri sunt suportate de Apple, dar rezolvă sarcina construirii interfeței în moduri fundamental diferite: SwiftUI declarativ, UIKit imperativ. Diferența se manifestă în gestionarea stării, navigare, performanță și compatibilitate.

Pentru proiecte noi cu versiunea minimă iOS 17, Apple recomandă SwiftUI ca framework principal. UIKit rămâne necesar pentru interfețe care necesită control fin asupra randării (UICollectionViewLayout personalizat, scene complexe CAAnimation) sau suport pentru iOS 12–14. Multe proiecte folosesc o abordare hibridă: SwiftUI prin UIHostingController este încorporat în aplicația UIKit, iar UIViewRepresentable permite utilizarea componentelor UIKit în ierarhia SwiftUI.