Компания
185,43
рейтинг
12 ноября 2015 в 13:50

Разработка → AppCode 3.3: Xcode 7, Swift 2 и планы на будущее

Привет, Хабр!

Давно мы не публиковали новостей про AppCode, пора это исправить. К тому же у нас есть отличный повод — 2 ноября вышла новая версия нашей IDE для iOS/OS X.



Если в AppCode 3.2 мы упорно работали над “умными” возможностями для Swift (и многое успели реализовать), то в версии 3.3 все силы были брошены на поддержку новых языковых конструкций Swift 2.0 и Objective-C, анонсированных Apple в июне.

Поддержка Xcode


В конце августа мы пообещали, что постараемся как можно скорее реализовать поддержку Xcode 7 в AppCode. Часть необходимых изменений мы внесли в первой же EAP-версии, и продолжали работать над этой задачей в течение всей программы раннего доступа. Новый AppCode 3.3 официально совместим с Xcode 7/7.1, а вот поддержку Xcode 6.x на OS X 10.11 нам пришлось прекратить (почему — можно прочитать здесь).

Objective-C


Все изменения в поддержке Objective-C относятся к нововведениям, появившимся в Xcode 7:

  • Корректно работают подсветка синтаксиса, автодополнение и Rename-рефакторинг для generic-типов



  • В парсер языка добавлена поддержка новых nullability annotations



Swift


Мы реализовали в AppCode 3.3 корректную подсветку синтаксиса и автодополнение для части конструкций Swift 2:

  • блоки do/try/catch
  • throw/throws (rethrows в пути)



  • defer
  • guard
  • repeat-while
  • indirect (для рекурсивных перечислений)



и продолжаем активно работать над остальными. Из значимых изменений, относящихся к поддержке Swift в целом, стоит упомянуть автодополнение для вложенных типов и исправленную подстановку методов классов с generic-типами в параметрах.

Отладчик Swift


Изменения в отладчике порадуют тех, кто работает с кодом на Swift. Мы улучшили отображения коллекций и типов CoreFoundation при отладке Swift-проектов.



C/C++


Среди главных изменений — поиск использований и рефакторинг переименования для параметров шаблонов (более подробно об этих и других изменениях по поддержке С++ можно прочитать в посте anastasiak2512).

Платформенные изменения


Их действительно много. Это и возможность изменений настроек форматирования на лету для конкретного куска кода, и масса улучшений для систем контроля версий, и новые возможности при поиске и замене (такие как использование регулярных выражений и предпросмотр результатов поиска). Стоит также отметить, что теперь в инсталлятор AppCode включена кастомизированная JDK с исправлениями от JetBrains (выбрать любую другую JDK, установленную в системе, можно c помощью Find Action -> Switch IDE Boot JDK).

Что дальше?


До конца года мы будем работать над улучшением поддержки Swift. На очереди evaluate expression для отладчика, расширения протоколов в Swift и многое другое. Продолжение работы над рефакторингами в Swift планируем в следующем году.

Вот, пожалуй, и всё. Как и все другие продукты JetBrains, AppCode теперь перешел на новую схему лицензирования, с ценами и условиями которой можно ознакомиться на нашем сайте. Следите за обновлениями в нашем англоязычном блоге, а прямо сейчас мы готовы ответить на любые ваши вопросы в комментариях.
Автор: @yeswolf
JetBrains
рейтинг 185,43

Комментарии (42)

  • –2
    JetBrains крутые! :)
  • 0
    Преамбула. Давным давно надоели баги и глюки XCode. Серьезно, это не IDE (редактор?), а насмешка над разработчиками. Можно даже сказать — плевок в лицо. Я недавно (год с небольшим) стал мобильным разработчиком, придя в эту клоаку из веб/системного-программирования, и был поражен размерами пропасти между Android Studio и XCode. Долго наша команда в буквальном смысле мучилась с убогостью интерфейсов рекомендованного Apple редактора: отвратительная навигация по коду, отвратительный встроенный менеджер репозитория, отвратительнейшая подсветка ошибок и полностью отсутствующий в нормальном смысле отладчик Swift кода (lldb для Swift? Не смешите. Да, научились пользоваться — куда деваться).
    Фабула. Решили обратить свое внимание на сей «продукт» Jet Brains, и каково же было удивление, когда именитый разработчик редакторов для программистов (не сарказм) подсунул нам такую свинью. Из коробки НИЧЕГО не работает кроме подсветки кода и небольшого рефакторинга (да, это плюс по отношению с ХКоде). Мало того, что отладчика (запускающегося из коробки) нам не завезли, так еще и ошибки статического анализа не показываются вообще. Итог: код написанный в AppCode просто не запускается. Открываем в «православном» XCode — куча ошибок. Правим.

    После новых приключений, команда вернулась в XCode, который уже даже стал казаться неплохим. Вообще, решение навигации по коду в XCode для себя я уже нашел. IVim. А как справляетесь с ХКодом Вы?
    • 0
      Что такое IVim?
      Справляемся с помощью плагинов, обычно. Их много и много реально улучшающих работу с IDE.
      • 0
        iVim — это плагин для Alcatraz, который привносит раскладку vim в XCode.
        • 0
          Он по-другому называется — XVim
      • –1
        если не трудно, посоветуйте ваши любимые плагины.
    • +1
      Сразу возникают вопросы:

      Из коробки НИЧЕГО не работает кроме подсветки кода и небольшого рефакторинга (да, это плюс по отношению с ХКоде).

      У вас в проекте только Swift, Objective-C или Objective-C + Swift?

      Мало того, что отладчика (запускающегося из коробки) нам не завезли, так еще и ошибки статического анализа не показываются вообще. Итог: код написанный в AppCode просто не запускается.

      Какую версию пробовали, когда скачивали?
      • 0
        В 3.2 в ObjC + Swift проекте статический анализатор был просто непригоден для использования. Несколько месяцев сидели на EAP'ах 3.3, даже они были более стабильными.
      • 0
        Swift + ObjC библиотеки. Самую свежую версию аппкода, неделю назад, или около того. Если хотите подробнее: задавайте вопросы, готов ответить с конкретикой.
        • 0
          Подробнее безусловно хотим. Поясню — отладчик Swift в версии недельной давности должен быть и должен работать. Что именно у вас происходит, почему создалось впечатление, что его нет?
          • –1
            Потому, что когда его запускаешь, он падает сразу. image
            • 0
              Есть такая проблема — пока пытаемся понять, как ее стабильно воспроизвести и исправить. Хороший кейз в том, что она как правило воспроизводится нечасто.
              Если вдруг еще раз сможете воспроизвести — то будет отлично, если напишете, как это получилось здесь
          • –1
            Прошу прощения, Skitch почему-то заблочил урлу картинки. После обновления на 3.3.1 дебаг запустился, но почему-то показывает странную ошибку, когда как в XCode их нет. image
    • +2
      >> отвратительная навигация по коду
      Что вы имеете в виду? Клавиатуру? Вы не в курсе что у XCode настраиваются все клавиши?

      >> отвратительный встроенный менеджер репозитория
      Для хобби проектов достаточно. Для работы — консоль.

      >> отвратительнейшая подсветка ошибок
      И что же в ней не так? Как по мне так весьма хорошая по сравнению со студией.

      • –4
        1. Вы что, шутите? Скажите мне как объединить две строки в XCode.

        2. Для каких хобби проектов? Что вы несете? Это инструмент для профессиональных разработчиков с прицелом на рынок, а не на хобби проекты.

        3. Я так понимаю, вы не работали в Android Studio. Вы что, раньше в «блакноте код песали»?
        • 0
          Я лучше xcode для разработки софта под osx/ios ничего не видел. У вас руки не из того места растут, вот и объяснение всех ваших бед. (простите не удержался).
          • –2
            Вы не ответили на мой вопрос. Повторю его — как объединить две строки в XCode?

            >> Я лучше xcode для разработки софта под osx/ios ничего не видел.

            Потому, что ничего и нет.
        • +2
          Воу-воу, полехче. Мы с вами не на базаре

          1. end-of-line, delete
          2. не устраивает IDE — используйте xcode command line tools
          3. нет, я не в «блакноте пейсал», а обычно пишу в Vim

          Я увидел ваш коммент примерно так:
          «отвратительная
          отвратительный
          отвратительнейшая
          полностью отсутствующий в нормальном смысле
          НИЧЕГО не работает
          нам не завезли
          не показываются вообще
          не запускается»

          А мне норм (и куче других людей)
    • +3
      Единственный баг XCode который я встречаю — это иногда отваливается коннект к эмулятору. В остальном, нет никаких проблем. Проекты от хоббийных до коммерческих, разрабатывающихся по несколько лет.
      Что я делаю не так? :)

      Да, после XCode наоборот Android Studio кажется несколько хм… непривычным. Редактирование ресурсов например, ужас-ужас, хотя привыкнуть можно.
      • +1
        Добавлю, многие фичи в XCode действительно неочевидны, и о них интуитивно не догадаться.

        Посмотрите WWDC-конференции где рассказывается о возможностях XCode, будете приятно удивлены. Там реально много всего.
        • –2
          Похоже, вы не требовательны. Мне хватило однажды переименованного View в коде, чтобы потом искать полчаса, откуда вываливаются ошибки. Оказалось, что нужно еще руками лезть в сториборд и там искать связку с View, удалить ее, и снова навесить. Вот несколько секунд назад вдруг понял, что в эмуляторе нельзя выключить интернет чтобы протестировать его отсутствие. Ах да, и еще эти великолепные ошибки 0x????? (подобного рода), выпадающие на довольно безобидные огрехи. А еще, я заметил, что апологеты Кода почему-то, выскакивают в комментариях, пишут — Всё ок. Кидают минус и заскакивают. Никто так и не привел доводов удобства. Обычно цепляют последнюю фразу, цитируют ее, и пишут — Это же не так!
          • +2
            Мне хватило однажды переименованного View в коде, чтобы потом искать полчаса, откуда вываливаются ошибки


            Кликаем на класс, Refactor -> Rename, XCode покажет зависимости, в том числе и в Storyboard. Для objective-c работает.

            Отладка — можно вывести значение любой переменной, набрав в консоли po 'name', выручает иногда, при желании для сложных структур можно функцию description переопределить, да обычно и стандартной хватает.
            Посмотрите до кучи, к примеру: developer.apple.com/videos/play/wwdc2015-104

            Если говорить об Android Studio, то редактирование ресурсов у XCode имхо в разы удобнее. Простой пример, если я создаю в Android Studio ListView c custom cells, сами ячейки я должен в отдельные xml положить. Такое было в XCode года 3 назад (все по разным XIB) и от этого отказались, сейчас гораздо удобнее — в Storyboard внутри макета таблицы все ячейки лежат.
            Даже иконку приложения в XCode куда удобнее редактировать, чем искать в Android Studio по куче папок xdpi, xxdpi и пр.

            А уж про симулятор я вообще молчу — сколько времени в Android Studio симулятор запускается? Это же абсолютно жуткий тормоз. Ему по-моему Core i7 нужен для нормальной работы. Только Genymotion и спасает, но то что «корпорация добра» вместе со своими программистами-олимпиадниками-переворачивателями_гномиков не могут даже нормальный симулятор сделать, реально удивляет.

            как объединить две строки в XCode?


            Что вы имеете в виду, я не понял вопроса.
            • –1
              >> Кликаем на класс, Refactor -> Rename, XCode покажет зависимости, в том числе и в Storyboard. Для objective-c работает.

              К сожалению, работаем на Swift.

              Про Custom Cells — работать мышкой при билде интерфейсов по определению неудобно. Вы пробовали работать в Dreamweaver (это же ад моего 2007го)? Верстать кодом гораздо удобнее и наглядней. И в этом плане xml Android Studio просто божественная манна, по сравнению с «этимивашими» сторибордами. Все прозрачно, понятно, и мерджить удобно (sic!).

              Про эмулятор андроида стоит сказать только одно — Genymotion. Дальше сравнивать нет смысла, ибо женя затыкает всех за пояс раз пятнадцать. А жаловаться на стандартный? Ну, что ж, да — я сам жаловался на него, пока не перешел на Genymotion.

              Эмм… сделайть «джойн лайнов». В vim — клавиша shift+j. Удалить перевод строки командой. Даже не знаю как объяснить, это умеют все редакторы, начиная от Notepad++.
              • +1
                Верстать интерфейсы вручную — для веб-программистов наверное привычнее, да :)
                Но если нужно сделать красивый дизайн (а особенно если есть ТЗ от дизайнера и надо сделать точно так же, с кучей слоев, прозрачностей, всяких украшательств), мышкой имхо в разы удобнее и нагляднее. Сложный интерфейс гораздо быстрее накидать визуально, WYSIWYG, однако :) Да и при нормально расставленных constrains все будет работать практически на любых девайсах без допиливания.

                Вот с мерджем согласен, проблемы могут быть. Со storyboard в этом плане все отлично — кроме командной работы, тогда все равно придется использовать несколько storyboard в проекте.

                Многие вещи в XCode делаются только мышкой (например связывание переменных IBOutlet или настройки объектов в Coredata model), после редактирования «в notepad» это может быть непривычно, да. Меня тоже не всегда эта тенденция радует, а что делать, мир неидеален.

                shift+j не пробовал :)

                Swift отдельная тема, тоже пришлось перейти, хотя и ObjectiveC всем устраивал.

                PS: Еще раз советую пересмотреть все видео по XCode в WWDC за последние 2-3 года, много интересного найдете.
                • –2
                  Я смотрел каждый WWDC как раз-таки последние 2-3 года. Не помню чего-то стоящего, кроме объявления, что теперь можно тестировать (слава Богу) на личных устройствах без аккаунта разраба. За два года, за ДВА, ребята из Купертино не смогли сделать нормальную поддержку Swift на уровне IDE своей. Конечно, смысла ныть нет, ведь альтернативы не предвидится. И вроде бы даже как-то привыкли к постоянным крашам, подвисаниям и lldb. Но это же не Эпл-вей, не правда ли? Я сам апологет продукции этой компании. Но от XCode я был в шоке, когда начал разрабатывать.
                  • +1
                    Я вообще не в восторге от Swift и с удовольствием бы подождал 2-3 года пока все утрясется с их изменениями. ObjectiveC меня полностью устраивал. Увы, рынок диктует свои условия, приходится переходить :)
                • 0
                  Расставлять ничего не надо, на нужной view или нужном custom cell
                  All View -> Add missing constraints

                  и Xcode сам всё расставит
            • –1
              UPD: И конечно же, как я мог забыть про знаменитые «распорки», для выравнивания двух-трех инлайновых элементов в Interface Builder. Те, что ушли в небытье в последнем релизе ХКода, где добавили StackView. А LinearLayout радовал нас с давних пор. Если вы понимаете о чем я.
              • +1
                А передвинуть контрол в другое место диалога в RelativeLayout, предлагаете вручную все зависимости в xml переписывать? С constraints все же в разы удобнее, 3-4 клика и все дела.

                LinearLayout был с самого начала, это да, когда появился StackView, я тоже про него вспомнил :)
      • 0
        Та же история с android studio, после xcode студия кажется очень неэффективной
        • 0
          Каждый божий день, XCode падает и глючит. Вот окно, к которому я уже привык даже.image
          • 0
            За год разработки на swift (начиная с первой беты) раньше видел такое окно пару раз в месяц, не сказал бы что оно мешало, кнопка открыть снова — и работа продолжается с того же места. После миграции на swift2 не видел такого окна

            Но если у вас до сих пор каждый день — то тут явно что-то не то
            • 0
              Вот сейчас раз пять подряд упал, при создании IBOutlet. Может дело в том, что по стечению обстоятельств на работе у меня стоит хакинтош?
    • 0
      Пробовал писать Swift в AppCode полгода назад, и был разочарован зачаточной поддержкой. Но дело то не в JetBrains, а то что сам Swift тогда только внезапно вышел в свет. А вот для старого доброго ObjectiveC еще тогда поддержка была просто божественна.
  • +1
    Вопрос к Jetbrains: в чем киллер-фичи вашего продукта, если меня и XCode устраивает?

    Использовать сторонний продукт который заведомо отстает от нововведений Apple, при том что еще и 89$ заплатить надо? За что?
  • +1
    Резонный вопрос. Попробую кратко пояснить на примерах, по личному опыту — приходилось программировать под разные платформы, в том числе достаточно много под iOS. Есть одна существенная особенность в мобильной разработке — ты всегда зависишь от того, кто делает мобильную платформу и обычно — перестраховываясь — всегда используешь ту IDE, которая считается официальной для конкретной платформы. Альтернативных вариантов обычно нет, поэтому к особенностям той или иной IDE приходится привыкать, а менять потом привычки — сложно.

    Например, при разработке под iOS вырабатывается стойкая привычка ко вполне определенному типу автодополнения кода — «набери начало того, что хочешь подставить». В случае какого-нибудь UITableViewCellStyleValue2 — придется набирать почти до конца, а у нас можно просто использовать camel humps и набрать UITVCSV2 (или в нижнем регистре, если в настройках отключить case-sensitive). То же самое с middle matching.

    Импорты. Хочешь использовать конкретный класс — сначала пропиши импорт, всегда. Рутина? Да, рутина, но к ней привыкаешь. А у нас можно просто прописать название класса, увидеть подсказку и добавить нужный импорт по Alt+Enter. Так же привыкаешь к тому, что код в среднем или крупном проекте никогда не будет очищен от неиспользуемых импортов, потому что нет времени, есть более серьезные задачи итп. А главное — потому что если это нужно сделать, то придется это делать руками. В AppCode для этого достаточно выбрать одну операцию в меню — и все.

    Поиск использований. Берем какой-нибудь ReactiveCocoa и пробуем найти в нем все использования какого-нибудь метода, например, map из RacStream (пример взят с потолка, просто проект под рукой). И хотим мы найти использования только метода, а не всех текстовых вхождений. У нас это можно сделать просто выделив map и нажав Alt+F7. И для этого не нужно никуда переходить.

    Контроль версий. Не берем работу с VCS в командной строке — что делать, если хочется работать с ним через UI? Большинство знакомых iOS-программистов просто по дефолту ставят что-нибудь вроде SourceTree. А большинство знакомых Android-программистов, использующих Android Studio — не ставят, потому что встроенного в IDEA-based продукты функционала по контролю версий вполне достаточно. То же самое относится и к AppCode.

    Debugger. У нас есть Inline view — и это в ряде случаев удобнее.

    Рефакторинги. Здесь я пожалуй, все-таки просто вставлю скриншот
    image.

    Это если коротко — более подробно я думаю можно только в отдельной статье. Или нескольких. И я думаю, мы их скоро напишем.

    P.S. Случайно запостил не туда, это был ответ на предыдущий комментарий.
    • –1
      Странно, что эпл совсем не форсит Свифт. Вроде бы их детище, а поддержка его в Коде — постольку-поскольку. А ведь если верить ребятам из Купертино — за Свифтом будущее iOS.
    • 0
      Поддержка контроля версий в IDE от JetBrains и правда божественная. Мечтаю, чтобы вы когда-нибудь выпустили отдельный продукт, где можно будет просто открыть папку с произвольным репозиторием git и ковыряться в ее истории при помощи ваших инструментов. Без парсинга проекта, без крутых рефакторингов, создания проектных файлов и прочих не самых быстрых вещей — просто подсветка кода для разных языков, шорткаты и контроль версий. Не IDE, а гит-блокнот. Понятно, что это все в IDEA делается, но бывает, что открываешь проект с каким-нибудь андроидом, с которым обычно не работаешь, чтобы что-то поправить в ресурсах или конфигах, а проект тебе выдает тучу ошибок, создает кучу проектных файлов и т.д., что несколько неудобно. Или в текущем проекте ребейз какой-то сложный, который всю структуру проекта убивает и показывает ошибки. Знаешь, что это будет, хотел бы заранее в такой блокнот переключиться и смержить там, но такого инструмента нет.

      Ну и для меня еще одна киллер-фича — привычка. Много лет использовал IDEA для джавы и питона, полгода юзал CLion для C++ (спасибо за него огромное), потом пришлось заниматься iOS-разработкой, и без AppCode был бы как без рук. Поиск, навигация, рефакторинги, шорткаты, вот это все в Xcode как-то не очень. Можно и там это все освоить и допилить, но зачем.

      Правда в AppCode и минусы есть. Во-первых, видно, что вам сложно гнаться за Apple с их скоростью разработки. Понятно, что вряд ли стоит ожидать, что вы будете выкатывать обновления в тот же день, что и Apple, но конечно хочется хотя бы большей стабильности. Во-вторых, может это я не там ищу, но в AppCode я не вижу некоторых шорткатов, которые были в Linux, приходится периодически тыкать в мышку. Исходный код сториборда не открывается никак, кроме как диффом, перебрасывает в Xcode сразу. Ну и вообще немного складывается впечатление, что та же IDEA — гораздо более вылизанный продукт. Понятно, что этому есть причины. Надеюсь, новая политика лицензирования поможет вам с улучшением качества продукта.
    • 0
      1) FuzzyAutocomplete
      2) Auto-Importer / Peckham
      3) Уже есть в Xcode
      4) Всегда есть что-то лучше, но для базовых вещей встроенный клиент достаточен (но не без глюков, да)
      5) «В ряде».
      6) Не буду спорить =)
      7) Вы забыли интеграцию с Reveal упомянуть, инспектор view у Xcode отстает пока от Reveal.
      • 0
        Получается бой двух IDE, а у меня нет такой задачи. Но ок )

        1) FuzzyAutocomplete

        А у нас еще Smart Completion, и все «из коробки»

        2) Auto-Importer / Peckham

        Ну ок, optimize imports все-таки только у нас )

        3) Уже есть в Xcode

        А у нас сразу же можно увидеть в отдельном окне, как именно используется символ, который ищем и поиск можно стартовать шорткатом без пассов мышью. А это быстрее.

        На самом деле нет, дальше я не буду сравнивать, контекст этого треда не верен. Дело не в том, чем мы лучше Xcode — ибо мы с ним не воюем. Дело в том, чем мы хороши для программирования под iOS. А это правда, тема для отдельной статьи.

        А кстати, была бы такая статья интересна тут, на хабре?
        • 0
          Конечно.
        • 0
          Да.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка