Как быстро выяснить, кто виноват в том, что обычный контрол (UIView, UIImageView и прочего стандартного класса) уехал куда-то в сторону

Просто быстро на время создайте подкласс (например для UIImageView создайте его дочерний класс UIImageView2). Для этого даже не создавайте отдельные исходники, добавьте interface часть в заговолочный файл в класс того контроллера, где возникает непонятный баг. В исполняемый файл (m) добавьте implementation вашего UIImageView2 класса всего лишь с одним методом setFrame (этим методом вы переопределите стандартный setFrame-метод). Вот как это сделал я

@implementation UIImageView2

- (void)setFrame:(CGRect)frame
{
    NSLog(@"++++++ frame.origin.x = %f", frame.origin.x);
    [super setFrame:frame]; // сюда поставьте брекпоинт, чтобы выяснить какая такая "сволочь" портит фрейм вашего объекта на окне :)
}

@end

Hoochie Men на алтайской дудке

Инструмент Automation (автоматическое тестирование iOS-приложений) - некоторые способы обойти траблы

Инструмент Automation позволяет автоматически тестировать iOS приложения, используя для написания тестовых скриптов JavaScript.

Вероятно, в Apple решили, что заботиться об удобстве работы программистов не настолько остро актуально в отличие от заботы о массовом пользователе... В общем Automation имеет ряд неприятных багов.

1 баг:
Кнопка нажимается с точки зрения Automation, но вы своими глазами видите на экране, что ничего не произошло. В таком случае я выхожу из положения так: я вставляю в скрипте цикл (обычно хватает 2-3 итераций), с помощью которого выясняю встроенными в Automation JavaScript-функциями произошло ли то, что должно произойти после нажатия (например, появилось ли окно, что можно проверить через myView.isVisible() && myView.isValid() условие)

2 баг:
Кнопка, контрол или что-нибудь ещё вообще никак не реагирует на нажатие, если это нажатие является первым нажатием по только что открытому окну. Спасает меня вот что: я с помощью скрипта "провожу пальцем" по тому месту (обычно это середина верхнего бара), где можно водить и это ни к чему не приведёт. После этого окно "оживает" и дальше уже можно нажимать на кнопку.

Продаю недорого 64-разрядный Хакинтош с установленной Mountain Lion

Продаю недорого 64-разрядный Хакинтош с установленной Mountain Lion (устанавливал хакинтошник-профи), я использовал его для iOS-разработки. Подробнее на http://do.ngs.ru/1101351267

Как прицеплять в Xcode-проект статические либы отдельно для Debug и Release

Это касается только Xcode 4 и более поздних версий:

ПЕРВЫЙ ТРУДОЁМКИЙ СПОСОБ: прицепить либы к дереву проекта намертво (вероятно можно и мышкой добавить нужные либы из Finder-папки перетаскивая их прямо в дерево проекта), но я делал это выходя в свойства проекта, потом переключался на вкладку Target, выбирал там Build Phases -> Link Binary With Libraries.

Этот первый способ плох тем, что Xcode порой глючит, и не в состоянии отличить дебаг-либу от релизной и может прицеплять дебаг-либу при релизной сборке приложения. Поэтому мне пришлось написать shell-скрипты, которые прятали в Temp-папки те либы, которые мне мешали и shell-скрипты для возвращения этих либ на прежние места. То есть перед Release-сборкой приложения все дебаг-либы можно аккуратно убрать одним запуском скрипта - при этом эти либы окрасятся в тревожный красный цвет в дереве проекта, но пусть это вас не пугает - приложение будет исправно собираться с оставшимися релизными либами.

НОВЫЙ ХОРОШИЙ СПОСОБ (пока плохо мной оттестирован): не добавлять либы первым способом в дерево проекта. Добавьте пути к нужным либам (включая имена файлов этих собранных либ) в настройках проекта и настройках таргета  -> Build Settings -> Linking -> Other Linker Flags (в подраздел Debug добавьте пути к дебаг-либам, в подраздел Release - к релиз-либам). Кроме того, вы можете в Debug/Release подразделы добавить вложенные подразделы для разных таргетов (для симуляторов и девайсов) - для этого найдите + кнопку справа внизу "Add Build Settings", нажмите на неё и выберите "Add Conditional Settings" (укажите пути для симуляторных и девайсовских дебаг/релиз либ).