AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое

Зачем все эти фичи, если среда зависает намертво и ресурсы жрет хуже хрома!
Серьёзно… Просто попытался воспроизвести первую гифку — и аппкод зависает намертво.

а так задумка, конечно же, хорошая…

del

Спасибо, пользуюсь 2019.1, но мне кажется 2018 версия была шустрее. После следующих изменений стало, вроде, лучше:
1. Добавил некоторые JVM флаги ( stackoverflow.com/questions/5651538/speedup-intellij-idea). После настроек сделал max 2Gb и min 1Gb и это оказалось лучше чем я когда выставлял max 7Gb, все равно AppCode всегда показывает использование памяти ок 800Мб.
2. Комплишен оооочень медленный, в итоге убрал галочки на smart и base completion, мне важно чтобы комплит появлялся, то что он мне помогал бы не совсем важно, иначе с этими галочками приходится по 5 — 10 секунд ждать первые подсказки, а без них всего пару секунд. Еще есть хак, если нужно вызвать метод или переменную из локального скоупа (class/struct/etc) то нужно всегда писать self. тогда видимо отсекаются глобальные области поиска и комплит почти сразу работает. Для глобальных функций/переменных как долго работал так и работает, проще дописать руками или открыть Xcode и там написать и потом обратно переключиться.

Буквально на днях заметил странную штуку, сборка в AppCode намного дольше чем на Xcode. Тесты проводились следующим образом.
Xcode:
1. Закрыл Xcode
2. Почистил DerivedData (Library/.../Xcode/DerivedData)
3. Открыл Xcode и сразу нажал запустить проект на симуляторе (то есть полная сборка + запуск)
Время на всё ушло 3:50-4:00 минуты в Xcode

AppCode, тоже самое, только чистил его DerivedData (../Caches/../AppCode 2019/../DerivedData/) и AppCode мне выдавал больше 5 минут (нажимал на жука чтобы включить отладку я так понимаю).

Еще мне очень сильно не нравится в 2019 после 2018 версии, что довольно часто после изменения кода (например изменить имя приватной функции, добавить дополнительный параметр в функцию) всё перестает работать секунд на 10-20, то есть IDE UI не блокирован, но если попробовать посмотреть описание любой переменной или функции в классе (да хочь чего) через cmd+touchpad то ничего не показывает, если нажать на любой (тут я подчеркиваю, что работа с другой нетронутой функцией, а не которая была переименована) вызов функции то не переходит в ее дефенишен и более того эта функция даже не подсвечивается (что по ней можно перейти).

Еще замечаю (любая версия IDE), что бывают выражения, которые программа с другом вывозит. Вот например внутри функции был код

let obj1 // CoreData объект из другого модуля
let obj2 // еще CoreData объект из другого модуля
let ratio = 100 * obj1.price1 / obj2.price2

вот после того как написал знак деления сразу стали видны лаги UI причем постоянные толи пока курсор не убрал с этой линии, толи пока выражение не дописал, но суть в том, что после знака деления комплит наотрез отказался работать (ну или ждать минуту надо). Подобное поведение встречается в сложных выражениях и автокомплит работает после полуминуты ожидания. Ужас.

Очень плохо резолвится chaining, прям проблема

guard let obj = object?.array.first?.innerObject?.someFireld else { return }

Тут всегда даже подсветка не работает, я уже не говорю, что не может вывести тип. Такое часто когда тип объекта object из другого модуля.

2019 версия стала подсвечивать больше кода, конечно есть участки где IDE не может понять, но их стало меньше — за это спасибо.

Уже не помню, но вроде компишен дженериков тоже очень плохо работает

class A {
    private let relay = RxSwift.BehaviorRelay</* с этого места комплит не работает */User?>(value: nil)
}

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

и компиляция с необновленными подами заканчивается не очень информативно

Error:Build failed with 0 errors

А можно, в двух словах для начинающих, чем это от XCode отличается?..
Ибо на офф сайте я такой информации не вижу (

Спасибо большое. Последний релиз отличный.

Скажите пожалуйста, в чем основная проблема такого скромного наборы рефакторингов в AppCode. Это касается как разницы между кол-вом в Swift относительно Objective-C так в целом между AppCode и ReSharper например. Перешел с .NET на iOS, думал, что достаточно будет просто сидеть в праильной IDE, но половину (как минимум) рефакторингов просто нет и это печалит. Если вдруг нужны примеры, то приведу парочку (прошу прощения за русский, не помню точный названий): сделать локальную переменную аргументом метода, extract Interface/Superclass. Какие вообще у JetBrains планы относительно рефакторинга в AppCode? Просто не хватает рук или ждёте стабилизации Swift?
Еще очень хотелось бы иметь фичу как в ReSharper (наверное есть и в IntelliJ IDEA) — отформатировать весь файл хотя бы в таком виде: отступы + группировка методов по области видимости + сортировка импортов. Понимаю, что теоретически можно это самому написать, поэтому был бы рад ссылочкам с чего начать)
Заранее спасибо!
P.S. Как мне кажется, основные аспекты хорошей IDE для большинства разработчику — UI без фризов, быстрый autocomplete, побольше рефакторингов, ну и всё в целом).

Это касается как разницы между кол-вом в Swift относительно Objective-C так в целом между AppCode и ReSharper например.

Ну, если коротко, то рук не хватает и мы постоянно ищем разработчиков. К слову, их количество неуклонно растет.

Если более подробно, то нельзя сравнивать Swift и какой-либо другой язык. Для начала, не существует просто Swift. Есть связка Swift + Objective-C/C++, mixed code. Либо это библиотеки, либо еще крайне многое. В итоге мы тут решаем задачу, которую ни один другой продукт JetBrains не решает — делаем кроссязыковое взаимодействие не в виде приятного бонуса, а как часть функциональности, без которой IDE просто бесполезна. Любой C-подобный язык сразу же вызывает рост сложности реализации любой фичи, потому что нельзя так просто взять и распарсить код с текстовыми подстановками в виде #define. То есть на самом деле — это крайне непростая задача, и делать ее крайне долго, когда речь идет о рефакторингах, работающих в контексте всего проекта. С локальными проще, и их мы понемногу реализуем.

Идем дальше. Раз в год выходит Xcode. Выход Xcode — это сразу же поддержка изменений в нем, о которых не знает никто. Поэтому часть времени всегда уходит на это. Допустим, с Xcode 8 пару раз сменился формат, в котором хранится документация кода. Один раз полностью изменился, большой кусок пришлось переписывать, а казалось бы, просто документацию отобразить. Тот же ReSharper работает с API плагинов, там ситуация, по-моему более предсказуема.

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

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

Ну и с фичами если смотреть, тут всегда приходится выбирать. Вот есть Code Coverage, который мы точно можем сделать хорошо. Его используют вообще все. Важнее ли он, допустим, Inline-рефакторинга? С точки зрения пользователей — важнее, это четко видно по трекеру.

Понимаю, что теоретически можно это самому написать, поэтому был бы рад ссылочкам с чего начать)

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