Есть ли в планах вынести проверки IDE в инспектор?
Например поддержка атрибутов, или же просто их эволюцию с «availability» -> «available», или же "_versioned" -> «usableFromInline» и "_inlineable" -> «inlinable»
Это парсерная ошибка, планов выносить парсерные ошибки в настройки с возможностью их отключения нет. Слишком сложно, слишком много времени, в целом — порочная практика, потому что проблемы начнут замалчиваться, а не решаться в итоге. Плюс частые изменения версии Swift.
Сейчас подобные изменений аттрибутов мы поддерживаем в зависимости от версии. Как только реализуем в очередном апдейте — начнут корректно обрабатываться как старые, так и новые в зависимости от версии Swift. Конкретно по этим — уже сделано, но пока еще не появилось в обновлениях.
И второй вопрос — будут ли расширяться возможности Code Style
В следующей версии скорее всего нет, но это не значит, что если задача окажется простой и на нее не появится времени, она не будет сделана по ходу. Заводите тикет, пусть ребята посмотрят, если окажется просто — сделают.
Но вот что в одном из будущих релизов мы к форматированию обязательно вернемся, в очередной раз серьезно его доработав — это точно, там еще много хорошего можно сделать.
Говорят — говорят — им не хватает только 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, не говоря уже о симуляторах) нам необходимо переиспользовать и мы не будем пытаться их переписать.
Это парсерная ошибка, планов выносить парсерные ошибки в настройки с возможностью их отключения нет. Слишком сложно, слишком много времени, в целом — порочная практика, потому что проблемы начнут замалчиваться, а не решаться в итоге. Плюс частые изменения версии Swift.
Сейчас подобные изменений аттрибутов мы поддерживаем в зависимости от версии. Как только реализуем в очередном апдейте — начнут корректно обрабатываться как старые, так и новые в зависимости от версии Swift. Конкретно по этим — уже сделано, но пока еще не появилось в обновлениях.
В следующей версии скорее всего нет, но это не значит, что если задача окажется простой и на нее не появится времени, она не будет сделана по ходу. Заводите тикет, пусть ребята посмотрят, если окажется просто — сделают.
Но вот что в одном из будущих релизов мы к форматированию обязательно вернемся, в очередной раз серьезно его доработав — это точно, там еще много хорошего можно сделать.
Скачайте File Watchers плагин, настройте там clang-format и будет он срабатывать на сохранение.
Менюшку, пункты меню легко можно сделать через External tools, потом повесить нужные шорткаты, никаких плагинов не надо даже.
Регрессии есть, связка Objective-C/Swift достаточно плотная и часто меняется. Здесь сильно бы помог тестовый проект с описанными проблемами, по вашему описанию дать какую-либо конкретику сложно.
Тестирует. Только работоспособность чего-либо в бета-версии не дает никакой гарантии того, что то же самое будет работать в релизе. Поэтому пока не будет проверено, что ничего не отломалось — предупреждение остается.
Здесь было полезно уточнить версию и если возможно — дать пример проблемного кода (можно в личные сообщения). Идеальный вариант — тестовый проект.
Вы правы, и я почти уверен, что причины для вас очевидны. Но вопрос возникает достаточно часто, поэтому я чуть расширю ответ и все-таки напишу о причинах. Важность редактирования интерфейсов для нас полностью понятна, но сама сложность задачи такова, что пока мы не готовы тратить на нее время — его потребуется слишком много даже для того, чтобы просто воспроизвести текущую функциональность. Нормальной спецификации форматов интерфейсных файлов — нет, какого-то внешнего API — тоже, плюс частые изменения. Почти то же самое с редактированием многих других проприетарных форматов файлов в Xcode без спецификаций.
Про замену Xcode. Для нас идеальным вариантом была бы полная концентрация на работе с кодом и над возможностями, которые относятся именно к этой сфере, но пока так сделать нельзя. Отчасти поэтому AppCode существует именно в виде отдельной IDE, но при этом мы его позиционируем как дополнение к Xcode, т.к. некоторые части (тот же xcodebuild, не говоря уже о симуляторах) нам необходимо переиспользовать и мы не будем пытаться их переписать.