@ObservedObject: vad det är, observera objekt och uppdatera View

Vad är @ObservedObject i SwiftUI

@ObservedObject är en property wrapper som prenumererar en View på ObservableObject-ändringar. När ett objekt markerat med @ObservedObject ändrar någon av sina egenskaper deklarerade med @Published, ritar SwiftUI automatiskt om vyn. @ObservedObject skapar inte objektet — det etablerar bara en anslutning mellan en befintlig ObservableObject-instans och den View som ska reagera på dess ändringar.

Den viktigaste skillnaden mellan @ObservedObject och @StateObject — är ägande. @ObservedObject förutsätter att objektet har skapats och lagrats någonstans högre upp i View-hierarkin. Den underordnade vyn får en referens till detta objekt via initieraren och observerar det bara. Om den underordnade vyn återskapas får den samma referens från föräldern — data går inte förlorad.

Enligt Apple Developer Documentation — SwiftUI (2025) är @ObservedObject tillgängligt från iOS 13, vilket gör det till det enda alternativet för att observera ObservableObject i projekt som stödjer äldre iOS-versioner. I iOS 14+ föredras @StateObject för att skapa objekt, men @ObservedObject förblir relevant för att överföra befintliga objekt.

Hur fungerar @ObservedObject

Mekanismen för @ObservedObject är baserad på ObservableObject-protokollet från Combine-ramverket. Varje klass som är kompatibel med ObservableObject får automatiskt en publisher objectWillChange som skickar en signal innan någon @Published-egenskap ändras. SwiftUI prenumererar på denna publisher via @ObservedObject och vid mottagning av signalen markerar vyn som att den kräver omritning.

class TaskViewModel: ObservableObject {
    @Published var tasks: [Task] = []
    @Published var isLoading = false
    
    func loadTasks() async {
        isLoading = true
        // hämta data
        isLoading = false
    }
}

struct TaskListView: View {
    @ObservedObject var viewModel: TaskViewModel
    
    var body: some View {
        List(viewModel.tasks) { task in
            Text(task.title)
        }
        .task { await viewModel.loadTasks() }
    }
}

När den överordnade vyn överför viewModel till TaskListView via initieraren, skapar SwiftUI en anslutning mellan objektet och vyn. Vid ändring av tasks-arrayen eller isLoading-flaggan ritar SwiftUI om TaskListView. Objektet förblir oförändrat — det lagras i den överordnade vyn via @StateObject.

@ObservedObject vs @StateObject: när ska vad användas

Skillnaden mellan @ObservedObject och @StateObject — är skillnaden mellan observatör och ägare. @StateObject skapar objektet och hanterar dess livscykel. @ObservedObject observerar bara objektet som har skapats och lagrats på en annan plats. Valet mellan dem bestäms av vymens ansvar för data.

Huvudregel: om View skapar ett objekt — @StateObject. Om View tar emot ett objekt — @ObservedObject. Brott mot denna regel till förmån för @ObservedObject för att skapa objekt leder till dataförlust vid ombyggnad av vyn. Brott till förmån för @StateObject för att ta emot objekt skapar en duplicerad instans, oberoende av föräldern.

Exempel på användning av @ObservedObject

Ett typiskt användningsscenario för @ObservedObject — en uppgiftslista, där rotvyn skapar en view model och listcellen tar emot den via @ObservedObject. Varje cell kan anropa metoder i view model och ändringarna visas automatiskt i hela listan, eftersom alla celler observerar samma objekt.

struct TaskRow: View {
    @ObservedObject var viewModel: TaskViewModel
    let task: Task
    
    var body: some View {
        HStack {
            Text(task.title)
            Spacer()
            Button("Klart") {
                viewModel.completeTask(task)
            }
        }
    }
}

struct TaskListContainer: View {
    @StateObject var viewModel = TaskViewModel()
    
    var body: some View {
        List(viewModel.tasks) { task in
            TaskRow(viewModel: viewModel, task: task)
        }
    }
}

I detta exempel skapar TaskListContainer viewModel via @StateObject och varje TaskRow tar emot den via @ObservedObject. När användaren klickar på „Done” i någon rad, ändrar viewModel.completeTask den publicerade egenskapen och alla Views som observerar detta objekt uppdateras automatiskt.

Vanliga misstag med @ObservedObject

Det vanligaste misstaget — att använda @ObservedObject för att skapa ett objekt inuti vyn. När vyn byggs om (t.ex. vid ändring av state), skapar SwiftUI en ny ObservableObject-instans, vilket leder till förlust av all ackumulerad data. Detta misstag är särskilt smärtsamt i NavigationStack, där en användare kan fylla i ett formulär och förlora data vid återgång.

Misstag: @ObservedObject istället för @StateObject

// ❌ Dataförlust: @ObservedObject behåller inte objektet
struct FormView: View {
    @ObservedObject var formVM = FormViewModel()
    // Ny formVM skapas vid varje ombyggnad av View!
}

// ✅ Korrekt: @StateObject behåller objektet
struct FormView: View {
    @StateObject var formVM = FormViewModel()
    // Objekt skapat en gång under vymens livstid
}

Misstag: överföring av @StateObject där @ObservedObject behövs

Om en underordnad View deklarerar samma ObservableObject via @StateObject, skapar den en oberoende kopia. Ändringar i det överordnade objektet syns inte i det underordnade och vice versa. Använd alltid @ObservedObject för underordnade Views som tar emot objektet utifrån.

Alternativ till @ObservedObject i SwiftUI

I modern SwiftUI finns flera alternativ till @ObservedObject, var och en med sina fördelar. Valet beror på applikationsarkitekturen, iOS-versionen och det specifika användningsscenariot.

• @EnvironmentObject — gör det möjligt att hämta ett objekt från SwiftUI-miljön utan explicit överföring via initieraren. Bekvämt för objekt som behövs på många skärmar, men kräver explicit injicering via .environmentObject().
• @State + @Binding — för enkla värdestyper behövs inget ObservableObject. Använd @State för lagring och @Binding för överföring till underordnade Views.
• @AppStorage — för UserDefaults-värden som automatiskt ska synkroniseras med vyn.
• @SceneStorage — för att spara temporärt tillstånd mellan omstarter av scenen (t.ex. position i en lista).

Valet mellan @ObservedObject och @EnvironmentObject — är en fråga om stil och arkitektur. @ObservedObject visar explicit vymens beroenden via initieraren, vilket gör koden mer förutsägbar. @EnvironmentObject är bekvämt för djupa hierarkier men döljer beroenden, vilket kan försvåra felsökning.