Приведи пример дедлока в iOS

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

Ждут не определение, а живой случай из приложения: где именно в коде с GCD или Swift Concurrency интерфейс встаёт намертво. По ответу видно, чинили ли вы такое сами: система убивает приложение за зависший главный поток.

Как отвечать

Самый частый случай в приложениях это попытка сделать асинхронный вызов синхронным:

let sema = DispatchSemaphore(value: 0)
api.load { result in      // колбэк приходит на главную очередь
    sema.signal()
}
sema.wait()               // вызвано с главного потока, приложение встало

Главный поток ждёт сигнал, а сигнал может прийти только на главном потоке, которому уже не дадут поработать. Рядом живёт DispatchQueue.main.sync из кода, который и так исполняется на главном потоке: обычно это вспомогательная функция «выполнить на главном», написанная без проверки текущего потока.

Назовите ещё пару мест, характерных для платформы: sync на своей же последовательной очереди, вложенные performAndWait у родительского и дочернего контекстов хранилища в разном порядке, повторный lock у нерекурсивного NSLock.

Про Swift Concurrency скажите отдельно. Блокирующие примитивы внутри async-функции удерживают поток кооперативного пула, а он ограничен числом ядер: несколько таких ожиданий парализуют пул, даже если кольца блокировок формально нет. Правило простое: в асинхронном коде ждут через await, а общее состояние прячут за актором.

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

Первое: оборачивают асинхронный интерфейс в синхронный ради удобства вызова. Семафор в такой обёртке работает ровно до первого вызова с главного потока или с очереди, куда приходит колбэк, и ломается уже в релизе, где тайминги другие.

Второе: считают, что переход на async/await отменяет тупики. Он убирает целый класс ошибок ручной синхронизации, но semaphore.wait(), performAndWait или sync внутри задачи остаются блокировкой потока, и зависание возвращается в новом виде.

Третье: диагностируют по одному потоку. Смотрят стек главного, видят ожидание семафора и списывают на медленную сеть. Смотреть надо стеки всех потоков разом в паузе отладчика, а ещё системные отчёты о зависаниях и трассировку состояний потоков в профилировщике.