2026년 Expo Push Notification 가이드

앱이 작동하는 지점에서, 사용자가 로그인 한 후, 제품이 재참여 흐름을 원할 때, native한 느낌을 주는 카트 리마인더, 리뷰 프로모트, 새로운 메시지 알림, 릴리스 발표와 같은 흐름을 구현하고 싶을 것입니다. 첫 번째 직관은 종종 "push"를 "just wire up"하는 것입니다. 그러나 한 주 후에, 디버깅을 시작할 때, 시뮬레이터가 정상적으로 등록되는 것처럼 보이지만, nobody가 왜 탭이 올바른 화면을 열지 않는지 설명할 수 없을 때, 문제가 발생합니다.

엑스포 푸시 알림은 간단하게 느껴질 수 있지만, 실제로는 매우 취약할 수 있습니다.

엑스포는 React Native 팀에게 APNs 및 FCM에 대한 실용적인 층을 제공합니다. 이는 많은 팀이 사용하는 이유입니다. 그러나 데모와 프로덕션 준비된 구현 사이의 격차는 실제입니다. 토큰 라이프 사이클, 권한 타이밍, 리스너 설정, 페이로드 디자인, 백엔드 클린업 등 모든 것이 중요합니다. 만약 빈번한 앱 로직 변경을 shipping하고 있다면, 신뢰할 수 있는 메시징 및 릴리스 속도에 의존하는 경우, 운영적 규율이 더욱 중요해집니다. 이는 신뢰할 수 있는 메시징 및 릴리스 속도에 의존하는 경우, 운영적 규율이 더욱 중요해집니다. 모바일 앱 사용자 유지 관리 작업: 사용자 경험을 예측할 수 있는 환경이 제공되는 경우만 유용합니다.

내용 목록

사용자와 Expo 푸시 알림에 대한 매력적인 기초
- Expo가 실제로 추상화하는 것
- 실제 프로덕션 준비가 무엇을 의미하는지
초기 프로젝트 설정 및 구성
권한 요청 및 푸시 토큰 캡처
서버에서 알림을 보내는 방법
앱에서 들어오는 알림을 처리하는 방법
생산 환경에서 최적의 방법과 일반적인 오류

Expo 푸시 알림을 사용하는 사용자와의 상호 작용의 기초

Expo 푸시 알림 설정은 주된 이유는 하나만이 있습니다. native 메시징 복잡성을 제거하여 팀이 첫 번째 날에 소유하고 싶지 않습니다. APNs 및 FCM 플러밍을 직접 구축하는 대신, Expo 게이트웨이와 함께 작업하여 제품 동작, 경로, 권한 UX 및 백엔드 메시지 논리에 집중할 수 있습니다. 추상화는 푸시가 "진짜"가 아니라는 것을 만들지 않습니다. 단지 엔지니어링 노력을 어디에 사용할지 바꾸는 것입니다.

서비스도 빠르기 때문에 성능이 일반적으로 걱정되는 첫 번째 문제가 아닙니다. 2023년 3월 14일부터 2023년 6월 12일까지 Expo 푸시 알림 __CAPGO_KEEP_0__의

The service is also fast enough that performance usually isn’t the first thing to worry about. From March 14, 2023 through June 12, 2023, Expo’s push notification API showed a 273 밀리초의 p99 지연 시간, 273 millisecond p99 latency그리고 0.17%의 평균 일일 오류율 전체 HTML 텍스트 조각에서 더 긴 Capgo UI 문자열 (부모 키 `capwesome_diff_experience_capgo`). 페이지/영역: Capawesome 비교 페이지. 역할: 장기 마케팅 또는 법적 문단. 페이지 capwesome.astro를 보존. Capgo 제품/브랜드 및 개발자 용어를 정확하게 보존. 수십만 개의 일일 메시지에 따르면 Knock의 Expo 푸시 API 벤치마크 분석. 이는 프로토 타입에만 적합한지 여부에 대해 의문을 품는 팀을 위로할 것입니다.

Expo가 실제로 추상화하는 것

팀이 "Expo 푸시"라고 말할 때, 그들은 종종 여러 개의 별개의 문제를 함께 묶어 말합니다:

Provider 라우팅: Expo는 메시지를 APNs로 전달합니다 iOS와 FCM Android를 위한.
토큰 형식: 서버에서는 Expo Push Token을 관리하는 대신 플랫폼에 특정한 토큰 처리를 먼저 관리하지 않습니다.
요청 계약: Expo의 푸시 API로 페이로드를 POST하는 대신 네이티브 제공자 API에 직접 통합하지 않습니다.

그것은 도움이 되지만 Expo가 모든 전달 문제를 소유한다고 가정하는 일반적인 오해를 만듭니다. 실제로 많은 실패는 앱 code,陈舊한 토큰, 잘못된 페이로드, 또는 권한 흐름이 좋지 않음으로부터 발생합니다.

실용적인 규칙: Expo를 신뢰할 수 있는 전송層로 간주하고 클라이언트 및 백엔드 설계에 대한 좋은 대안으로 간주하지 마십시오.

생산성 준비가 무엇을 의미하는가

작동하는 데모는 단지 한 기기에서 한 페이로드를 한 번 수락했음을 증명합니다. 생산성 준비는 다른 것을 의미합니다:

관심사	데모 자세	생산 자세
권한	즉시 요청	사용자 가치가 명확한 후에 요청
토큰	한 번 저장	갱신, 중복 제거, 만료, 일치
페이로드	모든 것을 포함 `data`	페이로드를 작고 동작 지향적으로 유지
앱 동작	알림 표시	전면 상태를 처리하는 데 올바르게 이동
작업	수동 테스트	수령, 정리, 로그, 및 사고 처리

‘알림 전송’과 ‘실제 제품 워크플로우를 지원하는 알림’ 사이의 차이입니다.

초기 프로젝트 설정 및 구성

첫 번째 권한 요청 전 Expo push의 많은 고통은 프로젝트 구성이 엉망이면 시작됩니다. 만약 프로젝트 구성이 엉망이면 클라이언트 code가 올바르게 보일 수 있지만 빌드 간에 앱이 일관되지 않게 동작합니다.

목재 데스크 위에 현대적인 랩탑이 프로젝트 설정의 구성 code 파일을 표시하고 있습니다.

적절한 라이브러리 설치와 빌드 경로와 일치하는 개발 환경으로 시작하세요. Expo Go를 넘어서 작업하는 경우, 로컬 워크플로우를 커스텀 Expo 개발 클라이언트 설정과 일치시키는 것이 도움이 됩니다. 프로젝트 설정과 일치하는 개발 환경으로 시작하세요. Expo Go를 넘어서 작업하는 경우, 로컬 워크플로우를 커스텀 Expo 개발 클라이언트 설정과 일치시키는 것이 도움이 됩니다.because notification behavior often needs to be validated in a build that mirrors production more closely than a quick sandbox run.

알림 패키지를 설치하세요

최소한, 다음을 필요로 합니다:

expo-notifications 권한 요청, 토큰 취득, 리스너, 알림 표시를 위해
expo-device because you should guard token retrieval with Device.isDevice.

Typical install commands depend on your package manager, but the key is version alignment with your Expo SDK. Don’t mix arbitrary package versions. Let Expo resolve compatible ones.

프로젝트 수준 구성 추가

설정은 명확하게 유지하세요. 최소한의 app.json or app.config.js 알림은 앱 계약의 일부이므로, 후계품이 아닌 반드시 고려해야 합니다.

{
  "expo": {
    "name": "MyApp",
    "slug": "my-app",
    "plugins": ["expo-notifications"],
    "ios": {
      "bundleIdentifier": "com.example.myapp"
    },
    "android": {
      "package": "com.example.myapp"
    },
    "extra": {
      "eas": {
        "projectId": "your-project-id"
      }
    }
  }
}

몇 가지 세부 사항이 중요합니다:

Bundle 식별자 및 패키지 이름 앱을 실제로 배포해야 하는 것과 일치해야 합니다.
通知 플러그인 native 프로젝트가 빌드 중에 필요한 설정을 얻도록 보장합니다.
EAS 프로젝트 ID 토큰 취득이 앱이 올바른 Expo 프로젝트와 연관되어야 한다고 기대할 때 중요합니다.

알림 처리기를 일찍 설정하세요

대부분의 기본 튜토리얼은 알림 동작을 너무 늦게 정의합니다. 하지 마세요. 앱 시작 시 근처에 두세요. foreground 동작이 예측 가능합니다.

import * as Notifications from 'expo-notifications';

Notifications.setNotificationHandler({
  handleNotification: async () => ({
    shouldShowAlert: true,
    shouldPlaySound: false,
    shouldSetBadge: true,
  }),
});

팀은 foreground 알림이 경고를 표시하거나 소리를 재생하거나 배지에 영향을 미치는지 결정합니다. 정확한 동작은 제품에 따라 다릅니다. 채팅 앱과 결제 앱은 같은 선택을 하지 않습니다.

foreground 동작을 의도적으로 정의하지 않으면 팀은 실제로 받은 알림이 표시되지 않았지만 제품이 기대하는 대로 표시되지 않았기 때문에 '누락된' 알림을 디버깅하게 됩니다.

Android는 채널 구성이 필요합니다.

Android 알림 채널은 실제로 필수입니다. 채널을 생략하면 경고가 불일치하거나 사용자 기대와 일치하지 않을 수 있습니다.

import { Platform } from 'react-native';
import * as Notifications from 'expo-notifications';

export async function configureAndroidNotifications() {
  if (Platform.OS !== 'android') return;

  await Notifications.setNotificationChannelAsync('default', {
    name: 'Default',
    importance: Notifications.AndroidImportance.MAX,
  });
}

앱 초기화 중에 설정하세요. 그런 다음 채널 ID를 안정적으로 유지하세요. 채널 ID를 쉽게 변경하면 알림 동작을 추론하기 어려워집니다.

권한 요청 및 푸시 토큰 캡처

대부분의 팀은 Snippet에서 복사한 다음 나중에 후회합니다.

권한 요청에는 타이밍, 플랫폼 인식 및 일관된 비동기 처리가 필요합니다. 토큰 캡처는 물리적 장치에서만 발생해야 하며, 권한이 해결된 후에야 하며, 백엔드에 결과를 저장할 준비가 된 경우에만 발생해야 합니다.

엑스포 푸시 알림 토큰을 얻고 저장하는 과정의 단계별 다이어그램입니다.

클라이언트 함수가 기본값이 되어야 하는 함수

이 함수를 시작점으로 사용하세요:

import * as Device from 'expo-device';
import * as Notifications from 'expo-notifications';
import Constants from 'expo-constants';
import { Platform } from 'react-native';

type RegisterResult =
  | { ok: true; token: string }
  | { ok: false; reason: string };

export async function registerForExpoPushNotificationsAsync(): Promise<RegisterResult> {
  if (!Device.isDevice) {
    return { ok: false, reason: 'Push notifications require a physical device.' };
  }

  if (Platform.OS === 'android') {
    await Notifications.setNotificationChannelAsync('default', {
      name: 'Default',
      importance: Notifications.AndroidImportance.MAX,
    });
  }

  const permissions = await Notifications.getPermissionsAsync();
  let finalStatus = permissions.status;

  if (finalStatus !== 'granted') {
    const request = await Notifications.requestPermissionsAsync();
    finalStatus = request.status;
  }

  if (finalStatus !== 'granted') {
    return { ok: false, reason: 'Notification permission was not granted.' };
  }

  const projectId =
    Constants.expoConfig?.extra?.eas?.projectId ??
    Constants.easConfig?.projectId;

  if (!projectId) {
    return { ok: false, reason: 'Missing EAS project ID configuration.' };
  }

  const tokenResponse = await Notifications.getExpoPushTokenAsync({ projectId });

  return { ok: true, token: tokenResponse.data };
}

순서는 중요합니다. 장치 유형을 확인한 후 안드로이드 채널 동작을 설정하고 권한을 해결한 후 프로젝트 구성이 유효한지 확인한 후 엑스포 토큰을 요청해야 합니다.

왜 `Device.isDevice` 필수입니다

이것은 많은 잡음이 발생하는 것처럼 보이지만 위험하지 않은 몇 가지 실수 중 하나입니다. 전문 팀은 Device.isDevice 이 조건이 일 때만 권한 요청을 조건부로 요청합니다. 개발자들이 시뮬레이터 토큰을 잘못된 토큰으로 보내고 엑스포를 비난하는 것은 실제로는 앱 구성에 대한 설명이 있는 Eagerworks의 Expo 알림 구현 노트.

그것이 왜 함수의 상단에 위치하는지 이유는 간단합니다. 그것을 도우미 함수 뒤에 숨기지 마세요. 그것이 명확해야 합니다.

시뮬레이터 결과는 UI 테스트에 유용합니다. 그러나 푸시 토큰 등록을 확인하는 데 신뢰할 수 없습니다.

권한을 요청하는 시점을 올바르게 선택하세요.

스플래시 화면에서 요청하지 마세요. 사용자가 가치 이해하기 전에 요청하지 마세요. 일반적으로 사용자 동작이 알림 이점을 구체화 할 때, 예를 들어 배송 업데이트 활성화, 대화 참여, 또는 감시 중인 항목 저장과 같은 경우가 있습니다.

좋은 구현은 일반적으로 이 흐름을 따릅니다:

사용자가 의미 있는 기능 경계에 도달합니다.
앱이 알림의 가치를 자신의 UI에서 설명합니다.
앱이 시스템 권한을 요청합니다.
권한이 부여되면 앱은 백엔드에 즉시 토큰을 저장합니다.

그 마지막 단계에서 많은 앱이 실패합니다. 그들은 토큰을 검색하고 로컬로 로깅하고 백엔드 등록을 미루고 있습니다. 나중에 지원 팀은 어느 기기에서 어느 토큰이 어느 시점에 존재했는지 알 수 없습니다.

토큰 등록 후 저장하는 간단한 예제입니다.

export async function enablePushForCurrentUser(userId: string) {
  const result = await registerForExpoPushNotificationsAsync();

  if (!result.ok) {
    return result;
  }

  await fetch('https://api.example.com/push-tokens', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: 'Bearer user-session-token',
    },
    body: JSON.stringify({
      userId,
      token: result.token,
      platform: Platform.OS,
    }),
  });

  return result;
}

워크플로우의 나중에 이 walkthrough는 유용한 시각적 참조입니다:

릴리스-heavy 앱을 빌드하는 팀에게는 토큰 등록을 앱의 운영 상태의 일부로 생각하는 것이 도움이 됩니다. 이는 온보딩의 일부만으로 생각하는 것과 다릅니다. 이러한 마음가짐은 더 광범위한 Expo 앱 전달 워크플로우에서 앱 동작이 자주 변경되고 백엔드 상태가 동기화되어야 하는 경우에 잘 맞습니다.

서버에서 알림을 보내는 방법

백엔드에 유효한 Expo Push 토큰이 있는 경우 알림을 보내는 것은 간단합니다. 요청 자체가 어려운 것은 아닙니다. 하지만 payload에 무엇을 넣고 클라이언트 상태에 얼마나 신뢰할 것인지 결정하는 것이 어려운 것입니다.

Node-style 예제 fetch:

type ExpoPushMessage = {
  to: string;
  title: string;
  body: string;
  sound?: 'default' | null;
  data?: Record<string, unknown>;
};

export async function sendExpoPushNotification(token: string) {
  const message: ExpoPushMessage = {
    to: token,
    title: 'New review received',
    body: 'Tap to open the order details.',
    sound: 'default',
    data: {
      type: 'new_review',
      orderId: 'ord_123',
      screen: 'OrderDetails',
    },
  };

  const response = await fetch('https://exp.host/--/api/v2/push/send', {
    method: 'POST',
    headers: {
      Accept: 'application/json',
      'Accept-encoding': 'gzip, deflate',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(message),
  });

  const result = await response.json();
  return result;
}

payload 필드의 각 필드가 무엇을 해야 하는지

payload를 임의로 사용하지 마세요. 각 필드를 의도적으로 사용하세요.

필드	목적	컨텍스트: Capgo 마케팅 웹사이트. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 메시지 키 `subprocessors_table_purpose` (Subprocessors Table Purpose).
`to`	__CAPGO_KEEP_0__	__CAPGO_KEEP_0__
`title`	__CAPGO_KEEP_0__	__CAPGO_KEEP_0__
`body`	__CAPGO_KEEP_0__	__CAPGO_KEEP_0__
`sound`	__CAPGO_KEEP_0__	__CAPGO_KEEP_0__
`data`	__CAPGO_KEEP_0__	__CAPGO_KEEP_0__

__CAPGO_KEEP_0__ data __CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__ __CAPGO_KEEP_0____CAPGO_KEEP_0__ __CAPGO_KEEP_1__ __CAPGO_KEEP_0__ { "type": "new_review", "id": 123 } __CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__ __CAPGO_KEEP_1__
내용 생성과 전송을 분리하세요: 메시지 복사본을 한 층으로 만들고 Expo API 요청을 다른 층으로 만드세요.
invalidation feedback를 처리하세요: Expo가 나중에 보고하면 DeviceNotRegistered, 그 토큰이陈舊해졌다고 표시하고 무의식적으로 다시 시도하지 마세요.
웹 훅 디자인을 사용하세요: 시스템이 이미 이벤트를 내뱉고 있다면, notification triggers를 같은 종류의 백엔드 웹 훅 처리 패턴 그것을 사용하세요.

클라이언트 리스너를 디버깅하기 전에 수동 테스트 푸시를 보내세요. 토큰이 평범한 알림에 작은 페이로드를 받으면, 전송 경로가 건강한 것입니다. 그렇지 않다면, 네비게이션 code를 변경하기 전에 토큰, 페이로드 형태, 권한 상태를 확인하세요.

알림을 받는 Incoming Notifications

배송은 기능의 반만입니다. 알림이 도착했을 때 앱이 일관된 동작을 하며, 사용자가 알림을 탭했을 때도 일관된 동작을 해야 합니다.

이것은 두 가지 별도의 순간을 처리한다는 것을 의미한다:

알림이 앱이 열려 있는 동안 도착한다.
사용자가 시스템 트레이 또는 잠금 화면에서 알림에 상호 작용한다.

모바일 앱의 전면 및 배경 상태에서 푸시 알림의 생애주기를 나타내는 다이어그램입니다.

앱이 활성화된 상태에서 받은 알림과 사용자가 알림에 상호 작용하는 것은 다른 이벤트입니다.

신뢰할 수 있는 설정은 두 개의 리스너를 모두 포함하는 경우가 많습니다:

import { useEffect } from 'react';
import * as Notifications from 'expo-notifications';

export function useNotificationObservers(
  onForegroundMessage: (notification: Notifications.Notification) => void,
  onNotificationTap: (response: Notifications.NotificationResponse) => void
) {
  useEffect(() => {
    const receivedSub = Notifications.addNotificationReceivedListener(
      (notification) => {
        onForegroundMessage(notification);
      }
    );

    const responseSub = Notifications.addNotificationResponseReceivedListener(
      (response) => {
        onNotificationTap(response);
      }
    );

    return () => {
      receivedSub.remove();
      responseSub.remove();
    };
  }, [onForegroundMessage, onNotificationTap]);
}

addNotificationReceivedListener 앱이 활성화된 경우 실행된다. addNotificationResponseReceivedListener 사용자가 전달된 알림을 탭하면 실행된다. 그들을 혼합하지 말라. 그들은 다른 UX 경로를 제공한다.

데이터 페이로드를 읽고 의도적으로 이동하라.

클릭 처리 패턴에 대한 실용적인 패턴입니다:

type NotificationData = {
  type?: string;
  orderId?: string;
  screen?: string;
};

export function handleNotificationTap(
  response: Notifications.NotificationResponse,
  navigation: any
) {
  const data =
    response.notification.request.content.data as NotificationData;

  if (data.screen === 'OrderDetails' && data.orderId) {
    navigation.navigate('OrderDetails', { orderId: data.orderId });
    return;
  }

  if (data.type === 'new_review') {
    navigation.navigate('Inbox');
    return;
  }

  navigation.navigate('Home');
}

이 패턴은 페이로드가 라우팅 힌트를 포함하기 때문에 문서 전체가 아닌 라우팅 힌트를 포함하기 때문에 변경된 순서가 알림이 전송된 후에도 견고합니다. 알림이 전송된 후에 현재 서버 상태를 가져올 수 있습니다.

클릭한 알림은 하나의 명확한 목적지로 이어져야 한다. fallback 경로는 모호하면 사용자가 즉시 알아차립니다.

애플리케이션의 전경 동작은 사용자 컨텍스트와 일치해야 합니다.

애플리케이션이 이미 열려 있는 경우, 시스템 스타일 알림을 무작위로 표시하는 것은 불편할 수 있습니다. 때로는 올바른 움직임은 앱 내 배너, 배지 업데이트, 또는 무음 리프레시입니다. 지원 인박스 화면은 사용자가 이미 그 대화 내용을 읽고 있는 경우에-visible 알림이 필요하지 않을 수 있습니다.

이것이 왜 전경 리스너가 경로와 알림 유형에 따라 branch해야 하는 이유입니다. 예를 들어:

채팅 화면이 열려 있는 경우: 메시지를 추가하고 중복된 배너를 피하십시오.
대시보드가 열려 있는 경우: 가벼운 앱 내 토스트를 표시하십시오.
중요한 계정 이벤트가 발생한 경우: 강한 UI 처리를 표면화하십시오.

간단한 접근법은 다음과 같습니다:

export function handleForegroundNotification(
  notification: Notifications.Notification,
  currentRouteName: string
) {
  const data = notification.request.content.data as { type?: string };

  if (currentRouteName === 'ChatThread' && data.type === 'new_message') {
    // refresh local thread state
    return;
  }

  // otherwise show your own in-app UI or update badges
}

애플리케이션에서 이러한 컨텍스트를 구분하지 않으면, 사용자는 기술적으로 정확한 알림에도 더 빠르게 알림 피로를 느끼게 됩니다.

제작 최적화 및 일반적인 함정

대부분의 Expo 푸시 알림 설정이 실패하지 않은 이유는 Expo가 너무 제한적이라는 것이 아니다. 실패하는 이유는 팀이 토큰이 영구적이라고 가정하고, 패키지에 어떤 내용이든 담을 수 있고, 앱 업데이트가 알림 논리를 변경하지 않다고 가정하기 때문이다.

그런 가정은 실제 운영 환경에서 살아남지 못한다.

모바일 앱의 운영 환경 푸시 알림 관리를 위한 8가지 최적화 방법을 설명하는 체크리스트 그래픽 자료입니다.

토큰은 임시적이지 않다, 식별자 기록이 아니다.

Expo Push Token은 임시적이기 때문에, 장치 식별자와 같은 영구적이지 않은 임차권과 다르다. 토큰은 재설치, OS 변경, 또는 기타 라이프 사이클 이벤트 후에 회전할 수 있다. 만약 토큰이 다시 돌아오면 DeviceNotRegistered백엔드에서는 토큰을 더 이상 활성화된 토큰으로 다루지 않아야 한다.

실용적인 백엔드 모델은 다음과 같이 저장한다:

사용자 ID
플랫폼
설치 범위의 메타데이터
현재 토큰
최근으로 확인된 타임스탬프
상태는 활성,陈舊, 또는 취소된 것 등이 될 수 있습니다.

사용자 테이블에 하나의 토큰 field만 저장하고 끝내지 마십시오. 사용자는 여러 장치가 있고 장치의 상태는 변합니다.

리프레시 전략은 대부분의 튜토리얼에서 인정하지 못하는 것보다 더 중요합니다.

official ecosystem 지침은 실제 운영상의 빈틈을 남깁니다. existing Expo push notification content는 종종 token의 유효성을 유지하는 방법을 설명하지 않습니다. App Store 리뷰 사이클과 OTA 업데이트와 같은 경우입니다.이는 특히 live 변경을 배포하는 팀에게 특히 중요합니다. push 신뢰도는 현재 토큰 상태와 백엔드 동기화에 의존하며, Expo notifications 문서에서 언급한 바와 같습니다. 이는 리프레시 트리거를 디자인할 때 영향을 미칩니다. token 상태를 일치시키는 좋은 시간은 다음과 같습니다:.

업데이트 후 앱 런치

사용자 로그인
권한 설정 변경
인증서 회전 작업이 릴리스 프로세스에 포함됩니다.
Credential rotation work on your release process
Push 알림 관련 지원 티켓 후 회복 흐름

스프린트의 끝에 보안 및 준수는 속하지 않습니다

많은 Expo 튜토리얼은 기계학습에 초점을 맞추고 운영 위험을 생략합니다. 그것은 취미 앱에 괜찮습니다. 그것은 의료-관련, 금융 기술, 또는 규제 상업 제품에 괜찮지 않습니다.

Courier의 Expo 알림 간격에 대한 기업에 초점을 맞춘 토론 consent 로깅, 감사 기록, 민감한 데이터 노출을 최소화하는 실제적인 지침에 대한 결핍을 강조합니다.

알림 텍스트나 페이로드 메타데이터에敏感한 비즈니스 데이터를 넣지 마십시오.
consent 변경을 서버 측에서 로깅하십시오.
어떤 알림 의도도 어떤 토큰에도 보냈는지 기록하십시오.
페이로드에 ID를 사용하고 앱을 열면 보호된 콘텐츠를 가져오십시오.

릴리즈 운영을 broader 앱 스토어 준수 및 __CAPGO_KEEP_0__ 보안 관행과 일치시키는 팀에 대해 app store compliance and API security practices릴리즈 운영을 broader 앱 스토어 준수 및 보안 관행과 일치시키는 팀에 대해, push는 auth, analytics, backend 이벤트 로깅과 같은 동일한 검토-discipline에 포함되어야 합니다.

사용자에게 보이는 메시지이지만, 푸시 알림은 분산 시스템 문제이기도 하다. 인증 상태와 결제 이벤트와 같은 주의를 기울여야 한다.

일반적으로 성공하고 일반적으로 실패하는 것

성공하는 경우	실패하는 경우
명확한 설명이 있는 후에 권한 요청	첫 번째 프레임에서 프롬프트
실제 장치에서 테스트	심화자 등록에 의존하는 경우
장치 컨텍스트와 함께 토큰 저장	사용자 레코드당 하나의 토큰
작은 메타데이터 페이로드 전송	대형 또는敏感한 블록을 임베드
앞서서와 탭 이벤트를 분리 처리합니다.	모든 알림이 한 경로를 따르는 것으로 가정합니다.
더욱 적극적으로 만료된 토큰을 제거합니다.	죽은 토큰을 영원히 재시도합니다.

완벽한 Expo 알림 설정은 복잡하지 않습니다. 그것은 discipline입니다.

팀이 자주 앱 로직을 변경하고 릴리즈 동작, 롤백, 그리고 배포 시각성에 대한 더 chặt한 제어가 필요하다면, Capgo 앱 로직 변경이 자주 발생하고 릴리즈 동작, 롤백, 그리고 배포 시각성에 대한 더 chặt한 제어가 필요하다면,

2026년 엑스포 푸시 알림 가이드

내용 목록

Expo 푸시 알림을 사용하는 사용자와의 상호 작용의 기초

Expo가 실제로 추상화하는 것

생산성 준비가 무엇을 의미하는가

초기 프로젝트 설정 및 구성

알림 패키지를 설치하세요

프로젝트 수준 구성 추가

알림 처리기를 일찍 설정하세요

Android는 채널 구성이 필요합니다.

권한 요청 및 푸시 토큰 캡처

클라이언트 함수가 기본값이 되어야 하는 함수

왜 Device.isDevice 필수입니다

권한을 요청하는 시점을 올바르게 선택하세요.

서버에서 알림을 보내는 방법

payload 필드의 각 필드가 무엇을 해야 하는지

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

알림을 받는 Incoming Notifications

앱이 활성화된 상태에서 받은 알림과 사용자가 알림에 상호 작용하는 것은 다른 이벤트입니다.

데이터 페이로드를 읽고 의도적으로 이동하라.

애플리케이션의 전경 동작은 사용자 컨텍스트와 일치해야 합니다.

제작 최적화 및 일반적인 함정

토큰은 임시적이지 않다, 식별자 기록이 아니다.

리프레시 전략은 대부분의 튜토리얼에서 인정하지 못하는 것보다 더 중요합니다.

스프린트의 끝에 보안 및 준수는 속하지 않습니다

일반적으로 성공하고 일반적으로 실패하는 것

왜 `Device.isDevice` 필수입니다