С какими инструментами для работы с потоками в iOS вы работали

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

Это вопрос про опыт, а не про перечень API. Интервьюер хочет понять, писали ли вы многопоточный код руками и можете ли объяснить, почему в конкретной задаче выбрали именно этот инструмент. Следом обычно спрашивают, чем OperationQueue отличается от GCD или как вы переводили код на async/await.

Как отвечать

Стройте ответ по схеме «инструмент, задача, почему он»:

• GCD: DispatchQueue.main для интерфейса, глобальные очереди с QoS (.userInitiated, .utility, .background), своя последовательная очередь для защиты общего состояния, DispatchGroup для ожидания нескольких запросов, флаг .barrier на конкурентной очереди для схемы «много читателей, один писатель»;
• OperationQueue: зависимости через addDependency, ограничение maxConcurrentOperationCount, отмена через cancel(). Типичный случай: загрузка картинок в ленте с отменой, когда ячейка ушла с экрана;
• Swift Concurrency: async/await, async let и TaskGroup для параллельных запросов, actor и @MainActor для изоляции состояния, кооперативная отмена через Task.checkCancellation(). Старый API на колбэках оборачивается через withCheckedThrowingContinuation;
• блокировки: NSLock, OSAllocatedUnfairLock (iOS 16+), Mutex из фреймворка Synchronization (iOS 18+).

Плюсом будет упомянуть Swift 6 и строгую проверку Sendable. Примеры берите из своих проектов, с цифрами, если они есть. Если в проде был только GCD, так и скажите, а про Swift Concurrency расскажите, что пробовали в пет-проекте.

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

Перечисляют инструменты без задач. Фраза «работал с GCD и NSOperation» ничего не говорит о навыке, а на уточнении про зависимости или отмену ответ рассыпается.

Отправляют запрос, результат которого ждёт пользователь, в очередь с QoS .background. Система вправе откладывать такие задачи надолго, здесь нужен .userInitiated. Сюда же DispatchQueue.main.sync из главного потока, который гарантированно даёт deadlock.

Считают, что async сам уводит работу с главного потока. Task {}, созданный из кода на @MainActor, наследует этот актор, и тяжёлый синхронный цикл внутри него всё так же подвешивает интерфейс.