Разработчик ios – iOS-разработчик, курсы программирования iOS, обучение разработке мобильных приложений Apple | GeekBrains — образовательный портал | GeekBrains

Лучшие практики и инструменты при разработке iOS приложений / Habr

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

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

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

Cocoapods

Я не думаю, что Cocoapods требует представления. Это библиотека для управления внешними зависимостями для IOS проектов. Она существует уже давно и является надежной и проверенной на практике в тысячах (если не в миллионах) проектов. Также существуют и альтернативные менеджеры зависимостей, например: Carthage, но я решил продолжить с Cocoapods, потому что у нее самый широкий спектр поддерживаемых проектов с открытым исходным кодом. Использовать Cocoapods очень просто, и он предоставляется с search index, который позволяет легко находить пакеты, которые могут пригодиться в любой момент.

Проект шаблона предоставлен с простым Podfile, который содержит Swiftlint и R.swift. Шаблон также включает Gemfile для управления версией Cocoapods, используемой для управления зависимостями. Данное решение является часто игнорируемым разработчиками, но оно предотвращает проблемы, возникающие, когда разработчики Вашей команды устанавливают зависимости, используя различные версии Cocoapods. Gemfile принудительно использует одну и ту же версию Cocoapods для всей команды.

Swiftlint

Swiftlint — это очень полезный инструмент для обеспечения соблюдения определенных правил и стиля написания кода каждым разработчиком в одной команде. Данную систему можно было бы рассматривать, как автоматизированную систему проверки кода, которая предупреждает разработчика об опасных моментах, таких, как, например, force casts, force tries и т. д., но кроме вышесказанного, данная система применяет общий стиль написания кода, следя за тем, чтобы все разработчики следовали одинаковым правилам, связанным со «стилем кода», например: отступы или интервалы. Такой подход имеет огромные преимущества, не только выполняя экономию времени на проверку кода, но также делает файлы проекта узнаваемыми, что повышает их читабельность и, как следствие, их понимание всеми участниками команды разработчиков. По данной ссылке предоставлен список всех правил. В шаблоне, Swiftlint он устанавливается посредством Cocoapods и включается в шаг «Фазы компиляции», поэтому он покажет предупреждение разработчику при каждой компиляции проекта.

R.swift

R.swift — это инструмент для получения строго типизированных, автоматически заполненных ресурсов, таких как изображения, сегменты шрифты и локализации. Он выполняет все перечисленные действия путем сканирования проекта и создания классов, необходимых для получения ресурсов. Самым большим преимуществом этой библиотеки является то, что при использовании ресурсов она делает программный код:

• Fully typed — меньше приведений и предположений о том, какой метод будет возвращен
• Compile time checked — больше не существует не корректных строк, которые приводят к остановке работы приложения во время выполнения кода
• Autocompleted — отсутствие необходимости угадывать заново название image/nib/storyboard

Рассмотрим следующий код с использованием официального строкового API:

let icon = UIImage(named: “custom-icon”)
 

Если вы ошиблись в названии изображения, вы получите ноль. Если какой-либо член вашей команды изменит имя ресурса изображения, этот код вернет ноль или его выполнение будет остановлено, если вы принудительно развернете изображение. При использовании R.swift это выглядит так:

let icon = R.image.customIcon()

Теперь вы можете быть уверены, что пиктограмма действительно существует (компилятор предупредит вас, если это не так, благодаря проверкам времени компиляции), и Вы будете явно уверены, что не сделаете опечатку в названии пиктограммы, поскольку будете использовать автозаполнение.

R.swift устанавливается посредством Cocoapods и интегрируется в шаблон в Фазе компиляции и будет генерировать классы оболочки Swift для каждой компиляции. Это означает, что если вы добавите файл / изображение / локализацию / шрифт / цвет / перо и т. д., то все это будет доступно посредством R.swift после компиляции проекта.

Отдельный файл AppDelegate для тестов

Очень часто забывают о хорошей практике использования отдельного класса TestAppDelegate при запуске тестов. Почему это хорошая идея? Обычно класс AppDelegate выполняет много работы при запуске приложения. Он может иметь логику конфигураций window, конфигурировать базовое отображение пользовательского интерфейса приложения, выполнить логику регистрации для получения уведомлений, иметь код настройки подключения к базе данных и даже иногда выполнять вызовы серверного API. Юнит тесты не должны иметь сайд эффектов. Вы действительно не хотите выполнять вызовы случайных API и настраивать всю структуру пользовательского интерфейса вашего приложения только для запуска юнит тестов?

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

Шаблон содержит файл main.swift, который является основной точкой входа для приложения. В этом файле есть методы, которые проверяют среду работы приложения, и, если это тестовая среда, они вызывают TestAppDelegate.

Флаги профилирования производительности компилятора

Swift — это отличный язык, более простой в использовании и более безопасный, чем Objective-C (IMO). Но когда он был впервые представлен, у него был один большой недостаток — время компиляции. Вернувшись в дни, когда я работал над проектом в Swift, в котором было примерно 40 тыс. строк кода Swift (проект среднего размера). Код был очень тяжелым, с параметрами настройки и выводом типов, а компиляция чистой сборки заняла почти 5 минут. При внесении даже небольших изменений, проект повторно компилируется и это занимает около 2 минут, чтобы увидеть изменения. Это было одним из худших событий, которые я когда-либо испытывал, и из-за этого я почти прекратил использовать Swift.

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

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

Dev/Staging/Production configurations

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

Одним из способов поддержки нескольких сред в проекте iOS является добавление конфигураций на уровне проекта.

Конфигурации уровня проекта

Определив конфигурации, можно создать файл Configuration.plist, содержащий переменные для каждой среды.

Configuration.plist

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

Затем необходимо добавить еще одно свойство в файл проекта Info.plist. Значение данного свойства будет динамически подставляться во время выполнения в имя текущей конфигурации.

Все это предварительно настроено в шаблоне.

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

Readme

Каждый проект должен содержать файл Readme, в котором, по крайней мере, содержатся инструкции по установке зависимостей и запуску проекта. Он также должен содержать описания архитектуры проекта и модулей. К сожалению, разработчики не любят писать документацию (файл readme является частью этой работы), и я видел проект, который разрабатывался месяцами, и у него даже был файл Readme. Чтобы снять бремя написания файла readme, шаблон содержит стандартный файл readme, который охватывает установку и структуру проекта. При настройке нового проекта с использованием шаблонов, вы автоматически включаете файл Readme.

Gitignore

В настоящее время большинство проектов используют GIT в качестве системы контроля версий. При использовании GIT у разработчиков нет желания игнорировать некоторые файлы или папки в проекте, например папку сборки или папку производных данных. Чтобы избавить разработчика от необходимости поиска файла gitignore, подходящего для его проекта iOS, шаблон содержит стандартный gitignore, предоставленный участниками Github.

Базовые классы для обработки внешних ссылок и уведомлений

В настоящее время почти каждое приложение должно обрабатывать внешние ссылки и уведомления. Для этого разработчик должен написать некоторое количество стандартного кода в классе AppDelegate. В данном шаблоне имеется описание, как это выполнить, в нем также содержаться базовые классы, облегчающие работу с внешними ссылками и уведомлениями.

Вывод

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

Сертификация в Apple Developer Center простым и понятным языком / Habr

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

Зачастую при первом погружении в эту систему у начинающих (и не только) разработчиков возникают серьезные проблемы с пониманием того, как функционирует Apple Developer Center (будем называть его «девцентр» для простоты). В результате, мне в процессе профессиональной деятельности не раз приходилось наблюдать на новых местах работы огромные свалки из профилей и сертификатов в девцентре, в результате чего приходилось приступать к «разбору завалов».

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

Мы разберем процесс управления вашим приложением в Apple Developer Center от его создания до публикации в магазине App Store. Мы будем говорить только о базовых вещах, таких, как разработка, тестирование и публикация, а также обсудим APNs (Push Notifications).

Отмечу тот факт, что далее я буду описывать принцип работы девцентра по состоянию на 31 марта 2016 года, поэтому если вы читаете эту статью позднее — все уже могло измениться.

Собственно, для работы нам нужно следующее:

• Рабочий Mac, либо PC с виртуальной машиной и установленной на ней Mac OS.
• Действующий Apple ID. Его всегда можно бесплатно зарегистрировать на официальном сайте компании Apple.
• На вашем Apple ID (либо у одной из компаний, которая добавила ваш Apple ID в свою команду) должна быть активирована так называемая Apple Developer Program — оплачиваемая раз в год «подписка», дающая вам доступ к Apple Developer Center и возможность публиковать ваши приложения в App Store. На текущий момент стоимость в пересчете на год невелика и составляет в районе $99 за год пользования.
• И, конечно же, навыки разработки под iOS.

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

• Certificates, Identifiers & Profiles. Раздел обеспечивает управление всей системой сертификации ваших приложений. Работу именно с этим разделом мы и будем разбирать в данной статье.
• iTunes Connect. Дает доступ к внутреннему и внешнему тестированию через TestFlight, а также к управлению публикацией ваших приложений в App Store.

Давайте подробно разберем понятия, лежащие в основе функционирования девцентра Apple.

Сертификаты (Certificates)

Этот раздел дает доступ к управлению сертификатами, которыми обладает ваша учетная запись Apple ID. Каждый из этапов, которые вы будете проходить, будь то разработка, тестирование или публикация, включая все значимые составляющие экосистемы Apple вроде Push Notifications, требует обязательного наличия актуального (действующего, Active) сертификата. Говоря проще, ваше приложение не сможет даже чихнуть, не имея на то разрешения из Apple Developer Center. Чуть подробнее о подразделах:

• Pending. Запрошенные вами сертификаты, находящиеся в процессе обработки от Apple. Для дев (Development) и прод (Production) сертификатов конкретно в моем случае этот подраздел чаще всего пустует.
• Development. Дев-сертификаты, обеспечивающие возможность отладки вашего приложения на конкретных девайсах (одном либо нескольких) через Xcode, а также создание дев-сборок «в отладочном режиме». Более подробно поговорим о них чуть ниже.
• Production. Прод-сертификаты, обеспечивающие работоспособность приложения при тестировании в TestFlight и при публикации в магазине App Store.

Теперь разберем типы сертификатов.

Сертификаты типа «Development»

В первую очередь, нужно знать, что девелоперский сертификат всегда привязывается к одной конкретной машине. Поэтому для отладки на вашем Mac вам понадобится доступ к этому сертификату. Тут есть варианты. Например, если, вы устроились на работу iOS-программистом, и в ваши задачи входит отладка на устройствах (как правило, так и есть), то есть два пути решения (какой из них выбирать — зависит от вас и условий работы в вашей компании):

• Создать отдельный дев-сертификат конкретно для вашего Mac, скачать и установить его. Плюс понадобится сгенерировать и установить на свой Mac девелоперский профиль на основе этого сертификата, но об этом позже.
• Либо экспортировать с машины, на которую заведен сертификат, файл *.p12/*.pfx (это можно сделать в связке ключей Apple). Такой файл защищается паролем при экспорте, и, зная этот пароль, информацию о сертификате можно будет импортировать на любом другом Mac. В этом случае отпадает необходимость создавать для каждого Mac отдельные Development-сертификаты и отдельные Development-профили. Небольшая оговорка: профиль хоть и должен быть сгенерирован для той машины, на которую выпущен экспортируемый сертификат, но в этот профиль понадобится добавить UDID вашего устройства прежде, чем выдавать профиль вам для установки, иначе ничего работать не будет.

Инструкция по процессу будет показана вам в девцентре Apple при начале создания сертификата, там все расписано очень подробно и понятно, по шагам, сложностей возникать не должно. Если вкратце, то после выбора типа сертификата (iOS App Development, для отладки приложения, либо APNs Sandbox, для отладки пушей) вам придется создать файл запроса к бюро сертификации (Certificate Signing Identity Request), на основе которого и будет сгенерирован девелоперский сертификат. Если вы хотите и отлаживать приложение, и отлаживать пуш-нотификации в «песочнице», то вам потребуются оба этих сертификата. Забегая вперед, упомяну, что аналогичный процесс применяется и при создании прод-сертификатов.

Наличие дев-сертификата означает, что, скачав его и установив двойным кликом в Связку Ключей (Apple Keychain), вы сможете запускать ваше приложение напрямую через Xcode в режиме отладки на устройстве, подключив это устройство проводом к вашему Mac. Перечень разрешенных конкретных устройств Apple нужно будет обязательно указать при генерации девелоперского профиля, но об этом позже. Также, вы сможете собрать и экспортировать сборку с дев-профилем, но стоит учесть, что в этом случае ваше приложение не будет иметь доступа к продакшн-возможностям (APNs будет только в режиме sandbox, например).

Сертификаты типа «Production»

Для начала на всякий случай поясню, что сборкой iOS-приложения называют *.ipa-файл, архив, выпускаемый с соблюдением правил сертификации Apple через команду Project — Archive в Xcode.

Теперь о сертификации. Прод-сертификаты обеспечивают функционирование различных подсистем приложения в «боевых» условиях, то есть в магазине App Store, а также на устройствах, где выполняется внутреннее и внешнее тестирование приложения через TestFlight. Здесь, по аналогии с Development-сертификацией, есть тип App Store & Ad Hoc Production, а также тип APNs Production, использующийся веб-сервером для рассылки push-уведомлений. Если вы планируете выпустить приложение, поддерживающее работу с пушами, то вам понадобятся оба сертификата, как App Store & Ad Hoc (на основе которого вы сделаете сборку и отправите приложение в iTunes Connect), так и APNs Production (его вы отдадите серверу, а тот воспользуется им для получения прав на рассылку пушей). В довесок к уже упомянутым подсистемам есть еще несколько других, обеспечивающих доступ к Wallet, Apple Watch и так далее, но их обзор выходит за рамки данной статьи.

Очень часто возникает вопрос о том, в чем же разница между App Store и тем самым Ad Hoc. Ранее они были представлены разными сертификатами, с некоторого времени Apple объединила их в единое целое, за что им большое спасибо. Чуть подробнее об этих разновидностях:

• Выпуск сборок типа App Store. Обеспечивает возможность тестировать приложение в TestFlight, как в режиме внутреннего, так и в режиме внешнего тестирования. Также дает возможность опубликовать приложение в App Store.
• Выпуск сборок типа Ad Hoc. Термин «Ad Hoc» можно перевести как «специальный», «для конкретной цели». Такой тип сертификации обеспечивает возможность запускать ваше приложение (включая все нужные подсистемы типа APNs) в боевых условиях, но только на конкретных девайсах, и без участия Xcode в процессе запуска. Другими словами, Ad Hoc необходим, если вы захотите поставить ваше приложение на стороннее устройство, не имея к нему прямого доступа (то есть не подсоединяя его проводом к вашему Mac, так как в этом случае вам бы хватило Development-сертификата), но при этом и не выкладывая приложение в iTunes Connect. Такой сертификат используется при создании специального Ad Hoc-профиля, о котором пойдет речь чуть позже.

Еще один частый вопрос: чем отличаются сборки, собранные на паре Development Certificate + Development Profile, и сборки, созданные через связку Distribution Certificate + Ad Hoc Profile? Ведь и там, и там нужно указывать перечень разрешенных для установки устройств, и то, и то можно устанавливать через iTunes. В чем же различие? На деле, разница в том, что дев-сборка будет запускаться «в отладочном режиме», то есть, например, APNs ей будут доступны только в режиме «sandbox». Продакшн-сборка будет обладать «боевыми» правами, с доступом во все подсистемы Apple вроде «настоящих» APNs, iCloud и так далее.

Intermediate Certificates

Некоторое время назад Apple внесла изменения в логику работы девцентра и своей системы сертификации, после чего на большинстве компьютеров пропала возможность делать сборки приложений, несмотря на наличие активных дев- и прод-сертификатов и актуальных профилей. Причина этого была в том, что Apple добавила дополнительное требование, чтобы на вашем Mac в связке ключей был установлен специальный сертификат под названием «Worldwide Developer Relations Certificate Authority». Он устанавливается автоматически с новыми версиями Xcode, но те, у кого Xcode уже был установлен ранее, просто должны были установить этот сертификат вручную, скачав его по прямой ссылке из секции Intermediate Certificates в девцентре Apple, после чего проблемы со сборками исчезали. Больше никакой смысловой нагрузки этот сертификат не несет.

Идентификаторы (Identifiers)

Данный раздел обеспечивает управление идентификаторами. Для вашего приложения в минимальном исполнении понадобится App ID, управление которыми доступно в одноименном подразделе.

В буквальном переводе «App ID» означает «идентификатор приложения», что полностью отражает его суть. Любое ваше приложение, которое вы хотите отлаживать на устройстве Apple, тестировать через TestFlight и/или публиковать в магазин App Store, должно обладать собственным уникальным именем, по которому его можно однозначно идентифицировать среди тысяч других приложений. При добавлении нового App ID вам будет предложено ввести несколько элементов:

• App ID Description. Имя вашего приложения. К примеру, если ваше приложение называется Mail Printer, то прямо так его и записываем в это текстовое поле.
• App ID Prefix. Префикс вашего приложения, он выдается вам автоматически и будет общим для конкретной команды Apple Team, где подключена и активна Apple Developer Program.
• App ID Suffix. Здесь нам понадобится выбрать Explicit App ID, чтобы указать бандл (bundle) приложения. Это идентификатор, обычно имеющий вид com.mycompany.myappname, где mycompany — имя вашей компании или вашего домена. Например, com.homecompany.MailPrinter. Обращаю ваше внимание, что точно такой же бандл должен быть выставлен в настройках таргета (Target) вашего приложения в Xcode (секция настроек General, поле Bundle Identifier).
• App Services. Здесь вам нужно отметить те сервисы, которые вы планируете использовать в вашем приложении. По умолчанию там отмечены только Game Center и In-App Purchase, их использование обязательно, удалить их нельзя. Остальные сервисы подключайте по мере необходимости.

После создания App ID вы можете использовать его для генерации любых типов профилей, об этом чуть позже.

Устройства (Devices)

В этом разделе размещено управление всеми устройствами Apple, которые вы можете использовать в рамках вашей Apple Developer Program. Есть ограничение, максимум 100 зарегистрированных девайсов одного типа (iPhone, iPad и так далее) на одну учетную запись в год, обычно этого более чем достаточно. При необходимости отладки на устройстве или выпуска Ad Hoc-сборки просто добавляйте сюда UDID нужных вам девайсов и используйте их при генерации профилей.

Профили (Provisioning Profiles)

Дословно название этого раздела переводится как «Профили обеспечения». Чуть более развернуто я бы описал понятие «профиль» как «Специальный файл, обеспечивающий доступ к некоторой функциональности в конкретной сборке вашего приложения». В данном разделе девцентра вы можете управлять вашими профилями, обеспечивая себе возможность выпускать сборки приложения для различных целей, то есть «профилировать» его. По сути, профиль является результатом объединения двух (иногда трех) компонентов:

• Активного сертификата определенного типа (раздел Certificates). С помощью сертификата профиль подтверждает, что ваше приложение имеет право на выполнение определенной группы действий.
• App ID (раздел Identities). Определяет конкретное приложение, для которого выпускается профиль.
• В некоторых случаях, еще нужен список зарегистрированных устройств (раздел Devices). Определяет перечень устройств, на которые разрешено устанавливать вашу сборку. Используется только с некоторыми типами профилей.

На выходе как раз и получаем профиль для выпуска сборок с определенными целями. Давайте рассмотрим разновидности профилей.

Профили типа «Development»

Это профиль для разработки, то есть его основное назначение — отладка вашего приложения на конкретных устройствах через Xcode с прямым подключением устройства проводом к вашему Mac. Дев-профили представлены двумя видами:

• iOS App Development. Требует указания перечня разрешенных устройств из раздела Devices.
  Используется для отладки iOS-приложений.
• tvOS App Development. Аналогично, только используется для tvOS-приложений.

Профили типа «Distribution»

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

• App Store. Используется для тестирования (как внутреннего, так и внешнего) в TestFlight, а также для выпуска приложения в App Store.
• tvOS App Store. Аналогично предыдущему, только для tvOS.
• Ad Hoc. Требует указания перечня разрешенных устройств из раздела Devices.
  Используется, если вы хотите выпустить сборку, которую можно будет поставить в режиме «Production», но только на некоторых устройствах. Реальная ситуация, когда это может понадобится, например, следующая. Вы разрабатываете приложение, а в процессе работы заказчик попросил у вас «дать ему пощупать приложение» на своем Apple-устройстве. В iTunes Connect для активации внешнего тестирования вы еще выходить не готовы, но просьбу заказчика нужно выполнять — вот тут как раз и пригодится Ad Hoc-профиль, сгенерированный на базе прод-сертификата App Store & Ad Hoc Production Certificate. Важный момент: в моем случае часто возникали проблемы при экспорте сборок подобным способом, если в Xcode не был также установлен и Development-сертификат. Ошибки были разного рода, от невозможности подписать сборку до абсурдного «App ID is not available», хотя это фактически не так (замена на другой бандл ничего не давала). Поэтому, по моему предположению, для удачного экспорта Ad Hoc-сборок необходимо, чтобы, помимо Ad Hoc-профиля, был также установлен и дев-сертификат с соответствующим профилем.
• tvOS Ad Hoc. Аналогично предыдущему, только для tvOS.

Этот сервис предоставляет вам возможность управлять внутренним и внешним тестированием в TestFlight, а также выкладывать приложение в App Store. Рассмотрение этого процесса выходит за рамки данной статьи, упомяну лишь тот факт, что для корректной работы этому сервису необходимы сборки, созданные на базе профиля типа Distribution — App Store (для iOS либо tvOS). Другие типы профилей здесь не поддерживаются.
По сути, при получении доступа к девцентру с активной Apple Developer Program ваш алгоритм действий должен сводиться к следующему:

1. Определиться, с каких конкретно машин будет производиться прямая отладка на устройствах через Xcode. Определить среди них основную машину (это может быть Mac разработчика, с которого чаще всего планируется производить отладку). Сгенерировать для основного Mac сертификаты группы Development, скачать и установить их. По необходимости, экспортировать информацию об этих сертификатах в файлы *.p12/*.pfx, которые потом можно будет разослать на другие целевые машины, где также планируется проводить отладку приложений.
2. Узнать, с какой машины планируется собирать сборки для тестирования и/или публикации в App Store. Сгенерировать для нее сертификат группы Distribution. Повторить процедуру с экспортом из предыдущего пункта, если требуется поддержка нескольких машин.
3. Проконтролировать наличие нужного идентификатора приложения в разделе App IDs и соответствие указанного там бандла значению поля Bundle Identifier в проекте в Xcode, при наличии несовпадения — устранить его либо в девцентре, либо в Xcode (где именно это править — зависит от вашей конкретной ситуации).
4. Убрать (Revoke/Delete) все сертификаты, а затем и профили, которые обладают пометкой Expired (истекший сертификат) или Invalid (некорректный профиль). Также отмечу, что, в отличие от сертификатов, профили можно редактировать. То есть, сгенерировав новые сертификаты, вместо удаления старых профилей вы можете просто отредактировать их, указав им новые сертификаты в качестве подписи.
5. Если профилей нет, либо не хватает нужных, то сгенерировать необходимые профили.
6. Скачать и установить нужные для вашей машины сертификаты и профили на свой компьютер. Установка производится двойным кликом на файле. Сертификаты будут установлены в Связку Ключей (Apple Keychain), профили — в Xcode.
7. Указать в настройках проекта Xcode нужные вам сертификаты в секции Build Settings — Code Signing Identity — Development/Distribution, а также указать необходимый Provisioning Profile.

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

• Произвести запуск в режиме отладки (Project — Run) через Xcode на разрешенном устройстве, используя дев-профиль.
• Создать сборку (Project — Archive с выбранным целевым устройством Generic iOS Device) на базе продакшн-профиля Ad Hoc для установки на конкретные устройства (такую сборку можно будет выслать, например, по электронной почте заказчику, чтобы он установил ее на свое разрешенное устройство).
• Создать сборку аналогично предыдущему пункту, но на базе продакшн-профиля App Store. Это будет сборка для внутреннего и/или внешнего тестирования, а также для выкладки в App Store, которую можно использовать в iTunes Connect.

Надеюсь, это подробное описание поможет вам разобраться в специфике функционирования системы сертификации приложений Apple, а также поможет навести порядок в Apple Developer Center.

Почему я как разработчик ненавижу iOS / Habr

С позиции пользователя, iOS — выдающаяся платформа. Возможно, несколько монотонная и жёсткая, но привлекательная и надёжная (в основном).

С позиции разработчика дела обстоят совсем иначе. Работать с iOS (а на самом деле, вообще, с Apple) — всё равно, что пытаться разговаривать с параноидальным роботом, действующим как известный советский пограничник из романа Кафки.

Он является одним из самых отвратительных браузеров, с которыми я имел дело с тех пор, как начал заниматься веб-разработкой в конце 90-х. Я потерял счёт костылям, которые пришлось поставить, чтобы заставить программы работать в Safari для iOS или в её веб-представлениях. Это просто неприемлемо в мире 2016 года, где всё подчиняется стандартам.

Чтобы дать вам представление: вы не можете, например, задать высоту элемента <iframe>. Это то, что мы в состоянии сделать в любом другом браузере (даже в IE6, самом ненавидимом браузере на Земле), после того как тэг <iframe> был введён в 1999 году. Эта проблема существует с 2011 года.

Ситуация, действительно, удивляет. Почему Apple не позволяет другим браузерным движкам работать в iOS? Или почему Apple не вкладывает больше ресурсов в проект Webkit, как это делает Google со своим Chromium?

Нола Лоусон: это потому, что они имеют намного больше инженеров и энтузиастов своего дела среди разработчиков, чем Apple.

Однажды мне понадобилось протестировать симулятор с iOS 7. Догадайтесь, что произошло. Выяснилось, что это, конечно, возможно, но потребуется загрузить старую и неподдерживаемую версию Xcode, которая работает только в Mavericks!

То есть, вы должны хранить либо старые Маки, либо старые iOS-устройства, молясь, чтобы Apple не сломала что-либо дальше.

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

Операции с сертификатами iOS являются делом утомительным, забюрократизированным и трудным для понимания. Иногда что-то рушится, и тогда ни документация Apple, ни Xcode, ни этот кошмарный Member Center не могут пролить хоть какой-то свет на то, что же всё-таки происходит.

Совсем недавно я потерял 2 дня, пытаясь выяснить, почему я не могу создать определённый сертификат, и, наконец, нашёл ответ. Кто бы мог подумать — в каких-то малоизвестных документах по Mozilla. Xcode выдал мне только выделенную серым кнопку, а на форуме разработчиков Apple не отозвался вообще никто.

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

AppStore — ещё один, огромный, источник раздражения. Например, всего несколько часов назад приложение, над которым я работаю, было отклонено, потому что кому-то в Apple не понравились мои скриншоты:

Мы отмечаем, что ваш(и) скриншот(ы) недостаточно показывает(ют) ваше приложение в действии.

Я, понятно, загрузил скриншоты работающего приложения без каких-либо изменений.

Если Apple считает, что скриншотов должно быть больше или что они выглядят как-то неприглядно, то почему бы так и не написать? Нет, вы не заслуживаете ничего больше, чем автоматизированный ответ.

Кстати, компании требуется неделя, чтобы сообщить, нравятся ли ей ваши скриншоты. Желаем успеха в попытках спланировать стратегию скоординированного выхода…

Помните робота из фантастического боевика «Элизиум — рай не на Земле»?

«Вы желаете говорить с человеком?»

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

Но изложенное выше не так плохо, как то, что произошло сегодня у меня с приложением Dash iOS. Apple решил, что разработчик успешного приложения причастен к мошенничеству с обзорами и закрыл это приложение.

Решение Apple окончательное и не может быть обжаловано.

Конечно, все мы знаем, что компания Apple — безупречная и что она никогда не делает ошибок. Как можно сомневаться в этом?
Вы должны платить за честь быть разработчиком iOS. Недостаточно того, что Apple заставляет вас компилировать на, фактически не стоящем своих денег, компьютере Apple или что вы должны терпеть все эти проблемы.

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

И в то же время можно бесплатно вести разработку на почти любой другой платформе в мире и даже компилировать с любой другой платформы. Как, например, возможна компиляция приложений для Windows на macOS, или приложений для Android на Linux.

Это — всё.

Авторская правка от 7 октября 2016 года: очевидно, что твиттер-аккаунт @ryosukeniwa был удалён после публикации этого материала. Какое совпадение.

18 шагов, чтобы стать iOS-разработчиком

Мобильная операционная система Apple существует уже более 10 лет. И если пять лет назад для работы с ней было достаточно изучить Objective C и несколько дополнительных фреймворков, то сегодня, захотев стать iOS-разработчиком, можно легко запутаться в обилии вариантов и возможностей.

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

1. Выберите язык программирования

Objective C или Swift. Swift считается более современным языком, который проще изучить. Если вы знакомы с любым другим языком, похожим на C, то вы сможете достаточно быстро разобраться и со Swift. Он позволит вам создать более точный и безопасный код. Однако не стоит пренебрегать и Objective C – в любом проекте, который уже существует на протяжении нескольких лет, однозначно будет присутствовать доля кода на Objective C. Многие крупные компании также используют этот язык и те преимущества, которые он может дать. Поэтому, когда вы освоите базу для работы со Swift, нелишним будет вернуться назад к Objective C и изучить данный язык.

2. Установите Xcode

Для того, чтобы написать и запустить код, вам понадобится среда разработки. Компания Apple позаботилась об этом и создала Xcode, с помощью которого ваша работа станет максимально комфортной. Xcode доступен в AppStore на бесплатной основе. Однако для того, чтобы его скачать, вам необходимо будет перейти и зарегистрироваться на developer.apple.com – это также бесплатно. Заплатить вам нужно будет только в том случае, если вы захотите загрузить свое приложение в AppStore. Кроме того, есть и платная альтернатива Xcode — AppCode от компании JetBrains.

3. Учитесь с помощью игровой площадки

Еще одна причина, почему стоит выбрать Swift в качестве языка изучения, это прекрасная функция «Игровая площадка» («Playgroud»), которая встроена в Xcode. Данная функция позволяет вам отслеживать выполнение кода в режиме реального времени. Apple также хранит в открытом доступе всю информацию, необходимую для работы со Swift.  Узнайте, как работает память в Swift, как избежать утечек памяти и разрешить циклические зависимости. Овладев языком на достаточном уровне, постарайтесь создать как можно больше апплетов. Это поможет

• запомнить типичные структуры данных: связный список, стек, бинарное дерево;
• изучить классические алгоритмы: бинарный поиск, пирамидальную сортировку или динамическое программирование.

4. Создайте ваше первое приложение

Чтобы начать разработку на iOS, вам необходимо изучить UIKit – это база для всех iOS-приложений. Создайте пустое iOS-приложение в Xcode и начните изучать основные компоненты приложений: UIApplication, AppDelegate, UIViewController, Storyboards и другие. Тщательно изучите доступную прямо в Xcode документацию по каждому из компонентов. Когда вы посчитаете, что освоили их, начинайте создавать базовые примеры. Вот несколько идей, с которых можно начать:

• Откройте список друзей с детализированной информацией о каждом друге. Создайте две страницы: на одной показаны имена друзей, при нажатии на имя друга открывается вторая страница с детализированной информацией о нем.
• Откройте в созданном вами приложении несколько скачанных из интернета картинок. Сделайте так, чтобы страница выглядела как стандартное приложение для просмотра фотографий. При нажатии на картинку она должна открываться на весь экран с функцией «Увеличить».

 5. Настройте сохранение данных между сессиями

Фактически, существование вашего приложения напоминает жизнь главного героя в фильме «День сурка»: для него каждый запуск – новый. Научитесь сохранять данные: начните с UserDefaults, потом ознакомьтесь с протоколом кодирования, затем перейдите к CoreData. Также будет нелишним использовать Realm и Firebase – они являются крайне популярной альтернативой для CoreData. Испробуйте все варианты и найдите наиболее подходящий вам.

6. Переходите в онлайн 

Начните работать с асинхронным кодом. Изучите Grand Central Dispatch (GCD) и NSOperation. Затем, изучите, как работает URLSession, как парсить JSON и XML. Чтобы получить дополнительный опыт, переделайте упражнения из пункта 4, используя полученные навыки. Вы также можете на все тех же Swift или Objective C создать приложение, которое будет в виде списка отображать самые популярные запросы и ответы на Github.

7. Используйте менеджеры зависимостей

В AppStore существует неисчислимое множество приложений – для всех них разработчики уже написали и протестировали огромное количество строк кода. Нет смысла заново изобретать велосипед: используйте CocoaPods и Carthage. У Swift есть своя собственная библиотека: Swift Package Manager. Установите несколько популярных библиотек: Alamofire, Snapkit.

8. Стандарты и лучшие примеры

Вы можете найти огромное количество проектов с открытым исходным кодом. Учитесь, используя их в качестве примера. Их коды используются в сотнях и тысячах приложений в AppStore, а это означает, что эти коды работают достаточно стабильно. Ознакомьтесь с официальными рекомендациями Apple. Если вы чувствуете себя достаточно уверенным в собственных силах, попытайтесь поучаствовать в одном из подобных проектов с открытым исходным кодом.

9. Тестируйте свой код

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

 

 

10. Изучите различные архитектуры

До этого мы использовали стандартную архитектуру, которую предлагает нам Apple – MVC (Model-View-Controller). Но, если вы уже успели написать несколько тестов, то вы наверняка заметили, что выбор определенных элементов, которые необходимо протестировать, это непростая задача. Начните с использования наиболее стандартных шаблонов: MVVM (Model-View-ViewModel), MVP (Model-View-Presenter) и VIPER (View-Interactor-Presenter-Entity-Router). Также можете ознакомиться с Redux.

11. Используйте все, что у вас есть

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

12. Изучите, как работает AppStore 

Выгрузка приложения в AppStore – это один из самых важных моментов в разработке iOS-приложений. Если вы твердо решили это сделать, тогда приготовьтесь заплатить за это 99 долларов, после чего сможете получить доступ к itunesconnect.apple.com. Даже если вы не готовы пока вносить оплату, нелишним будет изучить, как именно происходит публикация приложения, какие нужны сертификаты и профили, а также каким именно образом люди скачивают и загружают приложение.

13. Используйте аналитические инструменты

После загрузки приложения в AppStore все веселье только начинается. Вам придется иметь дело с различными девайсами и операционными системами, справляться с непредсказуемым поведением пользователей и неожиданными сбоями программы. Используйте логи, чтобы получить необходимую вам информацию, которая поможет понять, что именно вызвало ошибку. Чтобы проанализировать поведение и предпочтения пользователей, используйте такие аналитические платформы, как Firebase, Amplitude и многие другие.

14. Автоматизируйте все, что можно автоматизировать

Достаточно много времени, как правило, тратится на рутинную работу. Время от времени необходимо выслать новую версию приложения тестовой группе пользователей, зарегистрировать новый девайс, проверить, не конфликтуют ли внесенные в код изменения с ранее написанной частью кода. Для подобной работы существуют готовые решения. Изучите fastlane и используйте системы непрерывного обучения (CI system), например, такие как Travis. Постарайтесь еще при разработке вашего приложения автоматизировать часть задач.

15. Изучите экосистему

iOS-разработка не упирается только лишь в поддержку iPhone. Существует также огромный рынок iPad, Apple Watch, а также Apple TV. Научитесь оперировать своим кодом таким образом, чтобы его можно было использовать и для работы над другими iOS-устройствами (в этом вам поможет правильно выбранная архитектура). Обратите особое внимание на расширения Сегодня и расширения Действий («Today & Action extensions»).

16. Оптимизируйте ваш код

Ваше приложение должно отлично работать как на новых, мощных девайсах, так и на более старых. Используйте встроенные в Xcode инструменты для оптимизации скорости запуска приложения.

17. Не останавливайтесь на достигнутом

Несмотря на то, что вы уже изучили достаточно информации и многое знаете, однако на этом работа точно не заканчивается. Ваша работа в дальнейшем будет заключаться также в модерации покупок и подписок, защите данных пользователей, локализации (далеко не во всех языках слова читаются слева направо, и это надо также учитывать), адаптации приложения для использования увеличенных шрифтов и иных дизайнов. Попробуйте использовать RxSwift и ReactiveCocoa. Посмотрите, как изменяется ваш код. Попробуйте различные подходы к UI, к примеру, Texture (в качестве AsyncDisplayKit)

18. Найдите работу

Умение писать код – это далеко не единственное, что вам нужно уметь, чтобы успешно выполнять свою работу. Научитесь функционировать в команде, четко планируйте время, которое вы тратите на разработку, научитесь объяснять и отстаивать свою точку зрения – все это достаточно важные аспекты вашей будущей работы. Лучший способ овладеть всеми этими навыками – это использовать их непосредственно в работе. Создайте CV, оставьте в нем ссылки на ваши приложения на Github и дерзайте.

Источник