Migrating Rork Max SwiftUI to @Observable: Narrowing the Re-renders ObservableObject Was Spreading

Before / After: rewriting the ViewModel

Here is the ObservableObject version Rork Max is likely to emit.

// Before: ObservableObject
import SwiftUI
import Combine
 
final class GalleryViewModel: ObservableObject {
    @Published var wallpapers: [Wallpaper] = []
    @Published var searchText: String = ""
    @Published var isLoading: Bool = false
 
    var filtered: [Wallpaper] {
        guard !searchText.isEmpty else { return wallpapers }
        return wallpapers.filter { $0.title.localizedCaseInsensitiveContains(searchText) }
    }
 
    func toggleFavorite(_ id: Wallpaper.ID) {
        guard let index = wallpapers.firstIndex(where: { $0.id == id }) else { return }
        wallpapers[index].isFavorite.toggle()
    }
}

Moving to @Observable takes surprisingly little. import Combine and the @Published markers disappear, and the class gains the @Observable macro.

// After: @Observable
import SwiftUI
import Observation
 
@Observable
final class GalleryViewModel {
    var wallpapers: [Wallpaper] = []
    var searchText: String = ""
    var isLoading: Bool = false
 
    var filtered: [Wallpaper] {
        guard !searchText.isEmpty else { return wallpapers }
        return wallpapers.filter { $0.title.localizedCaseInsensitiveContains(searchText) }
    }
 
    func toggleFavorite(_ id: Wallpaper.ID) {
        guard let index = wallpapers.firstIndex(where: { $0.id == id }) else { return }
        wallpapers[index].isFavorite.toggle()
    }
}

Dropping @Published can feel unsafe at first. But under @Observable, stored properties are tracked by default. You do not opt in by hand. The mental model inverts: you opt specific properties out with @ObservationIgnored instead.

The view-side mapping

Once the ViewModel moves, swap the view-side property wrappers. This is the bulk of the migration. The mapping is as follows.

The owning view changes minimally — @StateObject becomes @State.

struct GalleryView: View {
    @State private var vm = GalleryViewModel()
 
    var body: some View {
        List(vm.filtered) { wallpaper in
            WallpaperCell(wallpaper: wallpaper) {
                vm.toggleFavorite(wallpaper.id)
            }
        }
    }
}

Pass each cell only the model it needs, not the whole ViewModel. This is the crux of narrowing re-renders. If a cell reads a single property of Wallpaper, it re-evaluates only when that property changes.

struct WallpaperCell: View {
    let wallpaper: Wallpaper
    let onToggle: () -> Void
 
    var body: some View {
        HStack {
            Text(wallpaper.title)
            Spacer()
            Button(action: onToggle) {
                Image(systemName: wallpaper.isFavorite ? "heart.fill" : "heart")
            }
        }
    }
}

Two-way binding needs @Bindable

For something like a search field where you want $ binding, you cannot write $vm.searchText directly against an @Observable object. You interpose @Bindable. Declare it at the property level for whole-view use, or rebind locally inside body with @Bindable var vm = vm.

struct SearchBar: View {
    @Bindable var vm: GalleryViewModel
 
    var body: some View {
        TextField("Search", text: $vm.searchText)
            .textFieldStyle(.roundedBorder)
    }
}

Forget this step and $vm.searchText fails to compile. The error is clear, so it will not stump you — but it is the single most frequent stop along the way.

What Instruments measured, before and after

Feel is not a decision criterion, so I counted View Body executions in the Instruments SwiftUI template. The subject was a list of 60 cards, and the operation was "toggle one card's favorite" repeated 10 times.

The numbers shift with device and data volume, but the trend was unambiguous. Under ObservableObject, a single state change rippled to every card on screen; under @Observable, only the target card re-evaluates. The half-beat hitch at the end of a scroll stopped bothering me on-device as well.

The important part is that this improvement did not come from making heavy work faster. The work itself is unchanged. What changed is the scope — who gets re-rendered. It is a subtractive optimization, which is also why its side effects are easy to reason about.

Five places that break quietly

The migration is mostly clean, but a few spots change behavior without the compiler warning you. Here they are, roughly in the order I tripped over them.

Combine pipelines that depend on $prop won't compile, so you'll catch those. But a small utility subscribed to objectWillChange goes silent without a word. Grep the whole project for objectWillChange before migrating, and you'll sleep easier.

Getting Rork Max to emit @Observable from the start

Alongside migrating existing code, you want new code generated as @Observable from the outset. Rork Max follows prompt instructions faithfully, so stating the state-management policy explicitly pays off. I attach a line like this.

For state management, do not use ObservableObject or @Published.
Implement it with the Observation framework's @Observable macro.
Use @State and @Environment for view property wrappers,
and route two-way bindings through @Bindable.

With that instruction in place, the generated ViewModel arrives as @Observable, and the follow-up rewrite nearly vanishes. Changing the generation policy tends to cost fewer keystrokes over time than fixing generated code after the fact.

Wrapping up

Migrating from ObservableObject to @Observable is not a flashy feature. But it quietly tidies up something you feel directly: how far a single change ripples across the screen.

The sequence is straightforward. Strip @Published and import Combine from the ViewModel and add @Observable; swap the view-side property wrappers per the mapping table; interpose @Bindable only where you need two-way binding. Then measure body executions in Instruments, and sweep away any leftover objectWillChange dependencies. Follow that order and the move should carry no major surprises.

Next time you feel a faint hitch at the end of a list scroll, look at which views are re-evaluating in Instruments before you suspect the frame rate. Narrowing the scope solves it more often than you'd expect. I hope this helps with your own implementation, and thank you for reading.