SwiftUI — nyckelbegrepp, View, State och Data Flow

Vad är SwiftUI?

SwiftUI — Apples deklarativa UI-ramverk, radikalt annorlunda från UIKit. Istället för att skapa kontroller, vyer och manuellt hantera deras livscykel, beskriver utvecklaren gränssnittet i form av deklarationer: vad som ska finnas på skärmen, inte hur det ska byggas. SwiftUI bygger på principen om reaktivitet: gränssnittet är en funktion av tillståndet. När tillståndet (State) ändras, räknar SwiftUI automatiskt om body för alla beroende Views och uppdaterar bara de ändrade delarna av skärmen. SwiftUI finns tillgängligt på iOS 13+, iPadOS 13+, macOS 10.15+, watchOS 6+, tvOS 13+ och visionOS 1+. SwiftUI-kod är plattformsoberoende: en fil fungerar på iPhone, iPad, Mac och Apple Watch med minimala plattformsanpassningar. Enligt Apple WWDC Session 101 (2024) täcker SwiftUI över 90 % av standard UI-mönster i App Store.

SwiftUI vs UIKit

UIKit — det imperativa ramverket (2008): utvecklaren skapar en UIViewController, konfigurerar subviews i viewDidLoad, implementerar delegate/datasource för UITableView och uppdaterar skärmen via reloadData eller setNeedsLayout. SwiftUI ersätter kontroller med enkla View-strukturer, delegater — med binding och onChange, Auto Layout — med HStack/VStack/ZStack och modifierare (padding, frame, offset). UIKit kräver manuell minneshantering via ARC; SwiftUI — strukturer som inte kräver referensräkning. SwiftUI:s prestanda är jämförbar med UIKit: ramverket använder en diffing-algoritm för minimal uppsättning ändringar. På IT Sectr används SwiftUI för nya projekt med iOS 17+ som mål; projekt med stöd för iOS 14–15 kräver UIKit på grund av SwiftUI:s begränsade kompatibilitet.

Deklarativ syntax i SwiftUI

I SwiftUI beskrivs gränssnittet via ViewBuilder — en result builder som omvandlar en uppsättning Views till en tuple eller Group. Modifierare (.padding(), .font(), .foregroundColor()) skapar nya Views med ändrade inställningar, muterar inte det ursprungliga objektet. Varje modifierare returnerar en ny View, vilket möjliggör kedjning. ViewBuilder stöder if/else, switch, ForEach — villkorlig och cyklisk rendering utan separata kontroller. View i SwiftUI är en value type (struct), vilket garanterar förutsägbart beteende och eliminerar race conditions.

View-protokollet och computed property body

View — ett protokoll med ett enda krav: computed property body av typen some View. Varje struktur som följer View beskriver sin del av skärmen i body. Typen some View — opaque return type som döljer den specifika typen av returnerad View (kombination av VStack, HStack, ZStack, Text, Image etc.). Swift-kompilatorn härleder den specifika typen vid kompileringstillfället, vilket bevarar prestandan för direktanrop utan typradering.

import SwiftUI

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

Strukturen GreetingView tar emot parametern name och visar två textblock i en vertikal stack. Modifierarna .font, .foregroundColor, .padding och .background konfigurerar utseendet. SwiftUI anropar body varje gång indataparametrarna (name) ändras — omritning sker endast för de ändrade delarna. I exemplet används RoundedRectangle med .ultraThinMaterial — inbyggd native blur-bakgrund i SwiftUI.

@State: lokalt tillstånd i SwiftUI

@State — en property wrapper som deklarerar lokalt tillstånd som tillhör ett enskilt View. SwiftUI hanterar automatiskt State-minnet: när värdet ändras ritas body om, men bara för Views som använder detta State. State är sanningens källa (source of truth) för enkla typer (String, Int, Bool, enum). Använd inte @State för komplexa datamodeller — för dem är @StateObject och @ObservedObject avsedda. State ska vara private och lagras i själva View, inte skickas mellan komponenter.

import SwiftUI

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

Startvärde count = 0. Varje knapptryckning ökar count; SwiftUI ritar automatiskt om CounterView helt (alla Views). I UIKit skulle ett liknande scenario kräva IBOutlet, IBAction och manuell uppdatering av label.text. @State garanterar att View bara ritas om vid ändring av ett specifikt State — SwiftUI:s diffing-algoritm hittar minimala ändringar i trädet.

@Binding: tvåvägskommunikation mellan Views

@Binding — en property wrapper som skapar en tvåvägsförbindelse mellan ett View och data som View inte äger. Binding är en referens till State (eller annan sanningens källa), som tillåter ett underordnat View att läsa och ändra värdet som lagras i föräldern. Binding markeras med prefixet $: $count skickar Binding<Int> till det underordnade View. Utan Binding kan det underordnade View inte ändra förälderns data — bara läsa dem.

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 äger State quantity och skickar Binding via $quantity. StepperControl kan ändra value, och quantity i föräldern synkroniseras automatiskt. Binding är inte en kopia av data, utan en bro till sanningens källa. Använd @Binding för anpassade kontroller, redigerare och återanvändbara komponenter som måste ändra förälderns data.

@ObservedObject och @StateObject: externa datamodeller

@StateObject — en property wrapper för att skapa och äga en instans av en klass som följer ObservableObject. View skapar objektet en gång per livscykel och ritas om när dess @Published-egenskaper ändras. @ObservedObject — en liknande wrapper, men View äger inte objektet — objektet skapas och lagras utanför View (skickas via initieraren). Apple rekommenderar @StateObject för sanningens källa i View-hierarkin och @ObservedObject för beroendeinjektion.

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("Välkommen, \(settings.username)!")
                    .font(.headline)
            }
        }
        .padding()
    }
}

UserSettings — en ObservableObject med två @Published-egenskaper. ProfileView äger objektet via @StateObject. Ändring av username eller isLoggedIn ritar automatiskt om ProfileView. @Published använder Combine Publisher för att meddela SwiftUI om ändringar. För att skicka settings till underordnade Views, använd @ObservedObject:

Data Flow i SwiftUI: fullständig bild

Apple definierar fyra nivåer av Data Flow i SwiftUI: @State (lokalt, value type), @Binding (tvåvägs), @StateObject/@ObservedObject (reference type med ObservableObject), @EnvironmentObject (globalt, injektion via miljön). EnvironmentObject gör det möjligt att skicka data genom hela View-hierarkin utan explicit överföring i initieraren. Dessutom arbetar @AppStorage med UserDefaults, @SceneStorage — med scenens tillstånd, @FetchRequest — med Core Data. Valet av Data Flow-nivå bestämmer applikationens arkitektur: enkla skärmar använder State/Binding, modulära — ObservedObject, storskaliga — EnvironmentObject + Redux-liknande lösningar (TCA, Composable Architecture).