Говорят — говорят — им не хватает только command-line интерфейса, в который можно прокинуть лицензионный ключ, чтобы быть интегрированными в AppCode примерно так же, как они интегрировались в Xcode.
Менюшку, пункты меню легко можно сделать через External tools, потом повесить нужные шорткаты, никаких плагинов не надо даже.
У меня ощущение, что JetBrains впиливая поддержку Swift выпиливает поддержку Objective-C, но при этом и за Swift не успевает.
Регрессии есть, связка Objective-C/Swift достаточно плотная и часто меняется. Здесь сильно бы помог тестовый проект с описанными проблемами, по вашему описанию дать какую-либо конкретику сложно.
И мне интересно, почему JetBrains не тестирует свой продукт на совместимость с beta-версиями Xcode? Ставлю самый свежий AppCode, а он мне говорит «переключитесь на Xcode 8.1», хотя 8.2 в бете был доступен очень-очень давно, а сейчас даже 8.2.1 уже вышел.
Тестирует. Только работоспособность чего-либо в бета-версии не дает никакой гарантии того, что то же самое будет работать в релизе. Поэтому пока не будет проверено, что ничего не отломалось — предупреждение остается.
Предупреждение в IDE есть потому, что мы интегрируемся с некоторыми частями Xcode, и изменения в них предсказать невозможно. Поэтому в каждом случае требуется время на проверку — его пока уменьшить, увы, не получается. Как только мы уверены, что проверили совместимость, мы отключаем предупреждение, обычно стараемся сделать это в процессе текущего EAP, либо выпустить минорным апдейтом.
Можете проверить, включено ли оно для того языка, на котором смотрите в Preferences -> Editor -> Colors and Fonts -> ? От версии macOS не должно зависеть.
Такие вещи — если они действительно нужны сообществу разработчиков — обычно создаются сообществом разработчиков. Я помню одни и те же вопросы к построению интерфейсов в Xcode еще начиная с версии 2.x, но альтернативы, которая действительно широко используется при разработке нативных приложений так и не появилось. Думаю, никому это просто не нужно.
И не все ошибки показывает, например, с теми же var/let и Optional variable.
Здесь было полезно уточнить версию и если возможно — дать пример проблемного кода (можно в личные сообщения). Идеальный вариант — тестовый проект.
Для редактирования Storyboard пока без Xcode никуда.
Вы правы, и я почти уверен, что причины для вас очевидны. Но вопрос возникает достаточно часто, поэтому я чуть расширю ответ и все-таки напишу о причинах. Важность редактирования интерфейсов для нас полностью понятна, но сама сложность задачи такова, что пока мы не готовы тратить на нее время — его потребуется слишком много даже для того, чтобы просто воспроизвести текущую функциональность. Нормальной спецификации форматов интерфейсных файлов — нет, какого-то внешнего API — тоже, плюс частые изменения. Почти то же самое с редактированием многих других проприетарных форматов файлов в Xcode без спецификаций.
Про замену Xcode. Для нас идеальным вариантом была бы полная концентрация на работе с кодом и над возможностями, которые относятся именно к этой сфере, но пока так сделать нельзя. Отчасти поэтому AppCode существует именно в виде отдельной IDE, но при этом мы его позиционируем как дополнение к Xcode, т.к. некоторые части (тот же xcodebuild, не говоря уже о симуляторах) нам необходимо переиспользовать и мы не будем пытаться их переписать.
Частично поможет Preferences -> Editor -> Code Style -> Swift -> Wrapping and braces -> Method call arguments -> Align when multiline, но сделать indent для аргументов с помощью этой опции не получится. Вообще, для форматтера Swift пока есть достаточно много нереализованного и в ближайшее время мы этими задачами с большой вероятностью заняться не сможем.
Менюшку, пункты меню легко можно сделать через External tools, потом повесить нужные шорткаты, никаких плагинов не надо даже.
Регрессии есть, связка Objective-C/Swift достаточно плотная и часто меняется. Здесь сильно бы помог тестовый проект с описанными проблемами, по вашему описанию дать какую-либо конкретику сложно.
Тестирует. Только работоспособность чего-либо в бета-версии не дает никакой гарантии того, что то же самое будет работать в релизе. Поэтому пока не будет проверено, что ничего не отломалось — предупреждение остается.
Здесь было полезно уточнить версию и если возможно — дать пример проблемного кода (можно в личные сообщения). Идеальный вариант — тестовый проект.
Вы правы, и я почти уверен, что причины для вас очевидны. Но вопрос возникает достаточно часто, поэтому я чуть расширю ответ и все-таки напишу о причинах. Важность редактирования интерфейсов для нас полностью понятна, но сама сложность задачи такова, что пока мы не готовы тратить на нее время — его потребуется слишком много даже для того, чтобы просто воспроизвести текущую функциональность. Нормальной спецификации форматов интерфейсных файлов — нет, какого-то внешнего API — тоже, плюс частые изменения. Почти то же самое с редактированием многих других проприетарных форматов файлов в Xcode без спецификаций.
Про замену Xcode. Для нас идеальным вариантом была бы полная концентрация на работе с кодом и над возможностями, которые относятся именно к этой сфере, но пока так сделать нельзя. Отчасти поэтому AppCode существует именно в виде отдельной IDE, но при этом мы его позиционируем как дополнение к Xcode, т.к. некоторые части (тот же xcodebuild, не говоря уже о симуляторах) нам необходимо переиспользовать и мы не будем пытаться их переписать.