Provisioning profile что это
Выкладываем приложение в App Store. Даже если вы не разработчик
Ранее писали про этап подготовки к релизу. Сейчас расскажем про публикацию приложения в AppStore. Пошаговый гайд будет полезен новичкам, которые до этого не сталкивались с полицией нравов из Купертино.
Для того чтобы выложить приложение в App Store, потребуется оплаченный аккаунт разработчика, среда разработки XCode и исходный код вашего приложения. Разобьем процесс на четыре этапа:
Настройка аккаунта
Все приложения перед выгрузкой в App Store должны быть подписаны сертификатом разработчика. Это нужно, чтобы пользователи App Store были уверены, что скачивают конкретное приложение от конкретного разработчика, а не подделку от чужого имени. Процедура подписывания (code signing) приложения позволяет операционной системе узнать, кто является разработчиком. И удостовериться в том, что приложение не было изменено с момента сборки. Точнее, с того момента, как разработчик его подписал. В этой процедуре участвуют три объекта: сертификат разработчика, AppID и Provisioning profile.
Сертификат
Сертификат представляет собой пару ключей асимметричного шифрования: приватный и публичный. В процессе сборки XCode формирует цифровую подпись для сборки на основании данных приватного ключа. Проверить подпись можно с помощью публичного ключа, который доступен и для Apple, который этот сертификат выдала.
Одного сертификата достаточно для выкладки неограниченного количества приложений.
Чтобы создать сертификат, нужно:
Сохраните сгенерированный сертификат на компьютер, откройте его (дважды кликнув). Сертификат будет помещен в системное хранилище и доступен для XCode.
AppID
Это уникальный строковый идентификатор приложения среди всех приложений. Он нужен для однозначной идентификации во всех системах: iTunes Connect, App Store и пр. Он состоит из двух частей: TeamID и BundleID. TeamID — идентификатор разработчика, выдается Apple на этапе регистрации аккаунта разработчика и не меняется. BundleID задается разработчиком при регистрации приложения в аккаунте.
Provisioning profile
Это профиль, который однозначно связывает AppID и сертификат разработчика (публичный ключ сертификата). В случае development provisioning profile он также содержит UDID всех устройств, на которых возможен запуск приложения.
Сохраните сгенерированный профайл на компьютер, откройте его, дважды кликнув. Теперь сертификат доступен для XCode.
Оформление приложения для магазина
Теперь нужно добавить приложение в iTunes Connect.
Переходим на https://itunesconnect.apple.com в раздел MyApps. Чтобы добавить приложение, нажмите плюсик слева вверху:
Заполняем открывшуюся форму:
Если все заполнено правильно, попадаем на страницу приложения.
На вкладке слева «Pricing and Availability» заполняем информацию о стоимости приложения в сторе. На вкладке слева с номером версии заполняем маркетинговую информацию:
О том, как подготовить маркетинговую информацию, мы рассказывали в предыдущей статье.
Также есть секция для того, чтобы можно было указать конкретную сборку, которую отправлять на ревью, а затем и в стор. Выбор недоступен до тех пор, пока мы не загрузили в iTunes Connect ни одной сборки приложения. Мы вернемся к этой секции позже:
Чтобы сохранить внесенные изменения, используйте кнопку Save наверху:
Настройка проекта, сборка и выгрузка
Откройте проект вашего приложения в XCode, перейдите к настройкам проекта. Необходимо, чтобы Bundle Identifier совпадал с BundleID, который вы указали при создании AppID. Также необходимо отключить функцию автоматического управления подписыванием в XCode. В выпадающем списке Provisioning Profile выберите тот, который недавно создали.
Обратите внимание: без всех необходимых иконок (в том числе иконка для магазина со стороной 1024 точки) сборка приложения не пройдет автоматическую проверку в iTunes Connect.
Теперь проект можно собрать и отправить в iTunes Connect. Для этого нужно нажать меню Product — Archive. По итогу сборки будет показано окно органайзера XCode, нажмите там кнопку «Upload To App Store»:
Открывается окно настроек выгрузки в App Store. Подробнее про bitcode, symbols stripping. Оставляем настройки без изменений.
На следующем шаге нужно выбрать provisioning profile из выпадающего списка подходящих:
Затем XCode подготовит архив для выгрузки в iTunes Connect. На этом экране обратите внимание на те параметры, что мы установили. Нажмите Upload.
В зависимости от скорости соединения нужно будет подождать некоторое время. Если все в порядке, XCode сообщит об успешном завершении выгрузки в iTunes Connect. Можно переходить к последнему этапу.
Отправка на ревью
В iTunes Connect на вкладке Activity можно увидеть отправленную сборку. Для проектов на Swift автоматическая проверка сборки занимает примерно полчаса. До тех пор сборка будет со статусом Processing:
После окончания проверки сборка доступна для выбора на странице информации о версии приложения:
После этого у приложения в iTunes Connect появится иконка. Сохраните изменения. Теперь можно отправить сборку на ревью.
Готово! Вы сделали все, что могли. Ждите ответа в течение нескольких дней. Не забудьте, что с 23 по 27 декабря iTunes Connect на каникулах. Разработчики не смогут обновлять и добавлять новые приложения в App Store и изменять ценники. Все остальные функции iTunes Connect будут доступны.
Распространение приложения под iOS внутри компании (Enterprise Distribute iOS App in-house)
(Осторожно, под катом трафик)
Подготовка и распространение приложения IOS внутри компании весьма непростая задача, особенно когда приложение написано на Windows с использованием Visual studio, а большинство туториалов в интернете описывают исключительно MacOS с использованием Xcode. Однако после часов сражения с детищем Apple, нам удалось свершить казалось бы невозможное, а именно: скрестить жирафа с носорогом собрать IOS приложение на Xamarin в архив Xcode, сразу на MacOS, после получить нужные файлы для распространения, и в завершении создать ссылку, по которой будет распространяться приложение.
Да, на слух вроде не очень сложно. Однако когда дело касается разработки приложений под устройства Apple, всё становится в несколько раз непонятней и сложней. И после триумфальной, но нелёгкой победы, нам захотелось оставить свой след в истории, написав сей туториал.
1 Шаг. Создание сертификата.
1. Сперва, на Mac, нужно создать запрос для создания сертификата. Для этого нужно открыть keychain access, например, через поиск:
3. В появившемся окне заполняем поля “User Email Address” – свою электронную почту, и “Common Name” – имя ключа. А также выбираем пункт “Saved to disk”, чтобы сохранить файл запроса на компьютер. И нажимаем кнопку “Continue”:
4. Далее появится окошко, в котором нужно указать название файла запроса и выбор пути для сохранения файла. Вносим нужные изменения и сохраняем:
5. После успешного сохранения появится следующее окно. Нажимаем “Done”:
6. После мы можем увидеть, что создался файл запроса в месте сохранения (в данном примере на рабочем столе). Или мы можем увидеть созданный ключ в списке ключей в “keychain access”:
7. Далее нам надо создать сертификат, это мы сможем сделать на сайте Apple для разработчиков, войдя в свой аккаунт:
8. После успешного входа в аккаунт мы переходим в “Certificates, IDs & Profiles”, так же на странице сертификатов нужно убедиться, что выбрано “IOS, tvOS, watchOS”:
9. Далее на странице, в разделе “Certificates”, нужно выбрать “Production”:
10. На странице нажимаем на кнопку с изображением “+”, чтобы создать сертификат. Появится страничка, на которой надо выбрать тип создаваемого сертификата:
11. В данном примере нас интересует метод дистрибьюции In-House, поэтому типом сертификата нужно выбрать “In-House and Ad Hoc”. После нажать кнопку “Continue”:
12. После мы перейдём к следующей странице создания сертификата на которой будет описано как создать запрос на MacOS для сертификата. Мы уже создали этот запрос в предыдущих пунктах. Нажимаем кнопку “Continue”:
13. На следующем этапе вам потребуется загрузить файл запроса, который мы создали ранее на рабочем столе. После успешной загрузки нажмите “Continue”:
14. После произойдёт генерация сертификата, и на следующей странице его можно будет скачать на компьютер:
15. Скачиваем сертификат, в данном примере на рабочий стол. Так же мы можем увидеть созданный сертификат на сайте:
Как мы можем видеть, по итогу мы успешно получили сертификат. Следующим шагом будет создание ID приложения.
2 Шаг. Создание Apps ID.
На предыдущем шаге мы успешно создали сертификат, теперь нам нужно создать Apps ID. Для этого нужно:
1. На сайте Apple для разработчиков, в своём аккаунте перейти сперва в “Certificates, IDs & Profiles”, так же на странице сертификатов нужно убедиться, что выбрано “IOS, tvOS, watchOS”:
2. Далее на странице, в разделе “Identifiers”, нужно выбрать “App IDs”:
3. На странице нажимаем на кнопку с изображением “+”, чтобы создать App ID. Появится страничка, на которой надо выбрать настройки создаваемого ID. Настройки ID индивидуальны для вашего приложения, единственное важное уточнение – в графе App ID Suffix нужно выбрать Explicit App ID:
4. После создания App ID, его можно увидеть на сайте:
По итогу двух шагов, мы успешно получили сертификат и создали App ID. Далее нам надо при помощи созданного сертификата создать Provisioning Profiles. И это приводит нас к следующему шагу “3 Шаг. Создание Provisioning Profiles”.
3 Шаг. Создание Provisioning Profiles.
На предыдущем шаге мы успешно создали сертификат, теперь нам нужно с его помощью создать Provisioning Profiles. Для этого нужно:
1. На сайте Apple для разработчиков, в своём аккаунте перейти сперва в “Certificates, IDs & Profiles”, так же на странице сертификатов нужно убедиться, что выбрано “IOS, tvOS, watchOS”:
2. Далее на странице, в разделе “Provisioning Profiles”, нужно выбрать “ Distribution”:
3. На странице нажимаем на кнопку с изображением “+”, чтобы создать Provisioning Profiles. Появится страничка, на которой надо выбрать тип создаваемого профайла:
4. В данном примере нас интересует In-House метод дестрибьюции, соответственно выбираем тип профайла “In House” и нажимаем на кнопку “Continue”:
5. На следующей странице нужно выбрать ранее созданный, на шаге 2, App ID:
6. После нажатия кнопки “Continue” мы перейдём к выбору сертификата, мы создали его на 1 шаге. Далее нажимаем на кнопку “Continue”:
7. На следующей странице нам надо заполнить поле с именем профайла и проверить данные перед генерацией профайла:
8. После профайл будет сгенерирован и его можно будет скачать:
9. Скачиваем Provisioning Profile, в данном примере на рабочий стол. Так же мы можем увидеть созданный provisioning profile на сайте, и увидеть, что он активен:
По итогу 3 шагов мы успешно создали Provisioning Profile.
1. Для этого нам потребуется приложение Xamarin в Visual Studio, которое будет подключено к Mac:
2. В решение нужно выбрать проект IOS, нажав на него правой кнопкой мыши. В появившемся меню выбрать “Properties”. В открывшемся окне выбрать пункт “ios bundle setting”. Далее выбрать в “bundle setting” – “manual provisioning”, а ниже в графе “manual provisioning” выбрать свой сертификат и профайл который мы создали на предыдущих этапах:
3. В проекте IOS нужно выбрать файл Info.plist и убедится что “bundle identifier” совпадает с нужным App ID:
Команда: msbuild /p:Configuration=Release /p:ServerAddress=10.211.55.2 /p:ServerUser=xamUser /p:Platform=iPhone /p:ArchiveOnBuild=true /t:»Build» MyProject.csproj
При помощи их мы сможем распространять своё приложение минуя AppStore, например, внутри компании. Далее нам надо нажать кнопку “Distribute App”. В появившемся меню выбрать “Enterprise” и нажать кнопку “Next”:
7. Далее нужно выбрать устройства, на которые можно распространять и обязательно выбрать “include manifest for over-the-air installation”, для того чтобы можно было скачать приложение из браузера:
9. На следующем этапе нам нужно выбрать созданные сертификат и Provisioning Profile:
10. После мы увидим успешно собранное приложение, и мы должны выбрать куда сохранить папку с приложением, которое мы после будем распространять:
5 Шаг. Распространение приложения
На предыдущих шагах мы подготовили наше приложение к распространению. На данном шаге мы создадим простой html файл с ссылкой и выложим её на локальный IIS, это делается для упрощения примера, но местоположение ссылки роли не играет. Не в рамках примера ссылку
можно разместить на собственном сайте, чтобы она была доступно сотрудникам, как и файлы приложения, следует размещать на собственном сервере. Однако в этом примере, как упоминалось ранее, мы использовали сервис dropbox.
2. После создаём html файл, следующего содержания:
3. Далее выкладываем этот html файл на локальный IIS (или ваш сайт), и пройдя по данной ссылке с мобильного устройства нам предложат установить приложение. После установки приложения пользователю нужно подтвердить доверие сертификату на устройстве Settings → General → Device Management → «Enterprise Name» тогда только пользователи смогут открыть приложение:
Руководство по работе с Apple Push Notification Service
Статья представляет собой вольный перевод руководства по работе с Apple Push Notification Service сайта raywenderlich.com и некоторые мои дополнения.
iOS-приложения не могут долгое время находиться в фоновом режиме. В целях сохранения заряда батареи приложениям, работающим в фоне, разрешено выполнять ограниченный набор действий.
Но что если происходит что-то интересное и вы хотите сообщить об этом пользователям, даже если ваше приложение у них не запущено?
Например, пользователь получил ответ в Твиттере, или его любимая команда выиграла игру, или его обед готов. Так как приложение не запущено, оно не может проверить и получить эти данные.
К счастью, корпорация Apple предусмотрела решение этой проблемы. Вместо того, чтобы беспрерывно проверять события или производить какие-либо действия в фоновом режиме, вы можете создать серверную сторону приложения, которая будет выполнять эти действия.
А когда наступит интересующее событие, серверная сторона сможет отправить приложению push-уведомление! Абсолютно любое push-уведомление может выполнять следующие три действия:
Краткий обзор
Схема работы механизма push-уведомлений:
После установки приложения появится всплывающее сообщение с подтверждением принятия push-уведомлений.
Стоит ли по-прежнему использовать push-уведомления, если уже в iOS 4.0 появились локальные уведомления и мультизадачность? Ещё бы!
Локальные уведомления — это ограниченные по времени события. Только VOIP-приложения, навигация и фоновое воспроизведения звука обладают возможностью неограниченного фонового выполнения. Если необходимо уведомить пользователей приложения (пока оно закрыто) о каком-либо внешнем событии, вы всё ещё должны использовать push-уведомления.
В этом руководстве будет детально описана работа системы push-уведомлений и как её интегрировать в своё приложение.
Что необходимо для push-уведомлений
Для интеграции push-уведомлений в приложение необходимо:
iPhone, iPad или iPod touch. Push-уведомления не работают в симуляторе, поэтому для тестирования нужен девайс.
Регистрация в iOS Developer Program. Для каждого приложения, в котором будет интегрирован механизм push-уведомлений, необходимо создать новый App ID и provisioning profile, а также SSL-сертификат для сервера. Эти действия выполняются на iOS Provisioning Portal.
Если хотите полностью выполнять примеры из этого руководства, вам необходимо создать provisioning profile и SSL-сертификат. Я в деталях объясню, как это сделать.
Для работы с push-уведомлениями дешёвого виртуального хостинга недостаточно. Вам необходимо запустить фоновое выполнение на сервере, установить SSL-сертификат, настроить исходящее TLS-соединение на определённых портах. Большинство провайдеров виртуального хостинга не позволят вам это сделать. Хотя если обратиться в службу технической поддержки, то вам, скорее всего, помогут решить все проблемы. Но всё же я настоятельно рекомендую использовать VPS.
Анатомия push-уведомлений
Ваш сервер ответственный за создание сообщений для push-уведомлений. Поэтому полезно знать, как эти сообщения выглядят.
Push-уведомление — это короткое сообщение, состоящее из токена девайса, полезной нагрузки (payload) и ещё некоторой информации. Полезная нагрузка — это актуальные данные, которые будут отправляться на девайс.
Ваш сервер должен преобразовать полезную нагрузку в JSON-словарь. Полезная нагрузка для простого push-сообщения выглядит следующим образом:
Блок, ограниченный фигурными скобками содержит словарь, который состоит из пар «ключ-значение» (так же, как и в NSDictionary).
Полезная нагрузка — это словарь, который состоит из, по крайней мере, одной пары «ключ-значение» «aps», значение которой само по себе является словарём. В примере выше «aps» содержит два поля: «alert» и «sound». Когда на девайс придёт push-уведомление, отобразится всплывающее сообщение с текстом «Hello, world!» и будет воспроизведён стандартный звуковой сигнал.
Кроме этого, в «aps» можно добавить и другие поля для настройки уведомления. Например:
Теперь значение поля «alert» — это словарь. «action-loc-key» содержит альтернативный текст для кнопки «Запустить». Поле «badge» содержит число, которое будет отображено на бейдже иконки приложения. Push-уведомление не будет сопровождаться звуковым сигналом.
Есть довольно много способов формирования JSON полезной нагрузки. Вы можете изменить звуковой сигнал уведомления, добавить свои собственные поля. Дополнительную информацию можно найти на странице «Local and Push Notification Programming Guide» сайта разработчиков Apple.
Push-уведомления — это нечто довольно маленькое; размер полезной нагрузки не может превышать 256 байт. Это примерно столько же, сколько позволяет вместить в себя СМС или твит. Push-сервер не будет тратиться на переносы на новую строку и пробелы, а сгенерирует что-то наподобие этого:
Такое представление менее читаемо, однако предоставляет достаточно места для более ценной информации. APNS отклонит push-уведомления, чьи размеры превышают 256 байт.
Понимание push-уведомлений
Они не надёжны! Нет гарантий, что push-уведомления будут доставлены, даже если APNS примет их.
Как только ваш сервер сформировал push-уведомление, он безответно отправляет его в APNS. Нет способа узнать статус доставки уведомления конечному пользователю после отправки. Время доставки может варьироваться от нескольких секунд до получаса.
Кроме этого, у пользователей i-девайсов может не быть возможности получать push-уведомления всё время. Например, рядом нет Wi-Fi сети с доступом в интернет либо девайс может быть вообще выключен.
APNS будет пытаться доставить последнее отправленное уведомление, когда девайс станет доступен для приёма. Но эти попытки ограничены по времени. После тайм-аута push-уведомление будет потеряно навсегда!
Они могут быть дорогими! Добавить push-функционал в приложение довольно просто и недорого, если вы владеете данными. Однако если у вас много пользователей либо необходимо запрашивать данные, то затраты резко возрастают.
К примеру, вы без проблем сможете оповестить пользователей об изменении RSS-ленты, потому что вы контролируете ленту и знаете, когда будут внесены изменения — когда обновится контент на сайте — ваш сервер мгновенно отправит уведомление.
Но что если ваше приложение — это RSS-читалка, позволяющая пользователям вносить URL-адреса своих лент? В этом случае вам необходимо придумать механизм слежения за обновлением добавленных лент.
На практике это означает, что вашему серверу нужно постоянно проверять ленты на изменение. Если у вас много пользователей, то возможно, придётся установить дополнительные сервера для обработки всех процессов и поддержки стабильной пропускной способности. Для таких приложений, как RSS-читалка, реализация push-функционала может стать довольно затратной и не представлять ценности для вас.
Ладно, хватит теории. Настало время изучить процесс реализации всех этих push-вещей. Но до того, как приступать к самому «вкусному» — программированию! — нужно выполнить несколько скучных настроек на iOS Provisioning Portal. Что ж, давайте сделаем их настолько быстро, насколько это возможно.
Provisioning Profiles и Сертификаты
Для того чтобы подключить push-уведомления к приложению, необходимо подписать его правильно сконфигурированным provisioning profile. Кроме этого, вашему серверу необходимо соединиться с APNS при помощи SSL-сертификата.
Provisioning profile и SSL-сертификат тесно связаны друг с другом и действительны только для одного App ID. Это защита, гарантирующая, что только ваш сервер может отправлять push-уведомления пользователям вашего же приложения.
Как вы знаете, для разработки и релиза приложения используют разные provisioning profiles. Есть два типа push-сертификатов для сервера:
Генерация Certificate Signing Request (CSR)
Помните, как вы заходили на iOS Provisioning Portal и создавали сертификат разработчика (Development Certificate) после присоединения к iOS Developer Program? Следующие шаги будут аналогичными. Но всё же я советую выполнять их в точности, как будет описано ниже. У разработчиков большинство проблем с push-уведомлениями как раз и связано с сертификатами.
Цифровые сертификаты базируются на шифровании с использованием открытого-приватного ключа. Вам нет необходимости знать что-либо о шифровании при работе с сертификатами, но вы должны быть осведомлены в том, что сертификат всегда работает в паре с приватным ключом.
Сертификат — это общая часть этой пары ключей. Приватный ключ должен держаться в секрете. Владеете им только вы и никто другой не должен иметь доступ к нему. Отмечу, что невозможно использовать сертификат без приватного ключа.
Всякий раз когда вы запрашиваете цифровой сертификат, необходимо сделать запрос на его подпись (Certificate Signing Request [CSR]). Когда вы создадите CSR, новый ключ будет занесён в связку ключей (keychain). Затем необходимо отправить CSR в центр сертификации (в этом случае это iOS Developer Portal), который сгенерирует SSL-сертификат на основе информации из CSR.
Откройте утилиту «Связка ключей» («Приложения → Утилиты (Другие)») и выберите опцию «Запросить сертификат у бюро сертификации…».
Если вы не видите этой опции меню или появляется сообщение с текстом «Запросить сертификат у бюро сертификации с ключом» («Request a Certificate from a Certificate Authority with key»), тогда необходимо загрузить и установить WWDR Intermediate Certificate. Также необходимо проверить, чтобы ни один приватный ключ не был выделен.
Сейчас перед вами должно быть окно ассистента сертификации:
Здесь введите e-mail. Разработчики советуют в качестве электронной почты использовать такую же, которую вы использовали для регистрации в iOS Developer Program, но это не обязательно.
В качестве общего имени введите «PushChat». Вы можете ввести что угодно, но выберите что-нибудь описательное. Позже это позволит легко найти приватный ключ.
Установите переключатель «Сохранён на диске» и нажмите «Продолжить». Сохраните файл под именем «PushChat.certSigningRequest».
Создание App ID и SSL-сертификата
Для начала создадим новый App ID. Каждому приложению, использующему механизм push-уведомлений, необходим свой собственный уникальный ID.
Кликните на пункт «App IDs» в сайдбаре и нажмите на кнопку «New App ID».
Я заполнил поля следующим образом:
Description: PushChat
Bundle Seed ID: по умолчанию
Bundle Identifier: me.evgeniy.PushChat
Будет лучше, если вы укажите свой собственный Bundle Identifier — com.yoursite.PushChat — вместо моего. В Xcode-проекте необходимо установить такой же bundle ID.
Ещё несколько моментов: мы сгенерируем SSL-сертификат, который будет использовать ваш push-сервер для защищённого соединения с APNS. Этот сертификат связан с App ID. Сервер может посылать push-уведомления только вашему приложению и никакому другому.
После того, как был создан App ID, он появится в списке:
В колонках «Development» и «Production» напротив «Push Notification» есть два оранжевых кружка с надписью «Configurable». Это значит, что App ID может использовать push-уведомления, но их всё ещё необходимо настроить. Поэтому переходим по ссылке «Configure».
На появившейся странице ставим флажок напротив «Enable for Apple Push Notification service». Далее нажмите кнопку «Configure» в строке с Development Push SSL Certificate. Откроется окно «Apple Push Notification service SSL Certificate Assistant»:
Первое, что необходимо — это сгенерировать Certificate Signing Request. Мы уже сделали это, поэтому нажмите «Continue».
На следующем шаге необходимо загрузить CSR на сервер Apple. Выберите CSR-файл, который вы сгенерировали ранее и нажмите «Generate».
Генерация SSL-сертификата займёт несколько секунд. Когда будет готово, нажмите «Continue».
Для того, чтобы скачать сертификат, нажмите «Download» — он будет сохранён под именем «aps_development.cer». После нажмите «Done».
Теперь у нас есть валидный сертификат и механизм push-уведомлений доступен для разработки. Если необходимо, вы можете снова загрузить сертификат.
Когда ваше приложение будет готово к релизу, необходимо повторить весь процесс для генерации Production-сертификата. Все шаги аналогичны.
Замечание. Production-сертификат действителен в течении года, но вы можете пересоздать его до истечения срока.
Нет необходимости добавлять сертификат в связку ключей. Если же вы захотите это сделать, то кликните два раза по скачанному ранее файлу aps_development.cer (после этого сертификат будет ассоциирован с приватным ключом).
Создание Provisioning Profile
Зайдите на Provisioning Portal. Перейдите по ссылке «Provisioning» и нажмите на кнопку «New Profile».
Я заполнил поля следующим образом:
Нажмите «Submit» и profile будет сгенерирован. У нового profile будет установлен статус «Pending». Перезагрузите страницу и увидите, что статус изменился на «Active». Теперь вы можете скачать provisioning profile (файл с названием «PushChat.mobileprovision»).
Добавьте provisioning profile в Xcode перетянув файл на иконку IDE либо кликнув на файл два раза.
Если ваше приложение готово к релизу, то вам необходимо повторить описанный выше процесс для создания Ad Hoc или App Store distribution profile.
Простенькое приложение
Предыдущие действия не были по-настоящему захватывающими, но они обязательны для выполнения. Я хотел в деталях показать, как сгенерировать сертификат, потому что такие вещи разработчик делает не каждый день, а без них push-уведомления работать не будут.
Сейчас мы создадим простое приложение, которое будет принимать push-уведомления.
Откройте Xcode и создайте новый проект. В ассистенте выберите «Single View Application» и перейдите к следующему шагу.
Я заполнил поля следующим образом:
После создания проекта, откройте PCAppDelegate.m. Измените метод didFinishLaunchingWithOptions следующим образом:
Вызов registerForRemoteNotificationTypes сообщает iOS, что это приложение хочет получать push-уведомления.
Соберите и запустите приложение. Для этого необходимо использовать девайс, потому что симулятор не поддерживает push-уведомления. Xcode автоматически выберет новый provisioning profile. Если во время запуска приложения произошла ошибка, убедитесь, что в Code Signing Identity выбран правильный profile.
Когда запуститься приложение, появится сообщение с подтверждением принятия push-уведомлений.
Приложение запросит разрешение только один раз. Если пользователь нажмёт «OK», push-уведомления будут приходить, если «Запретить» — не будут. Своё решение можно изменить в настройках.
Название вашего приложения будет добавлено в настройки push-уведомлений. Здесь пользователь может включить или отключить push-уведомления для вашего приложения, а также индивидуально настроить бейджи, звуки и сообщения.
Ваше приложение может определить, какие типы push-уведомлений включены:
Существует ещё одна вещь, которую вы должны добавить в приложение для того, чтобы иметь возможность получать push-уведомления. Добавьте следующий код в PCAppDelegate.m:
Когда ваше приложение регистрируется на приём push-уведомлений, оно пытается получить токен девайса. Это 32-байтовый уникальный номер, который однозначно определяет ваш девайс. Токен девайса можно сравнить с адресом, на который будут приходить push-уведомления.
После запуска приложения на консоли Xcode отобразиться токен вашего девайса:
Токен — это непрозрачная двоичная структура данных, которая представляет собой объект типа NSData. Для наших целей достаточно знать 32-байтовый токен девайса. Токен можно представить в виде 64 шестнадцатеричных символов. Мы будем использовать именно такой формат.
Если запустить приложение на симуляторе, то вызовется метод didFailToRegisterForRemoteNotificationsWithError:, который выведет ошибку с информацией о том, что симулятор не поддерживает push-уведомления.
Мы закончили с приложением. Теперь давайте опробуем push-уведомления в действии!
Отправка push-уведомления
Как было описано ранее, для отправки push-уведомлений необходимо настроить сервер. Но для тестирования воспользуемся приложением для Mac OS PushMeBaby, которое также можно скачать с сервиса github.
Далее всё просто — открываем PushMeBaby в Xcode, добавляем в проект ранее созданный SSL-сертификат (aps_development.cer), после чего переходим к редактированию файла ApplicationDelegate.m. В методе init делаем следующие изменения:
Добавляем токен девайса, который отобразится в консоли Xcode после запуска приложения, созданного ранее:
Добавляем полезную нагрузку, о которой говорилось ранее (обязательно экранируем кавычки):
И задаём имя добавленного в проект SSL-сертификата:
Теперь запускаем приложение и нажимаем кнопку Push. В течении нескольких секунд вы должны получить push-уведомление.
Со стилем «Баннер» push-уведомление выглядит следующим образом:
Со стилем «Напоминание» более привычно:
Замечание. Уведомление не отобразится, если приложение запущено и активно на девайсе. Однако полезная нагрузка придёт в приложение и её можно обработать с помощью метода didReceiveRemoteNotification:
На этом всё. Все интересующие вас вопросы можно задать в комментариях; я постараюсь на них ответить.