Performance issues with SwiftUI + realm

Understood. We use Realm, Swift & SwiftUI on macOS daily and don’t have any significant performance issues. That being said, our implementation could be way different than yours and I am sure our use cases are different as well.

I can tell you that in some cases, if you’re copying Realm objects to an array, it will hinder performance. But if you’re not doing that then it doesn’t apply.

Are you using @Observed objects? How is that implemented into a VStack? Did you try LazyVStack to see if there was any difference?

Seeing some code would be useful to track down the issue so if you have time, share some.

You actually don’t really need any example project, as the behavior is in the Realm SwiftUI quickstart with some minor modifications just to display that it’s happening.

All I’ve modified here is adding a simple counter state to ItemsView and some debug printing that shows when/why things rerender.

import RealmSwift
import SwiftUI

// MARK: Models

/// Random adjectives for more interesting demo item names
let randomAdjectives = [
    "fluffy", "classy", "bumpy", "bizarre", "wiggly", "quick", "sudden",
    "acoustic", "smiling", "dispensable", "foreign", "shaky", "purple", "keen",
    "aberrant", "disastrous", "vague", "squealing", "ad hoc", "sweet"
]

/// Random noun for more interesting demo item names
let randomNouns = [
    "floor", "monitor", "hair tie", "puddle", "hair brush", "bread",
    "cinder block", "glass", "ring", "twister", "coasters", "fridge",
    "toe ring", "bracelet", "cabinet", "nail file", "plate", "lace",
    "cork", "mouse pad"
]

/// An individual item. Part of an `ItemGroup`.
final class Item: Object, ObjectKeyIdentifiable {
    /// The unique ID of the Item. `primaryKey: true` declares the
    /// _id member as the primary key to the realm.
    @Persisted(primaryKey: true) var _id: ObjectId

    /// The name of the Item, By default, a random name is generated.
    @Persisted var name = "\(randomAdjectives.randomElement()!) \(randomNouns.randomElement()!)"

    /// A flag indicating whether the user "favorited" the item.
    @Persisted var isFavorite = false

    /// Users can enter a description, which is an empty string by default
    @Persisted var itemDescription = ""
    
    /// The backlink to the `ItemGroup` this item is a part of.
    @Persisted(originProperty: "items") var group: LinkingObjects<ItemGroup>
    
}

/// Represents a collection of items.
final class ItemGroup: Object, ObjectKeyIdentifiable {
    /// The unique ID of the ItemGroup. `primaryKey: true` declares the
    /// _id member as the primary key to the realm.
    @Persisted(primaryKey: true) var _id: ObjectId

    /// The collection of Items in this group.
    @Persisted var items = RealmSwift.List<Item>()
    
}

extension Item {
    static let item1 = Item(value: ["name": "fluffy coasters", "isFavorite": false, "ownerId": "previewRealm"])
    static let item2 = Item(value: ["name": "sudden cinder block", "isFavorite": true, "ownerId": "previewRealm"])
    static let item3 = Item(value: ["name": "classy mouse pad", "isFavorite": false, "ownerId": "previewRealm"])
}

extension ItemGroup {
    static let itemGroup = ItemGroup(value: ["ownerId": "previewRealm"])
    
    static var previewRealm: Realm {
        var realm: Realm
        let identifier = "previewRealm"
        let config = Realm.Configuration(inMemoryIdentifier: identifier)
        do {
            realm = try Realm(configuration: config)
            // Check to see whether the in-memory realm already contains an ItemGroup.
            // If it does, we'll just return the existing realm.
            // If it doesn't, we'll add an ItemGroup and append the Items.
            let realmObjects = realm.objects(ItemGroup.self)
            if realmObjects.count == 1 {
                return realm
            } else {
                try realm.write {
                    realm.add(itemGroup)
                    itemGroup.items.append(objectsIn: [Item.item1, Item.item2, Item.item3])
                }
                return realm
            }
        } catch let error {
            fatalError("Can't bootstrap item data: \(error.localizedDescription)")
        }
    }
}

// MARK: Views

// MARK: Main Views
/// The main screen that determines whether to present the SyncContentView or the LocalOnlyContentView.
/// For now, it always displays the LocalOnlyContentView.
@main
struct ContentView: SwiftUI.App {
    var body: some Scene {
        WindowGroup {
            LocalOnlyContentView()
        }
    }
}

/// The main content view if not using Sync.
struct LocalOnlyContentView: View {
    @State var searchFilter: String = ""
    // Implicitly use the default realm's objects(ItemGroup.self)
    @ObservedResults(ItemGroup.self) var itemGroups
    
    var body: some View {
        if let itemGroup = itemGroups.first {
            // Pass the ItemGroup objects to a view further
            // down the hierarchy
            ItemsView(itemGroup: itemGroup)
        } else {
            // For this small app, we only want one itemGroup in the realm.
            // You can expand this app to support multiple itemGroups.
            // For now, if there is no itemGroup, add one here.
            ProgressView().onAppear {
                $itemGroups.append(ItemGroup())
            }
        }
    }
}

// MARK: Item Views
/// The screen containing a list of items in an ItemGroup. Implements functionality for adding, rearranging,
/// and deleting items in the ItemGroup.
struct ItemsView: View {
    @ObservedRealmObject var itemGroup: ItemGroup
    @State var counter = 0
    
    /// The button to be displayed on the top left.
    var leadingBarButton: AnyView?
    
    var body: some View {
        let _ = Self._printChanges()
        NavigationView {
            VStack {
                // The list shows the items in the realm.
                List {
                    ForEach(itemGroup.items) { item in
                        ItemRow(item: item)
                    }.onDelete(perform: $itemGroup.items.remove)
                    .onMove(perform: $itemGroup.items.move)
                }
                .listStyle(GroupedListStyle())
                    .navigationBarTitle("Items", displayMode: .large)
                    .navigationBarBackButtonHidden(true)
                    .navigationBarItems(
                        leading: self.leadingBarButton,
                        // Edit button on the right to enable rearranging items
                        trailing: EditButton())
                // Action bar at bottom contains Add button.
                HStack {
                    Spacer()
                    Button(action: {
                        // The bound collection automatically
                        // handles write transactions, so we can
                        // append directly to it.
                        $itemGroup.items.append(Item())
                    }) { Image(systemName: "plus") }
                }.padding()
                
                Button("Increment counter (\(counter))") {
                    counter += 1
                }
            }
        }
    }
}

struct ItemsView_Previews: PreviewProvider {
    static var previews: some View {
        let realm = ItemGroup.previewRealm
        let itemGroup = realm.objects(ItemGroup.self)
        ItemsView(itemGroup: itemGroup.first!)
    }
}

/// Represents an Item in a list.
struct ItemRow: View {
    @ObservedRealmObject var item: Item

    var body: some View {
        let _ = Self._printChanges()

        // You can click an item in the list to navigate to an edit details screen.
        NavigationLink(destination: ItemDetailsView(item: item)) {
            Text(item.name)
            if item.isFavorite {
                // If the user "favorited" the item, display a heart icon
                Image(systemName: "heart.fill")
            }
        }
    }
}

/// Represents a screen where you can edit the item's name.
struct ItemDetailsView: View {
    @ObservedRealmObject var item: Item

    var body: some View {
        VStack(alignment: .leading) {
            Text("Enter a new name:")
            // Accept a new name
            TextField("New name", text: $item.name)
                .navigationBarTitle(item.name)
                .navigationBarItems(trailing: Toggle(isOn: $item.isFavorite) {
                    Image(systemName: item.isFavorite ? "heart.fill" : "heart")
                })
        }.padding()
    }
}

struct ItemDetailsView_Previews: PreviewProvider {
    static var previews: some View {
        NavigationView {
            ItemDetailsView(item: Item.item2)
        }
    }
}

To reproduce, run this, add an item, then click on the “Increment counter” button and check the log. You will see something like:

ItemsView: _counter changed.
ItemRow: @self changed.

ItemRow gets rerendered even though it did not (functionally) change at all. But, in actuality it’s a brand new observable object getting passed in to ItemRow.

A dev on github tested the memory address theory and said the same thing happens if you cache the items into an array, so that disproves the theory.

My current theory is just that when you pass a Realm object to a view, you’re always implicitly creating an observable object, and that is always going to cause the view to rerender.

If you do some extra work and only pass equivalent data as a struct, the problem goes away. But, obviously you lose a lot of benefits with this approach.

I think for simple apps using List views that use navigation to drill down to detail views, this likely isn’t much of a problem because List manages how many items are “mounted” at any given time. But imagine something like a kanban board desktop app using a lot of custom stuff instead of List, and you might be able to imagine it becoming a major problem. Rerendering a component far up on the hierarchy causes a huge cascade of rerendering.

-Jon

This is actually very accurate, I used to reproduce this behavior with the same means for a couple of years now, and avoid passing realm objects to a view, I started the struct approach years ago. This is very accurate and on point.

Also you can double check this by using TestFlight and comparing the re-renders that keep occurring on a page by page basis in the app. Readingminitial post, I’m glad I read through the rest of this as I was just about to suggest this.

Yes I find SwiftUI and RealmSwift don’t get along too well.

Just placing the cursor in a TextField that is bound to a Realm object property causes the whole user interface to lock up on macOS. For some reason it seems this is causing all UI objects to be re-rendered. Not sure this is a RealmSwift related issue or a SwiftUI issue.

I have two lists, one with around 30 realm objects and a second one with around 2000 objects (not realm objects).

The bound property in the TextField comes from one of the realm objects from the first list. Just placing the cursor in the TextField causes the colourful umbrella to show up for 20 or 30 seconds. Pretty strange.

EDIT:
LazyVStack {} seems to largely address the issue - which does not appear to be RealmSwift related. Seems SwiftUI will by default create all the list views unless LazyStack is used. !

That’s very concerning. One of the projects we use internally for testing is macOS, SwiftUI and displays a couple hundred realm objects in a list along with a few bound TextFields in the same UI.

We have not seen any slowdowns or other odd behavior. Not saying it isn’t there, we just dont notice them and are not experiencing a lock up.

Do you have some brief sample code that duplicates the behavior? Going forward, it would be helpful to know what to avoid doing!

I’ve found this problem to be SwiftUI itself. Any view with @FocusState will rerender any time there is a change in focus, whether or not it’s relevant to that view. Hopefully iOS 17 and macOS Sonoma will fix it. I haven’t looked into the latest focus changes for that yet.

This is kind of addressed in a prior post here:

The high level explanation is to take the data contained in a Realm object class, and put that data into a a struct so it’s static. Then pass those structs to the view for rendering. Because they are static, they don’t change and will not cause SwiftUI to refresh frequently. If the data in Realm changes on an object, only that object will be refreshed via the associated Realm object class.

The obvious downside to that is you loose a LOT of Realm functionality so I don’t feel it’s a good workaround.

At this time, we are not seeing an ongoing issues but definitely use LazyVStacks/LazyHStacks.

Any news on this issue / best practices that overcome abundant view invalidations?
Realm + Swift seems like a great way to rapidly prototype, but I haven’t managed to get the performance I want for a production-ready app, mainly because of @ObservedRealmObjects seeming to trigger a lot of abundant view invalidations.

The code below reproduces the issue: I would expect check marking a single item on the todo list with only invalidate that single TodoRow view; instead, it invalidates all rows.

import RealmSwift
import SwiftUI

// MARK: Models


@main
struct shufflelistApp: SwiftUI.App {
    var body: some Scene {
        WindowGroup {
            LocalOnlyContentView()
        }
    }
}



/// An individual item. Part of an `ItemGroup`.
final class Todo: Object, ObjectKeyIdentifiable {
    /// The unique ID of the Item. `primaryKey: true` declares the
    /// _id member as the primary key to the realm.
    @Persisted(primaryKey: true) var _id: ObjectId

    @Persisted var isChecked: Bool = false
    
    /// The backlink to the `ItemGroup` this item is a part of.
    @Persisted(originProperty: "items") var group: LinkingObjects<TodoList>
    
}

/// Represents a collection of items.
final class TodoList: Object, ObjectKeyIdentifiable {
    /// The unique ID of the ItemGroup. `primaryKey: true` declares the
    /// _id member as the primary key to the realm.
    @Persisted(primaryKey: true) var _id: ObjectId

    /// The collection of Items in this group.
    @Persisted var items = RealmSwift.List<Todo>()
    
    convenience init(n: Int) {
        self.init()
        for _ in 0..<n {
            self.items.append(.init())
        }
    }
    
}



/// The main content view if not using Sync.
struct LocalOnlyContentView: View {
    // Implicitly use the default realm's objects(ItemGroup.self)
    @ObservedResults(TodoList.self) var lists
    
    var body: some View {
        if let todoList = lists.first(where: {$0.items.count > 1 }) {
            // Pass the ItemGroup objects to a view further
            // down the hierarchy
            ToDoListView(todoList: todoList)
        } else {
            // For this small app, we only want one itemGroup in the realm.
            // You can expand this app to support multiple itemGroups.
            // For now, if there is no itemGroup, add one here.
            ProgressView()
               
                .onAppear {
                    $lists.append(TodoList(n: 50))
                }
            
        }
    }
}

//let realm = Realm()
// MARK: Item Views
/// The screen containing a list of items in an ItemGroup. Implements functionality for adding, rearranging,
/// and deleting items in the ItemGroup.
struct ToDoListView: View {
    @ObservedRealmObject var todoList: TodoList
    var body: some View {
        let _ = Self._printChanges()
        NavigationStack {
            SwiftUI.List(todoList.items) {
                ToDoRow(item: $0)
            }
           
        }
    }
}

struct ToDoRow: View {
    @ObservedRealmObject var item: Todo
    @Environment(\.realm) var realm
    var body: some View {
        let _ = Self._printChanges()
        HStack {
            Text(item._id.stringValue)
            Spacer()
            Button {
                 try? realm.write {
                    if let thawed = item.thaw() {
                        thawed.isChecked.toggle()
                    }
                }
            } label: {
                Image(systemName: item.isChecked ? "circle.fill" : "circle" )
                    .font(.title2)
            }
        }
    }
}

Seems the code implements HStack instead of LazyHStack (per above posts) - have you tried that?

Thanks for your reply Jay. Unfortunately putting the row in a LazyHstack still invalidates all rows when a single row is checkmarked.

Unless I’m missing something, this seems like a very problematic side-effect of using @ObservedRealmObject, and there Realm + Swift in general, for any project requiring a slightly more complex UI. As mentioned in the above posts, users that use e.g., a very simple List view to navigate to some detail view holding a single realm object might not notice much issues, but for slightly more complex projects showing a number of @ObservedRealmObjects on a single screen at the same time (e.g., a Kanban board) will very quickly experience significant lags in the UI as Swift will invalidate and rerender every single view containing an @ObservedRealmObject, instead of only the one that changed.

At least I would expect the simple two-view todo list example I provided to invalidate views more selectively, as it is as simple as a project can get and is even simpler than the sample code provided in the Realm SwiftUI docs.

@Richard_Anderson Thanks for the feedback - hopefully that was communicated to the Realm development team as well as they are important points.

Do the tools you suggest have current public support for iOS/macOS development or Swift SDK’s? I would like to look into that if they do - I don’t see anything on their site though.

Have not run into security issues yet, but unfortunately have to agree with the reactive part in my experience @Richard_Anderson.

@Jay FYI I am now also in the process of migrating away from Realm/MongoDB to Firebase Firestore storage, which offers similar real-time sync as Realm Swift – the initial reason I opted for Realm Swift a few years ago – but for which I could easily set up the above ToDoList example without the view invalidation issues. Hope the Realm development time will pick up this issue sometime in the future because, except for those view invalidations, I enjoyed using it a lot.

Do you know if they are aware? Otherwise I’m happy to open an issue.