Единственной постоянной в разработке програмного обеспечения являются баги. Давайте посмотрим правде в глаза, нам никогда не удавалось сделать все правильно с первого раза. Из-за небрежности или неправильных предположений, разработка программного обеспечения становится похожа на приготовление пирога в мотеле, кишащим тараканами, за исключением того, что в нашем случае мы сами создаем жуков. К счастью Xcode дает нам множество инструментов для того, чтобы держать насекомых в ужасе. Очевидно что для этой цели существует отладчик, который мы знаем и любим, но есть еще многое что он умеет помимо просмотра переменных и построчной отладки. Это туториал для начинающих и продвинутых iOS разработчиков, где вы сможете получить практический опыт работы с некоторыми менее известными но черезвычайно полезными методами отладки, таких как:
— как избавится от NSLog в пользу логирования брейкпоинтов;
— как избавится от списка TODO в пользу генерации предупреждений компилятора;
— остановка на условиях с выражениями;
— динамическое изменение данных с помощью LLDB и многое другое.
Как вы можете заметить, целью для меня является быть ленивым разработчиком. К счастью LLDB позволяет сохранить мое время на мартини. Он предоставляет мне отличные инструменты для того, чтобы я не был приклеен к моему компьютеру в течении дня и ночи. Устраивайтесь поудобнее в кресле и открывайте свой любимый напиток. Время становиться ленивым!
Замечу что данный туториал подразумевает что вы уже знакомы с основами отладки в Xcode. Если вы новичек, рекомендую пройти сначала этот туториал.

Лечу Crash'и NSLog'ами. Недорого. Многолетний опыт. 100% гарантия.

Примерно таким заголовком можно было бы описать то, что три с половиной месяца назад происходило у меня на одном из проектов. Вернее, это даже был не мой проект, но с проблемой crash'а пришлось разбираться именно мне.

Все началось с того, что на одном из относительно больших проектов начало стабильно вываливаться исключение при авторизации пользователя. «Ну и что тут такого? У всех бывает. Проверку на nil забыли поставить или где-то накосячили. „Тоже, мне, большое событие — crash на проекте“, — подумает большая часть программистов. В принципе — абсолютно согласен. Crash — не такое уж и редкое явление в программировании под iPhone, и с ним сталкиваешься по десять раз на день. Но этот был особенным. От него уже начало попахивать „магией“, когда мне сказали про его некоторые параметры и особенности:

• Воспроизводимость на симуляторе: 100%
• Воспроизводимость на устройстве: 0%
• Путь к крэшу (после локализации крэша): ~ 40 секунд
• Настройки оптимизации при компиляции (-O1,-O2...) не влияют на воспроизводимость
• XIB'ы в проекте не используются

Да выглядел он довольно безобидно:

// Code
UITextView * textView = [ [UITextView alloc] initWithFrame:CGRectMake(0, 150, _width, _height)];

// Exception
*** Terminating app due to uncaught exception 'CALayerInvalidGeometry', 
    reason: 'CALayer bounds contains NaN: [0 0; nan 200]'

»Ну тут же и ежу понятно, что width — после вычисления — NaN!", — подумал я. Бегло поглядев где и как вычисляется ширина вьюхи, и не найдя ничего особого опасного, я, для утверждения своей догадки, поставил перед созданием вьюхи NSLog. А вдобавок, и точку останова на строке с созданием элемента.

// Source:
NSLog(@"width = %f", _width);

//Output:
width = 200

«Гм», — подумал про себя я, и продолжил выполнение программы после точки останова. И крэша не произошло…