Михаил Овчинников

Как найти путь к домашней директории симулятора iOS

Разработка под iOS Xcode

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

Самый быстрый путь: воспользоваться командой po в консоли LLDB. Для этого ставим выполнение приложения “на паузу”.

В появившейся командной строке LLDB пишем:

po NSHomeDirectory()

В ответ нам вернется путь к домашней директории симулятора, теперь его можно скопировать и открыть в Finder (Cmd+Shift+G). Файлы, которые вы туда положите будут сразу видны в приложении, перезапуск не потребуется.

Источник

Принудительное обновление provisioning profile в Xcode 8.3

Xcode Code signing

После обновления в Xсode 8.3 исчезло окно управления provisioning profile проекта. Им было удобно пользоваться для принудительного удаления и скачивания профайлов. Например, когда добавляешь на Developer Portal новые устройства для ad-hoc установки, профайл в Xcode обновляется далеко не сразу и не всегда. Чтобы решить эту проблему, можно было зайти в настройки аккаунта, открыть окно управления профайлами и сертификатами, нажать правой кнопкой мыши на профайле, выбрать «Move to trash», после чего заново скачивался новый.

Сейчас такой возможности нет из-за того, что в Xcode 8 ввели Automatic provisioning, и видимо в Apple сочли, что такая возможность больше не требуется. Проблема же с тем, что профайл не всегда обновляется после внесения изменений на Developer Portal осталась.

Существует очень простое решение: нужно зайти в директорию /Users/michail/Library/MobileDevice/Provisioning\ Profiles (это Library, которая в домашней папке, нужно включить отображение скрытых файлов чтобы её увидеть) и удалить нужные профайлы, или всё содержимое, Xcode потом автоматически загрузит свежие профайлы.

Статический анализ кода при помощи SwiftLint

SwiftLint Swift Статический анализатор Xcode

SwiftLint — это статический анализатор Swift-кода, разработанный компанией Realm, который проверяет его на соответствие стилю и соглашениям принятым в сообществе разработчиков. Главным образом он базируется на Swift style guide от Github. Почему это важно? Наличие соглашений и стандартов всегда лучше их отсутствия: код написанный в едином стиле, проще читать при командной разработке, а также косвенно анализаторы кода способны улучшить и стабильность приложения, так как распознают заведомо плохие практики. Начинающим изучать Swift разбор ошибок и предупреждений анализатора поможет разобраться в особенностях языка, а также избежать использования устаревших конструкций, которые могли быть скопированы с сайтов вроде Stack Overflow.

Установка

SwiftLint является консольным приложением и устанавливается через Homebrew, поэтому достаточно ввести команду:

brew install swiftlint

Инструмент можно использовать отдельно, запуская команду swiftlint в консоли, что не очень удобно, поэтому существует довольно простой способ интегрировать его с Xcode.

Интеграция с Xcode

Откройте проект, который вы разрабатываете, зайдите в его настройки, на вкладку Build Phases и добавьте новую фазу сборки с запуском скрипта.

Добавление новой фазы сборки в Xcode

В появившемся поле для ввода нужно добавить следующий код:

if which swiftlint >/dev/null; then
    swiftlint autocorrect
    swiftlint
else
    echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

Команда swiftlint autocorrect автоматически исправляет простые недочеты вроде пустых строк с пробелами и т.п. Я всегда запускаю ее перед проверкой, чтобы не отвлекаться на тривиальные вещи. Данный скрипт будет выполняться при каждой сборке проекта, а все ошибки и предупреждения будут выводиться наряду со стандартными предупреждениями Xcode.

Настройка правил

Если какие-то из правил вам не подходят (например ограничение длины строки в 100 символов, или размер метода), их легко можно отключить, для этого в корне проекта создается файл под названием: .swiftlint.yml. Например, чтобы отключить предупреждения о превышении допустимой длины строки, в него нужно добавить следующие строки:

disabled_rules:
  - line_length

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

Управляем сторонними библиотеками с CocoaPods

Разработка под iOS Разработка под macOS CocoaPods Менеджер пакетов Xcode

CocoaPods — менеджер пакетов, сделанный по образу и подобию RubyGems, позволяющий легко скачивать и подключать сторонние библиотеки к Swift и Objective-C проектам.

Установка CocoaPods

Менеджер пакетов написан на Ruby и распространяется через RubyGems. В общем случае установка сводится к единственной команде в терминале:

sudo gem install cocoapods --pre

Процесс может занять некоторое (продолжительное) время, не выводя ничего на экран, стоит быть к этому готовым и не прерывать установку до завершения (должна появиться надпись вроде «xx gems installed»).

Далее установим мастер-репозиторий CocoaPods со спецификациями всех доступных проектов. Делается это командой в терминале:

pod setup --verbose

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

Установка и использование библиотек

Чтобы сразу продемонстрировать все возможности создадим новый Swift-проект и установим для него Objective-C компонент под названием BEMCheckBox.

Откроем Xcode и создадим самый простой Single View, Swift-проект, я назову его «CocoaPodsExample». Сохраните его в любое место, закройте Xcode, откройте терминал, перейдите в директорию с проектом и напишите:

pod init

В корне директории должен появиться новый файл: Podfile. Это обычный текстовый файл с конфигурационным кодом на Ruby, в котором мы должны указать требуемые библиотеки. Обычно все солидные opensource-проекты указывают в Readme, что именно нужно прописать в Podfile для установки, и BEMCheckBox здесь не исключение. Откройте его любым текстовым редактором и приведите к следующему виду:

platform :ios, "9.0"

target 'CocoaPodsTest'do
  use_frameworks!

  pod 'BEMCheckBox'
end

Синтаксис должен быть интуитивно понятен: указываем целевую версию платформы, директива use_frameworks! указывает CocoaPods использовать фреймворки вместо статических библиотек (подробности в блоге проекта), а после pod пишем название библиотеки.

Иногда требуется установить не оригинальную библиотеку, а наиболее акутальный форк от другого автора (например, исправление критичного бага, который ещё не успели смерджить) в таком случае можно использовать следующий синтаксис:

pod 'SWRevealViewController', :git => 'git@github.com:safarijv/SWRevealViewController.git', :branch => 'safarijv-additions'

В данном случае мы указываем репозиторий и ветку из которой нужно взять под. Если не указать ветку, то по-умолчанию будет браться master. Аналогично нужно поступать, если вам требуется внести свои изменения в библиотеку: создать форк, закоммитить изменения и сослаться на свой репозиторий в Podfile. Не стоит делать изменения в уже установленных подах, т.к. потом будет очень сложно разобраться (особенно другим разработчикам), почему поведение библиотеки отличается от описанного в оригинальной документации.

Далее запускаем установку командой:

pod install

После окончания установки, в директории с проектом должен появиться файл *.xcworkspace, который объединяет созданный нами проект и проект Pods со всеми необходимыми библиотеками и конфигурационными файлами. Теперь для работы с проектом нужно открывать именно воркспейс, а не сам проект (в противном случае ему не будут видны сторонние библиотеки).

Проверить, что библиотека подключилась легко: перейдите на Storyboard, поместите на ViewController UIView из Object Library и в Identity Inspector поставьте ему класс BEMCheckBox (если не получается, то можно попробовать собрать проект Cmd + B). Запустите проект, и у вас должен появиться работающий чекбокс. Обратите внимание, что мы подключили Objective-C библиотеку к Swift проекту, если вы делали это раньше вручную, то помните, что для этой цели нужно было создавать специальный заголовочный файл Objective-C Bridging Header, но последние версии CocoaPods генерируют его автоматически, поэтому в этом больше нет необходимости.

CocoaPods и системы контроля версий

Обычно хорошим тоном в современной разработке является не добавлять сторонние библиотеки под контроль версий. Однако авторы проекта наоборот, рекомендуют хранить директорию Pods/ вместе с проектом. Преимуществом такого подхода является переносимость проекта и отсутствие зависимости от внешних инфраструктур (например Github, где хранится большинство исходных кодов библиотек). С другой стороны, в крупном проекте со множеством библиотек это может существенно увеличить размер репозитория, а в случае командной разработки добавит головной боли при слиянии веток. Поэтому в небольших проектах, где вы являетесь единственным разработчиком, можно смело оставить директорию Pods/ под контролем версий, а в крупных проектах и при командной разработке, лучше добавить ее в .gitignore.

1 of 1