# Сертифікат push-сповіщень Apple: .p8 чи .p12 з Expo

> Для push-сповіщень Apple пропонує ключ .p8 без терміну дії для всіх твоїх застосунків або річний сертифікат .p12. З Expo ключем керує EAS.

Оригінальна сторінка: [Сертифікат push-сповіщень Apple: .p8 чи .p12 з Expo](https://devoria.fr/uk/blog/apple-push-notification-certificate-p8-p12-expo)
Автор: [Mehdi Azizi](https://devoria.fr/uk/mehdi-azizi)
Опубліковано: 2026-11-04
Останнє оновлення змісту: 2026-11-04


Push-сертифікат Apple дозволяє серверу надсилати сповіщення твоєму застосунку через APNs, сервіс сповіщень Apple. Він буває у двох формах: сертифікат .p12, дійсний рік і прив'язаний до одного застосунку, або ключ .p8, який не має терміну дії і працює для всіх застосунків твого акаунта. **З Expo сертифікат тобі не потрібен: EAS пропонує створити ключ .p8 під час першого білда, і push-сервіс Expo використовує його за тебе.**

Гайд про [сертифікат розробника і provisioning profile](https://devoria.fr/uk/blog/ios-developer-certificate-provisioning-profile-expo) згадує push-ключ лише кількома рядками. Тут розбираємо все до кінця: вибір між двома форматами, середовища sandbox і production, поновлення та збої, через які сповіщення не працюють у TestFlight.

Я публікую свої застосунки з Expo та EAS. Solys і TradaZen оголошують плагін `expo-notifications` у своїй конфігурації: саме він готує застосунок до отримання сповіщень.

## Навіщо Apple вимагає сертифікат або ключ

Push-сповіщення виходить із сервера, твого або Expo, який передає його APNs, а APNs доставляє його на iPhone. Тож APNs має перевірити, що цей сервер має право писати твоєму застосунку. Apple пропонує два способи це довести.

- **З'єднання через токен, з ключем .p8.** [За словами Apple](https://developer.apple.com/documentation/usernotifications/establishing-a-token-based-connection-to-apns), воно швидше, його можна використовувати з кількох серверів, а один ключ покриває всі застосунки твоєї команди або їх частину. Твій сервер підписує ним токен, який треба оновлювати щонайменше щогодини.
- **З'єднання через сертифікат, з файлом .p12.** [Apple уточнює](https://developer.apple.com/documentation/usernotifications/establishing-a-certificate-based-connection-to-apns), що цей сертифікат прив'язаний до одного застосунку і дійсний рік. Кілька застосунків означає кілька сертифікатів.

[Сторінка Apple про терміни дії](https://developer.apple.com/support/expiration/) нагадує: ключ підпису токенів APNs ніколи не спливає.

## Таблиця .p8 / .p12

| Критерій            | Ключ .p8                     | Сертифікат .p12               |
| ------------------- | ---------------------------- | ----------------------------- |
| Термін дії          | Не спливає                   | Один рік                      |
| Охоплення           | Усі твої застосунки          | Один застосунок               |
| Середовище          | Обирається під час створення | Sandbox і production          |
| Поновлення          | Немає, крім відкликання      | Щороку                        |
| Завантаження        | Лише один раз                | Експорт із Mac                |
| Кількість           | Два на середовище            | Один на застосунок            |
| Використання з Expo | Створює і керує EAS          | Відсутній у документації Expo |

Три уточнення. Файл .p8 [можна завантажити лише раз](https://developer.apple.com/help/account/keys/create-a-private-key): Apple не зберігає його у твоєму акаунті. А .p12 [експортується зі зв'язки ключів Mac](https://developer.apple.com/help/account/capabilities/communicate-with-apns-using-a-tls-certificate), на якому створено сертифікат. І ліміт у два ключі на середовище стосується ключів команди. Для ключів, обмежених певними застосунками, Apple дозволяє до 200 на середовище.

[Сторінка Expo про облікові дані](https://docs.expo.dev/app-signing/app-credentials/) говорить лише про push-ключ і рахує щонайбільше два на акаунт, не розрізняючи середовищ і ключів для окремих застосунків. **Для застосунку на Expo ключ .p8 є правильним вибором.**

## Sandbox і production: два середовища

APNs має два сервери: development, який ще називають sandbox, і production. [Apple](https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns) відводить перший для тестів, а другий для опублікованих застосунків. Застосунок знає, який використовувати, завдяки entitlement `aps-environment`. [За словами Apple](https://developer.apple.com/documentation/bundleresources/entitlements/aps-environment), його значення залежить від профілю підпису: `development` з профілем розробки, `production` з профілем дистрибуції і для TestFlight.

**Отже, білд TestFlight звертається до production, так само як App Store.**

З боку Expo є дві деталі. [Документація expo-notifications](https://docs.expo.dev/versions/latest/sdk/notifications/) вказує, що entitlement у проєкті завжди записаний як `development`, а потім в архіві release-білда змінюється на `production`. А під час створення токен Expo прив'язується до середовища застосунку, яке визначається автоматично: під час надсилання тобі нічого не треба обирати.

Якщо створюєш ключ сам, Apple питає його середовище й охоплення: уся команда чи певні застосунки. Документація для розробників тепер описує ключі команди, обмежені sandbox або production, а старі ключі, дійсні всюди, досі приймаються. Натомість [довідка акаунта](https://developer.apple.com/help/account/capabilities/communicate-with-apns-using-authentication-tokens) досі стверджує, що ключ працює в обох середовищах. Apple сама собі суперечить: орієнтуйся на середовище, яке обираєш під час створення. **Ключ лише для sandbox не підійде ні для TestFlight, ні для App Store.**

## Як Expo керує push-ключем

Згідно з [гайдом із налаштування Expo](https://docs.expo.dev/push-notifications/push-notifications-setup/), оновленим 28 липня 2026 року, твій перший development-білд пропонує налаштувати push-сповіщення і згенерувати ключ APNs. Відповідай «так» на обидва питання. Без EAS Build запусти `eas credentials`. Потрібен платний акаунт Apple Developer.

Далі:

- **EAS зберігає ключ і прив'язує його до застосунку.** За словами Expo, один ключ працює для скількох завгодно застосунків, а завантаження нового не змінює токени Expo Push твоїх користувачів.
- **Твій сервер не звертається до APNs.** Він надсилає до push-сервісу Expo, який передає далі в APNs. [Expo просить тебе читати квитанції](https://docs.expo.dev/push-notifications/sending-notifications/) приблизно через 15 хвилин після надсилання: саме там показуються помилки.
- **Плагін додає entitlement.** Оголоси `expo-notifications` у `plugins`:

```json
{
  "expo": {
    "plugins": ["expo-notifications"]
  }
}
```

Дві пастки. [FAQ Expo](https://docs.expo.dev/push-notifications/faq/) каже, що Expo Go більше не підтримує push-сповіщення починаючи з SDK 53, тоді як сторінка expo-notifications говорить лише про Android. В обох випадках Expo радить development-білд: тестуй на ньому. І видалення ключа через `eas credentials` прибирає його із серверів Expo, але не з твого акаунта Apple. Щоб звільнити місце, відклич його на порталі Apple. Як і будь-який секрет, файл .p8 ніколи не має потрапити у твій репозиторій: правило таке саме, як для [API-ключів застосунку на Expo](https://devoria.fr/uk/blog/secret-api-key-expo-app-what-to-protect).

## Поновлення: що насправді спливає

**Ключ .p8 не треба поновлювати.** Він перестає працювати, лише якщо ти його відкличеш. Якщо вважаєш, що його скомпрометовано, [Apple радить](https://developer.apple.com/help/account/capabilities/communicate-with-apns-using-authentication-tokens) створити новий ключ, перейти на нього і лише потім відкликати старий. Щоб замінити ключ в Expo, FAQ описує порядок дій: `eas credentials`, iOS, твій build-профіль, потім видалення push-ключа і генерація нового.

**Сертифікат .p12 спливає щороку.** Apple просить оновлювати його до кінця терміну і стежити за датою у зв'язці ключів. Коли він сплив або відкликаний, [ти більше не можеш надсилати сповіщення](https://developer.apple.com/help/account/certificates/certificates-overview) своєму застосунку. Окремого поновлення Apple не описує: ти створюєш новий сертифікат з ідентифікатора застосунку, встановлюєш його на сервер до кінця терміну, а потім прибираєш старий. **Найкраще поновлення: перейти на ключ.**

> Керуєш iPhone через Intune або інший інструмент керування парком пристроїв? Це інший сертифікат. Push-сертифікат для керування пристроями створюється на Apple Push Certificates Portal і поновлюється щороку. [Apple радить](https://support.apple.com/guide/deployment/dep2de55389a) записати, який акаунт Apple ти використав: він знадобиться для поновлення.

## Типові збої та як їх виправити

### Працює в розробці, але не в TestFlight

1. **Ти надсилаєш на неправильний токен.** Білд TestFlight реєструється в production і отримує новий токен. Токен із development-білда не працює: Apple відповідає `BadDeviceToken`, коли [токен не відповідає середовищу](https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns). Бери токен із самого застосунку з TestFlight.
2. **У production-застосунку немає push-облікових даних.** Це діагноз із FAQ Expo. Перевір сторінку облікових даних проєкту на expo.dev або `eas credentials`.
3. **Твій ключ обмежений sandbox.** Заміни його на ключ, дійсний для production.
4. **iPhone не отримує токен.** Якщо ти встановив білд TestFlight поверх білда з Xcode, Expo радить перезавантажити пристрій.

### «No valid aps-environment entitlement string found»

За FAQ Expo, ця помилка означає, що для твого iOS-проєкту не налаштовано жодного push-ключа. Перевір сторінку облікових даних, потім запусти білд знову: EAS запропонує згенерувати ключ. Також перевір, що `expo-notifications` справді є в `plugins`.

### ITMS-90078: Missing Push Notification Entitlement

Apple надсилає цей лист після завантаження: твій застосунок, схоже, реєструється в APNs, але його підпис не містить entitlement `aps-environment`. [Нотатка Expo про SDK 51](https://github.com/expo/fyi/blob/main/apns-entitlement-sdk-51.md) це пояснює. Починаючи з цього SDK, entitlement додається лише якщо встановлено `expo-notifications`. Попередження виникає через дві перевірки Apple. Перша порівнює можливості (capabilities) ідентифікатора застосунку з entitlements застосунку. Друга знаходить у бінарнику метод реєстрації сповіщень, який код Expo містить у всіх застосунках.

**Це попередження, а не відмова**, уточнює Expo. Якщо ти використовуєш сповіщення, додай плагін і зроби новий білд: [EAS синхронізує можливості](https://docs.expo.dev/build-reference/ios-capabilities/) ідентифікатора застосунку під час кожного білда. Якщо ні, прибери можливість Push Notifications з ідентифікатора на порталі Apple. Попередження може залишатися, без наслідків.

### InvalidCredentials або всі застосунки замовкли водночас

`InvalidCredentials` у квитанції означає, що твої push-облікові дані більше не дійсні, часто тому, що ключ відкликали. Усі застосунки, які його використовували, замовкають одночасно. Рішення від Expo: `eas credentials`, потім новий ключ. Якщо квитанція згадує `InvalidProviderToken`, Expo радить зробити новий білд, перегенерувавши push-ключ і профіль.

## Перед тим як вмикати сповіщення

Щоб протестувати сповіщення на своєму iPhone до релізу, скористайся гайдом [TestFlight для тестування застосунку](https://devoria.fr/uk/blog/testflight-testuvannya-zastosunku-iphone). Якщо надсилаєш тихі сповіщення, щоб розбудити застосунок, перечитай [guideline 2.5.4 про фонові режими](https://devoria.fr/uk/blog/guideline-2-5-4-background-mode-rejected). Увесь ланцюжок без Mac описано в статті [як опублікувати iOS-застосунок без Mac](https://devoria.fr/uk/blog/publish-ios-app-without-mac-expo-eas), а етапи релізу на сторінці [публікація застосунку в App Store](https://devoria.fr/uk/expertise/publish-an-app-on-the-app-store).

Перед першим надсиланням пройди [безкоштовну діагностику](https://devoria.fr/uk/diagnostic): вона покаже, що блокує твій проєкт, і надішле тобі мій чекліст проти відмов Apple. Щоб створити застосунок, підключити підписки й опублікувати його, [iOS & Android Kit](https://devoria.fr/uk/kits/ios) проводить тебе через чотири етапи зі стартовим кодом моїх застосунків, у твоєму темпі.

## Поширені запитання

### Чи спливає push-сертифікат Apple?

Сертифікат .p12 спливає через рік, і сповіщення перестають працювати, якщо його не замінити. Ключ .p8 ніколи не спливає: він перестає працювати, лише якщо ти його відкличеш. Це головна причина обрати ключ.

### Чи потрібен окремий push-сертифікат для кожного застосунку?

Із сертифікатом .p12 так: кожен сертифікат прив'язаний до одного застосунку. Ключ .p8 працює для всіх застосунків твого акаунта. Тож з Expo один ключ може покрити весь твій каталог.

### Як поновити push-сертифікат Apple?

Створи новий сертифікат з ідентифікатора застосунку з новим запитом на підпис, встанови його на сервер, потім прибери старий. Зроби це до кінця терміну. Найпростіше перейти на ключ .p8, який не треба поновлювати.

### Я загубив файл .p8, що робити?

Apple дозволяє завантажити його лише раз. Якщо ключ створив EAS, Expo його зберігає, і сповіщення працюють далі. Інакше створи новий ключ, додай його через `eas credentials`, потім відклич старий на порталі Apple. Токени Expo Push твоїх користувачів не зміняться.

### Чи треба робити новий білд після зміни push-ключа?

Зазвичай ні. Ключ потрібен серверу, який надсилає, а не встановленому застосунку, і Expo зазначає, що новий ключ не змінює токени. Виняток: якщо квитанції повідомляють про `InvalidProviderToken`, Expo радить зробити новий білд із новим ключем і новим профілем.


## Твій проєкт

[Review Kit](https://devoria.fr/uk/kits/app-review): Мій чекліст для перевірки в App Store, виправлені відмови Apple, чекліст для Google Play і три скіли для Claude Code. 2 499 ₴.

[iOS & Android Kit](https://devoria.fr/uk/kits/ios): Створи свій застосунок для iPhone і Android з Claude Code: стартовий код моїх застосунків, шлях до публікації в сторах і всі кіти. 4 999 ₴.

[Діагностика: що відділяє тебе від твого застосунку для iPhone](https://devoria.fr/uk/diagnostic): 7 запитань, 60 секунд: ти дізнаєшся, що насправді заважає тобі опублікувати застосунок для iPhone, отримаєш свій шлях у 4 кроки і кіт, який тобі підходить.