Какие существуют варианты передачи и хранения объектов в iOS?

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

Умеете ли вы подобрать хранилище под конкретные данные, а не складывать всё в UserDefaults или Core Data по привычке. Следом обычно просят объяснить, почему Core Data не база данных, и где хранить токен авторизации.

Как отвечать

Разделите ответ на две части. Передача внутри приложения:

• между экранами UIKit: внедрение через инициализатор или свойство, prepare(for:sender:) для сегуэ, обратно через делегат или замыкание;
• в SwiftUI: @State и @Binding для локального состояния, @Environment для общего, с iOS 17 модели на макросе @Observable;
• широковещательно: NotificationCenter или Combine, когда отправитель не знает получателей.

Хранение:

• UserDefaults: настройки и флаги. Весь plist читается в память при старте, поэтому большие массивы и картинки туда не кладут;
• Keychain: токены и пароли, шифруется системой и обычно переживает переустановку приложения;
• файлы через FileManager: Documents для данных пользователя, Library/Caches для того, что можно скачать заново, система вправе его очистить;
• Core Data и SwiftData: фреймворки графа объектов с отслеживанием изменений и миграциями. SQLite здесь лишь один из типов хранилища под капотом;
• SQLite напрямую через GRDB или свою обёртку: когда нужен полный контроль над SQL и производительностью.

Для сети и диска объекты сериализуют через Codable: JSONEncoder/JSONDecoder, PropertyListEncoder. NSKeyedArchiver с NSSecureCoding остаётся для классов Objective-C.

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

Называют Core Data реляционной базой. Это слой управления объектами в памяти, и после такой ошибки почти наверняка спросят про потоки: NSManagedObjectContext привязан к своей очереди, и передавать объекты между контекстами напрямую нельзя.

Кладут токен в UserDefaults. Это обычный plist в песочнице, он попадает в бэкап и читается на устройстве с джейлбрейком.

Путают Documents и Caches: большие скачиваемые файлы в Documents уходят в бэкап iCloud, что нарушает рекомендации Apple по хранению данных.