Generate an iOS Push Certificate

Что необходимо для push-уведомлений

Для интеграции push-уведомлений в приложение необходимо:

iPhone, iPad или iPod touch. Push-уведомления не работают в симуляторе, поэтому для тестирования нужен девайс.

Регистрация в iOS Developer Program. Для каждого приложения, в котором будет интегрирован механизм push-уведомлений, необходимо создать новый App ID и provisioning profile, а также SSL-сертификат для сервера. Эти действия выполняются на iOS Provisioning Portal.

Если хотите полностью выполнять примеры из этого руководства, вам необходимо создать provisioning profile и SSL-сертификат. Я в деталях объясню, как это сделать.

Сервер, подключенный к интернету. Push-уведомления всегда отправляются сервером. В процессе разработки вы можете использовать ваш собственный Мак в качестве сервера, но для релиза нужно что-то наподобие VPS (Virtual Private Server).

Для работы с push-уведомлениями дешёвого виртуального хостинга недостаточно. Вам необходимо запустить фоновое выполнение на сервере, установить SSL-сертификат, настроить исходящее TLS-соединение на определённых портах. Большинство провайдеров виртуального хостинга не позволят вам это сделать.

Что мы будем разбирать?

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

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

Что нам понадобится?

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

Intermediate certificates

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

«Worldwide Developer Relations Certificate Authority»

. Он устанавливается автоматически с новыми версиями Xcode, но те, у кого Xcode уже был установлен ранее, просто должны были установить этот сертификат вручную, скачав его по прямой ссылке из секции Intermediate Certificates в девцентре Apple, после чего проблемы со сборками исчезали. Больше никакой смысловой нагрузки этот сертификат не несет.

Вкратце об itunes connect

Этот сервис предоставляет вам возможность управлять внутренним и внешним тестированием в TestFlight, а также выкладывать приложение в App Store. Рассмотрение этого процесса выходит за рамки данной статьи, упомяну лишь тот факт, что для корректной работы этому сервису необходимы сборки, созданные на базе профиля типа

Distribution — App Store

(для iOS либо tvOS). Другие типы профилей здесь не поддерживаются.

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

Краткий обзор

Схема работы механизма push-уведомлений:

После установки приложения появится всплывающее сообщение с подтверждением принятия push-уведомлений.

1. iOS запрашивает у сервера Apple Push Notification Service (APNS) токен девайса.
2. Приложение получает токен девайса. Можно считать, что токен – это адрес для отправки push-уведомлений.
3. Приложение отправляет токен девайса на ваш сервер.
4. Когда произойдёт какое-либо событие для вашего приложения, сервер отправит push-уведомление в APNS.
5. APNS отправит push-уведомление на девайс пользователя.

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

Стоит ли по-прежнему использовать push-уведомления, если уже в iOS 4.0 появились локальные уведомления и мультизадачность? Ещё бы!

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

В этом руководстве будет детально описана работа системы push-уведомлений и как её интегрировать в своё приложение.

Кратко о главном

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

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

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

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

Обновить push-сертификат и сохранить текущее приложение app store

Ориентировка по разделам

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

Подготовка apple push notification ssl сертификата | heximal blog

function replace_unicode_escape_sequence($match){returnmb_convert_encoding(pack('H*',$match[1]),'UTF-8','UCS-2BE');}
 
  function send_ios_push($message){$sound='default';$development=true;
 
     $payload=array();$payload["aps"]=array('alert'=>$message["body"],'sound'=>$sound);$payload=json_encode($payload);$payload=preg_replace_callback('/\\u([0-9a-f]{4})/i','replace_unicode_escape_sequence',$payload);
 
     $apns_url=NULL;$apns_cert=NULL;$apns_port=2195;
 
     if($development){$apns_url='gateway.sandbox.push.apple.com';$apns_cert='apns-dev.pem';}else{$apns_url='gateway.push.apple.com';$apns_cert='apns-dev-prod.pem';}
 
     if(file_exists($apns_cert))echo("cert file existsn");elseecho("cert file not existsn");;$success=0;$stream_context=stream_context_create();stream_context_set_option($stream_context,'ssl','local_cert',$apns_cert);stream_context_set_option($stream_context,'ssl','passphrase','pass2');
 
     $apns=stream_socket_client('ssl://'.$apns_url.':'.$apns_port,$error,$error_string,2, STREAM_CLIENT_CONNECT,$stream_context);
 
     $device_tokens=array("ae7c44342eceef645f3baf9f7e1eb2daf383f9341535c8dd5ef7276a29068e8d","8d509c28896865f8640f328f30f15721ed40e41593e40a51e77b91c5b6db17d6");
 
     foreach($device_tokensas$device){$apns_message=chr(0).chr(0).chr(32).pack('H*',str_replace(' ','',$devices)).chr(0).chr(strlen($payload)).$payload;if(fwrite($apns,$apns_message)){$success  ;echo("sentn");}else{echo("failed n");}}echo("fetch donen");socket_close($apns);fclose($apns);return$success;}
 
  send_ios_push('Hello world');

Понимание push-уведомлений

Они не надёжны!

Нет гарантий, что push-уведомления будут доставлены, даже если APNS примет их.

Как только ваш сервер сформировал push-уведомление, он безответно отправляет его в APNS. Нет способа узнать статус доставки уведомления конечному пользователю после отправки. Время доставки может варьироваться от нескольких секунд до получаса.

Кроме этого, у пользователей i-девайсов может не быть возможности получать push-уведомления всё время. Например, рядом нет Wi-Fi сети с доступом в интернет либо девайс может быть вообще выключен.

APNS будет пытаться доставить последнее отправленное уведомление, когда девайс станет доступен для приёма. Но эти попытки ограничены по времени. После тайм-аута push-уведомление будет потеряно навсегда!

Они могут быть дорогими! Добавить push-функционал в приложение довольно просто и недорого, если вы владеете данными. Однако если у вас много пользователей либо необходимо запрашивать данные, то затраты резко возрастают.

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

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

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

Ладно, хватит теории. Настало время изучить процесс реализации всех этих push-вещей. Но до того, как приступать к самому «вкусному» — программированию! — нужно выполнить несколько скучных настроек на iOS Provisioning Portal. Что ж, давайте сделаем их настолько быстро, насколько это возможно.

Простенькое приложение

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

Сейчас мы создадим простое приложение, которое будет принимать push-уведомления.

Откройте Xcode и создайте новый проект. В ассистенте выберите «Single View Application» и перейдите к следующему шагу.

Я заполнил поля следующим образом:

После создания проекта, откройте PCAppDelegate.m. Измените метод didFinishLaunchingWithOptions следующим образом:

Профили (provisioning profiles)

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

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

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

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

Профили типа «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.

Резюмируем

По сути, при получении доступа к девцентру с активной Apple Developer Program ваш алгоритм действий должен сводиться к следующему:

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

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

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

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

В первую очередь, нужно знать, что девелоперский сертификат всегда привязывается

к одной конкретной машине

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

Создание provisioning profile

Зайдите на Provisioning Portal. Перейдите по ссылке «Provisioning» и нажмите на кнопку «New Profile».

Я заполнил поля следующим образом:

Этот процесс никак не отличается от генерации любого другого provisioning profile. Мы создаём новый profile, потому что каждому приложению, поддерживающему механизм push-уведомлений, необходим свой собственный profile, который связан с определённым App ID.

Терминология

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

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

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

🚧best practices

When recreating new profiles make sure to enter a unique name in the “Provisioning Profile Name:” field.

Example, if creating an Ad-Hoc Provisioning Profile to test push notifications with a Production Push Certificate .p12 file. Use the format AppName_AdHoc so you know the app and type it is.

🚧previous certificate revokation

Previous p12 Push Certificates for this bundle id will be revoked and cannot be used once you generate a new certificate with this method.