Что такое retain и release в iOS?

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

Понимаете ли вы, что память в iOS управляется подсчётом ссылок, а не сборщиком мусора, и умеете ли читать старый код на Objective-C. Вопрос почти всегда уходит дальше, в ARC, weak и циклы ссылок, поэтому вести туда стоит самому.

Как отвечать

retain увеличивает счётчик ссылок объекта на единицу, release уменьшает. Когда счётчик становится нулём, объекту посылается dealloc и память освобождается. Это ручное управление памятью в Objective-C с правилами владения: методы, чьи имена начинаются с alloc, new, copy или mutableCopy, отдают объект во владение вызывающему, и освобождать его нужно самому. Всё остальное возвращается автоосвобождённым, то есть release отложен до слива ближайшего пула (@autoreleasepool, и один такой пул сливается на каждом витке рабочего цикла).

Дальше главное: сегодня эти вызовы руками не пишут. ARC расставляет ровно те же retain и release на этапе компиляции, поэтому работа с памятью остаётся детерминированной, пауз сборщика мусора нет, а счётчик всё так же реален. Отсюда следствия, которые и хотят услышать: ARC не спасает от цикла сильных ссылок, поэтому обратная ссылка объявляется weak (обнуляется сама) либо unowned (не обнуляется, обращение после освобождения роняет приложение). Правило про слабый делегат и [weak self] в замыканиях растут из того же места. В Swift механизм не изменился, просто вызовы принадлежат рантайму Swift.

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

Называют ARC сборщиком мусора и обещают, что объект освободится «когда-нибудь». Освобождение происходит ровно в момент обнуления счётчика, и на этом держатся deinit и своевременное закрытие файлов и соединений.

Пытаются что-то доказать через retainCount. Значение не отражает владение: его искажают автопул, кэшированные и неизменяемые объекты, оптимизации компилятора.

Путают weak и unowned, а заодно считают, что под ARC утечка невозможна. Цикл из двух сильных ссылок утекает молча и ловится графом памяти в отладчике, а не чтением кода.