Какой у вас опыт с Realm

Что проверяют

Работали ли вы с Realm глубже, чем «сохранили объект и прочитали». Интервьюера интересуют живые объекты, привязка к потоку и миграции схемы. Следом почти наверняка спросят, почему Realm, а не Core Data или SwiftData, и что вы знаете о его нынешнем статусе.

Как отвечать

Опишите задачу, под которую выбрали Realm, и пройдитесь по местам, где у него своя модель:

• модели: в актуальном RealmSwift свойства объявляются через @Persisted, вариант @objc dynamic остался в старом коде;
• живые объекты: Results ленивые и обновляются сами, объект после записи в другом месте уже содержит новые данные. Отсюда observe и NotificationToken, который нужно хранить, иначе подписка умрёт;
• потоки: экземпляр Realm и его объекты привязаны к потоку, где созданы. Между потоками их передают через ThreadSafeReference или замороженную копию freeze(), а для Swift Concurrency есть Realm, изолированный на актор;
• запись: всё внутри realm.write, тяжёлые пачки лучше писать не на главном потоке;
• миграции: schemaVersion и migrationBlock в Realm.Configuration. Расскажите, как меняли схему в уже выпущенном приложении;
• SwiftUI: @ObservedResults и @ObservedRealmObject, если использовали.

Обязательно назовите статус: MongoDB объявила устаревшими Atlas Device Sync и мобильные SDK, облачную синхронизацию закрыли, а сама библиотека осталась открытой, но без активного развития. Для нового проекта это повод присмотреться к SwiftData, Core Data или GRDB, и хорошо, если вы скажете это сами.

Если Realm вы только пробовали, честно так и скажите и сравните его с хранилищем, которое знаете лучше.

Где спотыкаются

Пишут try! Realm() и считают это нормой. Открытие может упасть на миграции или повреждённом файле, а падение приложения на старте это худший исход.

Передают объект Realm в другой поток, получают исключение о неправильном потоке и не могут объяснить причину.

Не знают, что файл базы растёт и сам не сжимается, и что для этого в конфигурации есть shouldCompactOnLaunch.