Начало Xcode

Появлением на свет этой среды разработки Apple ответила на тысячекратно заданный ей вопрос, нужны ли ей вообще сторонние разработчики программного обеспечения. Ответ можно было сформулировать и словами: нужны.

В конце 90-х, представители Metrowerks, производителя самого популярного и всеми любимого CodeWarrior, попытались договориться с Apple о взаимопомощи и поддержке. В течение многих лет Apple сама использовала в разработке программного обеспечения, и даже операционных систем, инструменты со стороны.

Для сохранения лица, финальные сборки строились местными орудиями труда, но общий кризис, назревающий в компании, крайне негативно сказывался на разработке средств разработки. Похоже, то что рассказывал мне один бывший «инструментальщик» Apple, похоже на правду: группа финансировалась по остаточному принципу, уровень зарплат был ниже чем в других подразделениях компании, и лучшие уходили.

Переговоры с Джобсом закончились приобретением Metrowerks микропроцессорным отделением Motorola.

CodeWarrior был лучше чем Project Builder, хотя сравнивать сложные объекты на лучше-хуже настолько же некорректно, как сравнивать координаты точек на плоскости по величине, в этом конкретном случае, увы, такое сравнение имело смысл. CodeWarrior генерировал более компактный и эффективный код, его пользовательский интерфейс был удобнее, да и выглядел симпатичнее, а служба технической поддержки интересовалась проблемами своих клиентов как если бы это было самым важным для компании.

Но...Стив так решил...

Независимость Apple от сторонних средств разработки

Еще во времена NeXT, Стив пришел к выводу что у серьезной компании, разрабатывающей оригинальную (в смысле, ни на какую другую систему не похожую) платформу, должны быть свои собственные средства разработки.

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

И даже если поставщик средств разработки внимательно прислушивается к проблемам клиентов, как Metrowerks, и пытается помочь, это не то же самое. Круг посвященных в интимные подробности совершенно секретных проектов, какие бы меры не принимались для сохранения тайны, неминуемо расширился бы, и это еще не самая большая беда.

В любом случае, Стив твердо решил превратить Project Builder в официальную и самую важную среду разработки для Mac’ов и честно предупредил об этом Metrowerks. Никто не станет мешать продавать CodeWarrior Carbon-разработчикам, но ни о каких соглашениях не может быть речи. Apple нужна собственная адекватная среда разработки, и она у нее будет.

Были только два параметра, по которым Project Builder превосходил CodeWarrior: это цена и разработка Cocoa-приложений. Project Builder был бесплатным, CodeWarrior стоил несколько сотен долларов. И, несмотря на талант и усилия инженеров Metrowerks, их продукт так и не смог даже сравниться с Project Builder в Cocoa, а переходная эпоха, когда почти все программное обеспечение для Mac OS X писалось в Carbon, подходила к своему концу.

Перемены

Вообще-то я не люблю резкие перемены, особенно в том, чем я пользуюсь каждый день. И не только я, скорее всего. Это действительно была совершенно другая программа. В ней были интегрированы те же самые привычные инструменты, но сама среда и правила поведения в ней были другие.

Старые баги, про которые было досконально известно как их обходить, и как вообще не сталкиваться с ними. Вместо них появились новые, незнакомые. Их было намного меньше, но о них я узнал на форуме. Я с ними сталкивался, но принял за особенности поведения.

Не знаю, заступался ли кто-нибудь за Metrowerks в судебном порядке, или все возможные проблемы урегулировали еще на стадии разработки Xcode, но практически все козырные свойства CodeWarrior были бесстыдно позаимствованы.

Xcode 1.0

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

Хотя Xcode был, пока дело не доходило до каких-то запредельных манипуляций с кодом, абсолютно предсказуем и понятен, несмотря на множество нарушений правил «гуманного» интерфейса. Но это нисколько не мешало. Может, не все правила... нужны?

Своих собственных новшеств в первой версии Xcode было предостаточно. Например, такая утилита как Fix&038;Continue. Запустив код на исполнение, в некоторых случаях в него можно было внести исправления без остановки исполнения и повторной компиляции.

Вроде были какие-то правила, в каких случаях это не должно срабатывать, не помню.

Куда важнее и интереснее подсистема для распределенного построения программ, с помощью которой можно было распределить эту задачу между несколькими Mac’ами, для ускорения процесса. Естественно, подобные технологии не бывают слишком просты, и для относительно небольших проектов не имеют смысла.

А вот операционные системы и сам Xcode строили с ее помощью, и сборкой систем занималась целая ферма из сотен Mac’ов. Утилита для этого называлась distcc.

В комплекте с Xcode поставлялись средства для разработки Cocoa-приложений с помощью Java, и полный комплект WebObjects, библиотеки которой тоже теперь были на Java. По моему, переход на Java окончательно добил WebObjects, и это не только мое личное мнение.

А из проблем могу вспомнить только две: проблемы с отладчиком (иногда) и плохую работу системы автоматического дописывания известных среде разработки ключевых слов. Вот это было серьезно: идентификаторы и в Cocoa, и в Carbon, очень длинные. Имена функций, констант и тому подобное.

Это неслучайно: Apple рекомендовала не гнаться за краткостью, не сокращать слова в идентификаторах и полностью описывать смысл и суть обозначаемого предмета. И сама делала именно это.

Например (и это еще далеко не самые длинные «ключевые слова»):

NSGetUncaughtException;

NSOutlineViewDataSource.

Обоснования приводились очень логичные: скорее всего, люди, придумавшие это правило, были абсолютно правы: если слова пишутся полностью, и исчерпывающе выражают смысл, их, как ни странно, легче запомнить.

Тем более, как утверждала документация Apple, в Xcode встроена первоклассная утилита, дописывающая эти длинные слова автоматически.

В Xcode 1.0 эта утилита была практически бесполезна. В Xcode 1.5 ее почти решили. В наши дни ее нет.

Apple