Как быстро выяснить, кто виноват в том, что обычный контрол (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

Как прицеплять в 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" (укажите пути для симуляторных и девайсовских дебаг/релиз либ).

Полезные ссылки для iOS-программиста

Вот страницы, на которые я каждый день заглядываю и иногда общаюсь с участниками (если могу помочь советом):

http://www.rsdn.ru/forum/apple.os/
http://touchdev.ru/
http://habrahabr.ru/blogs/macosxdev/

Как совмещать C++ и Objective C код в одном файле (классе)

Есть 2 способа, как совмещать C++ и Objective C код в одном исходнике:

1) При добавлении в Xcode-проект нового Objective C класса (который будет включать в себя C++ код) дайте файлу реализации расширение.mm (а не.m как предлагается по умолчанию). Кроме того, можно смело переименовать в дереве Xcode-проекта файл, изменив расширение с m на mm.

2) Если вам нужно использовать Objective C код в C++ классе (файл реализации которого будет иметь расширение.cpp) то в дереве проекта нажмите правую кнопку мыши или сделайте иное действие (в зависимости от настроек Mac OS) чтобы вызвать контекстное меню. В контекстном меню выберите Get Info. Появится окошечко, в котором нужно поменять тип файла с cpp.cpp на objcpp.cpp. Кстати, это позволит коду узнавать #ifdef __IPHONE_3_1 (или какая у вас там версия iPhone OS), что необходимо, если вы работаете в коллективном проекте, где нужно писать переносимый код для разных платформ.