Install AppCode

AppCode is an IDE for iOS/macOS developers, based on the IntelliJ IDEA platform.

System requirements

AppCode is available on macOS only since it cannot run without Xcode.

macOS 10.15.2 or later

Pre-release versions are not supported.

Requirement	Minimum	Recommended
RAM	2 GB of free RAM	8 GB of total system RAM
CPU	Any modern CPU	Multi-core CPU. AppCode supports multithreading for different operations and processes making it faster the more CPU cores it can use.
Disk space	2.5 GB and another 1 GB for caches	SSD drive with at least 5 GB of free space
Monitor resolution	1024×768	1920×1080
Operating system	Latest version of macOS
Xcode	11.7	12.4

You do not need to install Java to run AppCode, because JetBrains Runtime is bundled with the IDE (based on JRE 11).

Install using the Toolbox App

The JetBrains Toolbox App is the recommended tool to install JetBrains products. Use it to install and manage different products or several versions of the same product, including Early Access Program (EAP) releases, update and roll back when necessary, and easily remove any tool. The Toolbox App maintains a list of all your projects to quickly open any project in the right IDE and version.

Install the Toolbox App

Download the disk image .dmg from the Toolbox App web page.

Mount the image and drag the JetBrains Toolbox app to the Applications folder.

After you run the Toolbox App, click its icon in the main menu and select which product and version you want to install.

Log in to your JetBrains Account from the Toolbox App and it will automatically activate the available licenses for any IDE that you install.

Standalone installation

Install AppCode manually to manage the location of every instance and all the configuration files. For example, if you have a policy that requires specific install locations.

Mount the image and drag the AppCode app to the Applications folder.

When you run AppCode for the first time, some steps are required to complete the installation, customize your instance, and start working with the IDE.

JetBrains AppCode 2019.2.1 — скачать бесплатно с ключом

Перед вами Smart IDE для работы в iOS и macOS. Программа AppCode отлично понимает структуру кода и умеет работать с ним максимально быстро, грамотно, комфортно, таким образом избавляя конечного пользователя от длительных настроек и изучения инструкций.

Эффективная навигация по проектам.
В любой момент, когда вы используете какой-либо файл, класс или символ в своем проекте, используйте иерархические и структурные представления, что позволит максимально быстро перемещаться по проекту в любую его область и получать нужный элемент буквально сразу после того как вы подумали о нем.

Умное автозавершение
Программа AppCode предлагает два вида завершения кода: базовое завершение по типу вашего приложения и более совершенное завершение SmartType для более точной фильтрации предложений.

Надежные рефакторинги
Модифицируйте и улучшите свой код в любое время с помощью надежных, точных и отличных рефакторингов.

Тщательный анализ кода
Софт постоянно контролирует вводимый вами код. Он предупреждает вас об ошибках и запинках и предлагает быстрые исправления для их автоматического решения. AppCode обеспечивает более 60 проверок кода только для Objective-C, C и C ++ и нескольких проверок кода для других поддерживаемых языков. Все проверки кода выполняются «на лету».

Огромный опыт
AppCode совместим на 100% и Xcode без дополнительной настройки и без проблем интегрируется с CocoaPods, Reveal application, большинством популярных систем управления версиями и множеством трекеров.

Лицензия: ShareWare — у нас вы можете скачать бесплатно
Язык: English — Русская версия и Русификатор отсутствуют
Размер: 505 MB
ОС: macOS 10.12+
Версия: 2019.2.1
Скачать: JetBrains AppCode последняя версия на ПК с ключом/кряком

[/not-group]

—>

AppCode для Windows

Установка windows 7 (для сборщика систем) второй системой с windows 8.1 для одного языка
Здравствуйте, имеется ноут (Alienware A14) с предустановленной Win 8.1 для одного языка 64-bit, а.

Хочу сделать программу невидимой для Windows XP или Windows 2000 или Windows NT
Ya hochu sdelat` programu nevidimuyu na Windows XP ili Windows 2000 ili Windows NT Nashel funkciu.

Ключ для Windows 10 Enterprise подойдет для Windows 10 Enterprise N 2016 LTSB ?
Собственно сабж, качнул себе винду Windows 10 Enterprise N 2016 LTSB, хочу теперь купить ключ на.

Заказываю контрольные, курсовые, дипломные и любые другие студенческие работы здесь или здесь.

Может ли обладатель Windows Phone претендовать на лицензионную Windows для компьютера?
Всем привет в общем я обладатель телефона Nokia Lumia 920. 2 года назад я покупал его за 20тыс.

Поставить windows 7×64 на ноутбук с windows 8, но сохранить разделы для восстановления?
Такая вот ситуация — на ноутбуке стоит восьмерка, но мне нужно поставить 7 но при этом сохранить.

При установке Windows 7 на Windows ХР запрашивает драйвера для raid controllers
помогите люди добрые чайнику поставить windows7 на windowsxp при установке запрашивает какие то.

Создает ли Windows папку Windows.old также и для своих регулярных обновлений?
До сих пор считал (так пишут :)), что папка Windows.old создается при смене версии ОС на Windows 10.

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

Неделю назад мы выпустили AppCode 2019.1 — поговорим об изменениях в нем. Под катом куча нового, полезного, исправленного и дополненного.

Swift

Swift 5

Все новые возможности Swift 5 корректно работают в AppCode 2019.1:

• SE-0200 Raw text literals
• SE-0213 Literal initialization via coercion
• SE-0216 Dynamic callables
• SE-0224 Support ‘less than’ operator in compilation conditions
• SE-0227 Identity key path
• SE-0228 Fix ExpressibleByStringInterpolation
• SE-0230 Flatten nested optionals resulting from try?

Переименование

Была проблема с переименованием перегруженных методов и методов класса-родителя — а теперь ее нет.

Навигация к определению

Казалось бы, что может быть проще и элементарнее перехода к определению метода или класса? Стандартное, привычное действие.

И все действительно так в Objective-C: название типа при инициализации объекта стоит отдельно, сам метод-инициализатор — отдельно. Соответственно, если курсор стоит на названии типа, мы переходим к определению типа, если на инициализаторе — к определению инициализатора. А вот в Swift все становится сложнее. Инициализатор слился с названием типа воедино, и, если воспроизводить поведение Xcode, теряем возможность перехода именно к инициализатору. Если же оставлять поведение AppCode 2018.3.x, ломаем привычку пользователя (“как в Xcode”, то есть переход не к определению инициализатора, а к определению типа). Это по понятным причинам не нравится пользователям.

В итоге выработали серединное решение: все-таки выражение, инициализирующее объект в Swift, по-прежнему состоит из двух частей. Все, что до круглых скобок, — название типа, а все внутри — сигнатура инициализатора. Поэтому, если курсор стоит на названии типа, переходим к определению типа, если внутри круглых скобок — к определению инициализатора:

Оба сценария использования сохранены, все счастливы.

Перемещение выражений

Пока пользователи Xcode выделяют мышкой и копипастят, пользователи AppCode ставят курсор на выражение и двигают его целиком легким нажатием ⇧⌘↑ / ↓ :

Работает для циклов, функций, методов, классов, условий, в общем, почти для всего.

Многострочные литералы

Как превратить однострочный литерал в многострочный? В AppCode теперь достаточно нажать ⏎ :

Подсветка, автодополнение, анализ кода и все-все-все

Чем корректнее мы строим дерево символов, которое используется для подсветки, анализа кода, навигации и прочих функций IDE (даже для отображения переменных в отладчике), тем лучше и правильнее будет работать AppCode. В этом релизе мы решили несколько фундаментальных проблем, которые портили жизнь пользователям:

• Мы стали строить символы библиотек и для симуляторов, и для устройств. Раньше строили только для симулятора.
• Сделав это, стали корректно определять текущую платформу (симулятор/устройство) и правильно передавать ее clang-annotator в Objective-C и SourceKit в Swift. Почему это важно? Например, SourceKit не будет отображать ошибки и предупреждения, если ему некорректно передать в аргументах папку с продуктами сборки. Эта проблема должна исчезнуть.
• Стали правильно обрабатывать DerivedSources и все исходники, сгенерированные в этой папке (Core Data, Intents).

Objective-C/C/C++

Коллеги из CLion добавили стили именования кодовых конструкций для C/C++, а мы их получили еще и для Objective-C ( Preferences | Editor | Code Style | C/C++/Objective-C | Naming Convention) :

Запуск и отладка

AppCode теперь умеет присоединяться к процессам, запущенным не только на симуляторе, но и на устройстве ( ⇧⌘A → Attach to process ):

В настройки конфигураций запуска добавлена возможность выбора языка и региона приложения:

Run to Cursor можно вызывать не только через ⌥F9 , но и нажатием на номер строки в редакторе:

Пересчет переменных при отладке теперь можно запретить с помощью действия Mute Variables в контекстном меню:

Темы для IDE

Внимательный читатель уже заметил, что все скриншоты в посте сделаны с использованием новой темы оформления Dark Purple:

Темы IDE теперь можно делать самостоятельно, поэтому в репозитории плагинов кроме нескольких тем, сделанных нами, уже можно найти несколько пользовательских вариантов оформления. А до 3-го мая можно не только сделать свою тему, но и поучаствовать в конкурсе, недавно анонсированном нами.

Список недавно просмотренных / измененных участков кода

Есть несколько полезных действий для навигации к недавно открытым или измененным местам в коде:

• Recent Files ( ⌘E )
• Switcher ( ⌃⇥ )
• Jump to Last Edit Location ( ⇧⌘⌫ )

Перемещение к последнему отредактированному участку кода вообще сложно переоценить, особенно когда редактируешь файл большого размера.

Теперь появился еще и список недавно просмотренных / измененных мест Recent Locations ( ⇧⌘E ):

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

Похожие публикации

Что нового в AppCode 2018.1

AppCode 2017.2: Extract Method и улучшения автодополнения для Swift, поддержка __auto_type в Objective-C и многое другое

AppCode 2017.1: улучшенная поддержка Swift, новые возможности кодогенерации и многое другое

Вакансии компании JetBrains

Комментарии 23

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

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

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

Вот, к сожалению, жаль, что у такого хорошего инструмента нет автоматического отслеживания подобных вещей. Всё работает, подсветка есть, индекс собран, по файлам прыгает. Но в какой-то момент при попытке перейти на определение по cmd+b — фриз полностью главного потока. И висит оно так минут 10.

Спасибо за пути возможного решения.

Спасибо, пользуюсь 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), что бывают выражения, которые программа с другом вывозит. Вот например внутри функции был код

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

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

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

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

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

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

в итоге убрал галочки на smart и base completion

Буквально на днях заметил странную штуку, сборка в AppCode намного дольше чем на Xcode.
то есть полная сборка + запуск

довольно часто после изменения кода (например изменить имя приватной функции, добавить дополнительный параметр в функцию) всё перестает работать секунд на 10-20

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

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

А вот тут бы тестовый проект, потому что крайне трудно воспроизвести то, о чем вы говорите. Если брать минимальный пример типа:

то здесь все подсвечивается. Поэтому проблема не в chaining, как таковом, а, скорее всего, в сочетании generics в ваших объектах. Понять точно было бы полезно.

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

Error:Build failed with 0 errors

Это касается как разницы между кол-вом в 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-рефакторинга? С точки зрения пользователей — важнее, это четко видно по трекеру.

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

Плохо работает движок — рефакторинг не гарантирует корректности, в итоге он никому не нужен

Речь о нашем собственном парсере и resolve engine, который является расширением модели IntelliJ. Они у нас свои, потому что SourceKit нужных нам возможностей не дает. Я вот тут достаточно подробно рассказывал, почему. Основное там — нет нормальных кэшей. Без кэшей ни одно сложное преобразование, работающее в контексте проекта или workspace невозможно. Ни одно из сторонних решений эту задачу пока не решило.

SourceKit мы используем для показа ошибок/предупреждений и чтобы получить часть преобразований кода, которые он дает (fix-it), то есть по сути как линтер.

В будущем, посмотрим, к чему приведет движение CLion к clang и возможно, переиспользуем тот же подход для части задач.