Итак, продолжаю описывать уже немного утрясшиеся впечатления от iOS-разработки. Если кто-то пропустил, то вот первый пост. Теперь немного расскажу об инструментах и экостистеме. Сразу оговорюсь, что поскольку “настоящим сварщиком” мне называться пока рано, я могу быть не в курсе источников и реальных причин каких-то недочётов. Например, я наверняка буду приписывать отдельным инструментам недостатки, происходящие от других элементов тулчейна или даже просто из сложившихся здесь традиций.

IDE

Самый главный инструмент iOS-девелопера - это, конечно же, XCode. Этот инструмент вызывает смешанные чувства. С одной стороны, если сравнить его с таким монстром (в хорошем смысле) как IntelliJ IDEA, то чувствуется недостаток всяких приятных и ускоряющих работу неопытного девелопера фич (например, я не нашёл, как сгенерировать заготовки недостающих методов протокола). Естественно, и вполне в стиле Apple, нет никакого репозитория плагинов. Не обходится, к сожалению, без крэшей и странных багов. Диалог коммита в git, например, крэшит программу практически через раз, а в одном случае мне пришлось даже перезапустить систему, чтобы то ли XCode, то ли симулятор пришли в себя.

Довольно много сумятицы вносит, как XCode работает с файлами проекта: его структура и местоположение файлов на диске имеют друг с другом мало чего общего. Папки в навигаторе являются чисто “виртуальными” и при добавлении файлов в проект откуда-то ещё (например, из какой-нибудь опенсорсной библиотеки) в лучшем случае вы получите кашу из файлов в папке с проектом. В худшем - если забыть поставить галочку при добавлении - файл проекта просто сошлётся на них, а сами файлы останутся лежать где лежали, и, конечно, не попадут в VCS, и выяснится это, только когда проект откроют на другой машине. Я уже не говорю о том, что один и тот же файл можно добавить два раза, что ломает билд. Конечно, ко всему этому можно привыкнуть и делать всё аккуратно, но поначалу это вызывает путаницу.

С другой стороны, сделана эта IDE очень приятно, и, положа руку на сердце, можно сказать, всё действительно нужное для разработки под iOS и OSX там есть. Есть куча готовых шаблонов для приложений, поддержка svn и git (с учётом упомянутых выше проблем со стабильностью), средства юнит-тестирования и ряд основных рефакторингов. Дизайнер интерфейсов очень неплох (после ада андроидовских XML-ек с лейаутами), многие вещи делаются перетаскиванием стрелочек из одной области окна в другую. А уж после того как я увидел визуализацию найденных static analyzer-ом утечек памяти, я практически влюбился в этот инструмент.

Впрочем, отталкиваясь от опыта работы с IDEA, RubyMine и WebStorm, очень хотелось бы взглянуть на альтернативу от JetBrains: AppCode. Если будет время - обязательно попробую и опишу впечатления.

Пляски с криптографией

Если кто-то вам скажет, что самая сложная и запутанная часть в программировании для iOS - синтаксис Objective-C, или управление памятью, плюньте этому человеку в лицо. Лично у меня самое большое количество негатива вызвала запутанная возня с сертификатами. Даже если вы работаете в компании с девелоперским аккаунтом (то есть половина бюрократии уже сделана за вас), то для разработки (не распространения) одного приложения вам будет необходимо:

• создать certificate signing request
• с помощью него создать сертификат и положить его в кейчейн
• создать app ID
• создать provisioning profile для девайса (для симулятора не нужно, и на том спасибо)
• создать provisioning profile для приложения и добавить туда себя и свой девайс. Впрочем тут можно срезать углы, поскольку при указании bundle id можно использовать wildcard. С другой стороны, при добавлении сюда ещё одного разработчика или девайса, необходимо перегенерировать и импортировать его в систему заново.

Если представить себе что все эти артефакты имеют неприятное свойство “протухать” (то есть, имеют конечный срок действия), требуют для использования приватных ключей, которые лежат на машинах где был сделан signing request (а если ключа нет - то надо перегенерировать сертификат), умножить всё это на количество разработчиков в команде, а потом ещё раз на количество разрабатываемых приложений, то можно представить сколько нервов, времени и мата занимает вся эта возня. Я уже не говорю про то, на сколько граблей было наступлено при настройки headless сборки-проектов на билд-сервере. Codesign то в упор не видел кейчейна, то зачем-то требовал user interaction в виде окошечка подтверждения доступа к этому самому кейчейну. Впрочем, как и с другими “острыми углами”, наступив с десяток граблей и наведя порядок в управлении сертификатами, ключами и профайлами, к этому можно привыкнуть и, в общем, даже жить.

Управление зависимостями

Управления зависимостями в obj-c нет как такового вообще. Библиотеки присоединяются к проекту либо в уже откомпилированном виде, либо в виде сорцовых файлов. И то и другое нужно держать в репозитории. Для особо продвинутых есть git submodules. Вообще, у меня такое ощущение, что использование любых сторонних библиотек не очень поощряется самим Apple и какой-то частью community. Мне же после java/scala/ruby/python-дева писательство велосипедов кажется уже такой явной глупостью, что это даже не требует каких-то объяснений. Немного порывшись в интернетах, я обнаружил несколько инструментов для управления проектами. Из них самым внятным и стабильными выглядит CocoaPods, очень похожий на рубёвый bundler. Его я тоже собираюсь попробовать, как только будет возможность.

Заключение

Этот пост я писал очень уж долго и решил, что рискую оставить его пылиться на ноутбуке вечно. Так что, пожалуй, буду закругляться, несмотря на то что были ещё какие-то мысли и замечания. Может, когда-нибудь ещё наберётся каких-то вещей на ещё один пост. Так, например, полезный опыт приделывания xcode и консольных утилит к Jenkins и настройка непрерывного деплоя через TestFlight вполне потянет на таковой, если дойдут руки. Пока же всем спасибо за внимание и удачно провести праздники :)