С какими фреймворками для iOS вы работали чаще всего и что вам нравится

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

Не список, а то, насколько осознанно вы выбирали инструмент. По ответу видно, на чём построены реальные экраны в вашем опыте, понимаете ли вы границы SwiftUI и умеете ли обосновать выбор, а не повторить моду.

Как отвечать

Назовите два или три фреймворка, с которыми действительно работали, и к каждому дайте фразу про задачу и фразу про ограничение.

• UIKit: императивная работа с представлениями, полный контроль над жизненным циклом, сложные коллекции и кастомные переходы. Цена: состояние синхронизируется руками;
• SwiftUI: декларативное описание интерфейса, быстрый прототип, @State и @Binding вместо ручных обновлений. Ограничения упираются в минимальную поддерживаемую версию iOS и в тонкую настройку списков;
• Combine или async/await: поток событий против линейного кода. Скажите, что выбрали и почему, новые проекты чаще уходят в структурированную конкурентность;
• Core Data: локальное хранилище с графом объектов. Упомяните работу с контекстами в разных потоках, это первое, о чём спросят дальше.

Хороший ответ заканчивается связкой: что нравится и на каком основании. Например, декларативный подход уменьшает число состояний, которые можно рассинхронизировать, но в проекте с поддержкой старых версий системы приходится жить в UIKit и встраивать SwiftUI точечно через UIHostingController.

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

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

Хвалят SwiftUI, но не могут назвать ни одного места, где он мешал. Ответ без ограничений читается как опыт из уроков, а не из живого проекта.

Путают фреймворк с архитектурой. MVVM, VIPER и Clean это способ разложить код, они не отвечают на вопрос, чем рисуется экран и чем хранятся данные.