2026년 Expo 알림 가이드

앱이 작동하고 사용자가 로그인했으며 제품이 재참여 흐름을 원할 때, native한 느낌을 주는 카트 리마인더, 리뷰 프로모트, 새로운 메시지 알림, 릴리즈 애너운스먼트와 같은 기능을 구현하고 싶을 것입니다. 첫 번째 직감은 종종 'push'를 연결하는 것입니다. 그러나 한 주 후에, 디버깅을 위해 디바이스 하나가 알림을 받고 시뮬레이터가 정상적으로 등록되는 것을 보면서, nobody도 알 수 없는 이유로 탭이 올바른 화면을 열리지 않는 문제를 해결해야 합니다.

Expo push notifications은 간단하게 느껴질 수 있지만 surprisngly 약한 측면도 있습니다.

Expo는 React Native 팀에게 APNs 및 FCM에 대한 실용적인 층을 제공합니다. 이것이 많은 팀이 사용하는 이유입니다. 그러나 데모와 프로덕션 준비 구현 사이의 격차는 실제입니다. 토큰 라이프 사이클, 권한 타이밍, 리스너 설정, 페이로드 디자인, 백엔드 클린업 모두 중요합니다. 또한 빈번한 앱 로직 변경을 하는 경우, 신뢰할 수 있는 메시징과 릴리즈 속도에 의존하는 경우, 운영적 규율이 더욱 중요해집니다. 이것은 신뢰할 수 있는 메시징과 릴리즈 속도에 의존하는 경우, 운영적 규율이 더욱 중요해집니다. mobile app user retention work: 사용자 경험을 예측할 수 있는 경우에만 전달이 유용합니다.

사용자와의 상호 작용을 위한 Expo Push Notification의 기초
- Expo는 실제로 다음을 추상화합니다.
- 실제로 프로덕션 준비가 무엇을 의미하는지
초기 프로젝트 설정 및 구성
권한 요청 및 푸시 토큰 캡처
서버에서 알람을 보내는 방법
앱에서 Incoming Notification을 처리하는 방법
프로덕션 최적화 및 일반적인 오류

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

Expo 푸시 알림 Expo 푸시 알림 설정은 주로 한 가지 이유로 매력적입니다. 그것은 팀이 첫 번째 날에 소유하고 싶지 않은 원시 메시징 복잡성을 제거합니다. Expo의 게이트웨이와 함께 작업하는 대신, APNs 및 FCM 플러밍을 직접 구축하는 대신, 제품 동작, 라우팅, 권한 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 지연, 그리고평균 일일 오류율 0.17% 수백만 건의 일일 메시지에 걸쳐 수십만 건의 일일 메시지에 걸쳐 tens of millions에 따르면 Knock의 Expo 푸시 API 성능 분석이것이 프로토타입에만 적합한 Expo인지 의심하는 팀을 위로할 것이다.

Expo가 실제로 추상화하는 것

팀이 'Expo 푸시'라고 말할 때, 종종 여러 개의 별개의 문제를 함께 묶어 말한다:

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

그것은 도움이지만 또한 일반적인 오해를 일으킵니다. 팀은 종종 Expo가 모든 전달 문제를 소유한다고 가정합니다. 실제로 많은 실패는 앱 code,陈舊한 토큰, 잘못된 페이로드, 또는 허용된 흐름에서 오는 것입니다.

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

실제 프로덕션 준비가 무엇을 의미하는가

작동하는 데모는 단지 한 장치가 한 페이로드를 한 번 수락했음을 증명한다는 것을 의미합니다. 프로덕션 준비는 다른 것을 의미합니다:

관심사	데모 마음가짐	프로덕션 마음가짐
권한	__CAPGO_KEEP_0__	__CAPGO_KEEP_0__
__CAPGO_KEEP_0__	__CAPGO_KEEP_0__	__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__	수동 테스트	영수증, 정리, 로그, 및 사고 처리

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

초기 프로젝트 설정 및 구성

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

modern한 노트북이 나무 책상 위에 놓여 있는 프로젝트 설정의 구성 code 파일을 보여주는 장면

개발 환경이 빌드 경로와 일치하는 경우에 시작하세요. Expo Go를 넘어서 작업하는 경우, 개발 클라이언트 설정을 커스터마이즈하는 것이 도움이 됩니다. 알림 동작이 종종 빠른 샌드박스 실행보다 더 가깝게 프로덕션에 가까운 빌드에서 검증해야 하기 때문입니다. 알림 패키지를 설치하세요권한 요청, 토큰 수집, 리스너, 및 알림 표시를 위해 최소한으로 필요합니다:

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

권한 요청, 토큰 수집, 리스너, 및 알림 표시를 위해 최소한으로 필요합니다:

expo-notifications for permission requests, token retrieval, listeners, and notification presentation.
expo-device 왜든 토큰 취득을 보호해야 하는지 Device.isDevice.

일반적인 설치 명령어는 패키지 매니저에 따라 다르지만 Expo SDK 버전과 일치하는 것이 중요합니다. Expo가 호환되는 버전을 자동으로 해결하도록 하세요.

프로젝트 수준 구성 추가

최소한의 구성만 유지하세요. app.json 또는 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"
      }
    }
  }
}

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

앱이 실제로 배포하는 앱과 일치하는 번들 식별자와 패키지 이름이 필요합니다. 알림 플러그인은 빌드 시 네이티브 프로젝트에 필요한 설정을 제공합니다.
EAS 프로젝트 ID The notifications plugin ensures the native project gets the required setup during build.
The notifications plugin ensures the native project gets the required setup during build. 앱 토큰 취득 시 앱이 올바른 Expo 프로젝트와 연관되어야 한다는 것을 기대하는 경우 중요합니다.

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

기본적인 튜토리얼에서 많은 경우 알림 동작을 너무 늦게 정의합니다. 하지 마세요. 앱 시작 시점에 근처에 두세요. 이로써 전면 동작이 예측 가능합니다.

import * as Notifications from 'expo-notifications';

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

팀은 전면 알림이 표시되면 경고 알림을 표시할지, 소리를 재생할지, 배지에 영향을 줄지 여부를 결정합니다. 정확한 동작은 제품에 따라 다릅니다. 채팅 앱과 결제 앱은 같은 선택을 하지 않습니다.

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

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에서 복사한 다음 나중에 후회합니다.

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

Expo 푸시 알림 토큰을 얻는 과정을 단계별로 보여주는 다이어그램.

기본적인 클라이언트 함수가 되어야 합니다.

기본적인 함수를 사용하는 것처럼 함수를 사용하십시오.

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 };
}

기기 종류를 확인한 후 안드로이드 채널 동작을 설정하고 권한을 해결하고 프로젝트 설정을 검증하고 Expo 토큰을 요청합니다.

왜 `Device.isDevice` 필수는 아닙니다.

이것은 많은 잡음이 발생하는 것처럼 보이지만 전문 팀만이 조건에 따라 권한을 요청할 때 발생하는 오류 중 하나입니다. Device.isDevice 권한이 true일 때만 조건부로 권한을 요청하고, 개발자들은 앱 설정이 잘못되었음을 알 수 없는 시뮬레이터 토큰으로 알림을 보내고 Expo를 비난하는 오류를 피하기 위해 조건을 생략하는 경우가 많습니다.이러한 문제는 Eagerworks의 Expo 알림 구현 노트에서 설명되어 있습니다. 이러한 이유로 함수의 맨 위에 체크를 두어야 합니다. 도우미 함수 뒤에 숨기지 마십시오. 명확하게 하십시오..

시뮬레이터 결과는 UI 테스트에 유용하지만 push 토큰 등록을 검증하는 데 신뢰할 수 없습니다.

권한을 요청하는 시점을 올바르게 물어보십시오.

__CAPGO_KEEP_0__

Splash 화면에서 질문하지 마세요. 사용자가 알기 전에 알림의 가치를 물어보지 마세요. 일반적으로 알림의 이점이 구체화된 사용자 동작 후에 가장 좋은 시점입니다. 예를 들어, 배송 업데이트 수신을 활성화하거나 대화에 참여하거나, 감시 중인 항목을 저장하는 경우입니다.

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

사용자가 의미 있는 기능 경계에 도달합니다.
앱은 알림의 가치에 대한 설명을 사용자 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는 유용한 시각적 참조가 됩니다.

릴리스가 많은 앱을 개발하는 팀에게는 토큰 등록을 앱의 운영 상태로 생각하는 것이 도움이 됩니다. 온보딩만의 일부가 아닌, 앱의 운영 상태의 일부로 생각하는 것이 더 적합합니다. 이러한 마음가짐은 더 광범위한 Expo 앱 배포 워크플로우, 앱 동작이 자주 변경되고 백엔드 상태가 동기화되어야 하는 경우에 잘 맞습니다.

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

백엔드가 유효한 Expo Push Token을 가지고 있다면, 알림을 보내는 것은 간단합니다. 요청 자체가 어려운 것은 아닙니다. 문제는 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를 임의로 사용하지 마세요. 각 필드를 의도적으로 사용하세요.

필드	목적	실용적인 조언
`to`	대상 Expo Push Token	현재 장치 기록에 속하는지 확인하세요.
`title`	알림 제목	짧고 인간이 읽을 수 있는 것만 사용하세요.
`body`	Main visible text	작업을 명확하게 하세요
`sound`	시스템 소음 동작	중요한 알림에만 사용하세요
`data`	앱 관련 메타데이터	ID와 경로 힌트를 선호하세요. 복잡한 콘텐츠보다

The data 객체는 제품 워크플로우에서 유용합니다. 타입과 레코드 ID를 전달하고 사용자가 탭할 때 최신 데이터를 가져올 수 있습니다. 이 방법은 대량 또는敏感한 데이터를 직접 패키지에 포함하는 것보다 안전합니다.

패키지 크기를 작고 단조롭게 유지하세요

Courier의 Expo 알림 가이드에 따르면 Courier’s guide to Expo notificationsExpo Push 토큰은 임시로 처리되어야 합니다. roughly 크기 제한을 초과하는 패키지는 4 KB 보내기가 취소될 수 있으며, 신뢰할 수 있는 패턴은 JSON이나 인라인 미디어와 같은 큰 데이터를 보내기보다 작은 메타데이터 전송을 보내는 것입니다. { "type": "new_review", "id": 123 } 실제 시스템에서 작동하는 것을 반영하는 조언입니다. 작은 데이터 전송은 더 자주 실패하지 않고 앱 로직이 변경될 때 더 오래 유지됩니다.

사용자를 라우팅하기 위한 데이터를 충분히 보내고 앱이 열리면 나머지 데이터를 가져오세요.

유용한 서버 측 습관

테스트를 위한 기본적인 보내기 함수는 충분합니다. 실제 프로덕션에서는 보내기 함수가 몇 가지 더 많은 책임을 지는 경우가 많습니다.

보내기를 시도한 기록을 유지하세요: 사용자 ID, 토큰, 데이터 유형 및 타임스탬프와 함께 알림 의도 저장:
송신을 분리하세요: 메시지 복사본을 하나의 층에서 빌드하고 Expo API 요청을 다른 층에서 빌드하세요.
유효성 검사 feedback를 처리하세요: Expo가 나중에 보고할 경우 DeviceNotRegistered, __CAPGO_KEEP_0__을 만료표시하고 무작위로 다시 시도하지 마십시오.
웹후크 친화적인 디자인을 사용하십시오: 이미 시스템이 이벤트를 발생시키고 있다면, 같은 종류의 백엔드 웹후크 처리 패턴을 통해 알림 트리거를 라우팅하십시오. 그것을 사용하는 다른 곳과 동일한 패턴을 사용하십시오. 클라이언트 리스너를 디버깅하기 전에 수동 테스트 푸시를 보내십시오. 토큰이 평범한 알림에 작은 페이로드를 받았다면, 전송 경로가 확실히 건강합니다. 그렇지 않다면, __CAPGO_KEEP_0__을 변경하기 전에 토큰, 페이로드 형태, 권한 상태를 확인하십시오.

Before debugging client listeners, send a manual test push first. If a token receives a plain notification with a tiny payload, your transport path is probably healthy. If not, don’t start by changing navigation code. Start by validating the token, payload shape, and permission state.

배송은 기능의 반만입니다. 알림이 도착했을 때 앱이 무엇을 해야 하는지, 사용자가 알림을 클릭했을 때 앱이 무엇을 해야 하는지 모두 처리해야 합니다.

이것은 두 가지 별개의 순간을 처리해야 하는 것을 의미합니다:

앱이 열려 있는 동안 알림이 도착하는 경우

시스템 트레이 또는 잠금 화면에서 알림과 상호 작용하는 경우
모바일 애플리케이션의 푸시 알림 라이프 사이클 다이어그램

Handling Incoming Notifications in Your App

Foreground receipt and user response are different events

A reliable setup usually includes both listeners:

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 경로를 제공합니다.

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

이 패턴은 알림을 탭했을 때의 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 경로가 모호하면 사용자가 즉시 알아차립니다.

앱이 활성화 될 때 앱의 동작은 사용자의 맥락과 일치해야 합니다.

앱이 이미 열려 있는 경우 시스템 스타일 알림을 무작위로 표시하면 느슨한 느낌을 줄 수 있습니다. 때로는 올바른 움직임은 인앱 배너, 배지 업데이트, 또는 무음 리프레시입니다. 사용자가 이미 해당 대화 내용을 읽고 있는 경우 지원 인박스 화면에는 표시되지 않는 알림이 필요하지 않을 수 있습니다.

채팅 화면이 열려 있는 경우: 이 메시지를 추가하고 중복된 배너를 피하세요.
대시보드 열기: 인앱 토스트를 가볍게 표시하세요.
중요한 계정 이벤트: 강한 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가지 최선의 실천 방법을 요약한 체크리스트 인포그래픽입니다.

토큰은 영구적이지 않고, 식별 정보가 아닙니다.

__CAPGO_KEEP_0__는 Expo Push Token과 같은 임대 계약처럼 다루어야 합니다. OS 변경, 재설치, 또는 기타 라이프 사이클 이벤트 후 토큰이 회전할 수 있습니다. 토큰이 최종적으로 반환되면 DeviceNotRegistered, 백엔드에서는 이를 활성화로 다루지 않아야 합니다.

실용적인 백엔드 모델에는 다음과 같은 항목이 포함됩니다.

사용자 ID
플랫폼
설치 범위 메타데이터
현재 토큰
최근 보기에 대한 타임스탬프
활성,陈腐, 또는 취소된 상태와 같은 상태

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

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

공식 생태계 지침은 실제 운영상의 빈틈을 남깁니다. 기존 Expo push notification 콘텐츠는 종종 토큰 유효성을 유지하는 방법을 설명하지 않습니다. 앱 스토어 리뷰 주기 및 OTA 업데이트, 특히 라이브 변경을 배포하는 팀에게는 중요합니다. 푸시 신뢰도는 현재 토큰 상태와 백엔드 동기화에 의존하기 때문입니다. Expo 알림 문서에서 언급한 것과 같이.

Expo 알림의 단점에 대해 Courier가 기업에 초점을 맞춘 토론을 진행했습니다.

Refresh 트리거를 디자인할 때 영향을 받는 요인은 다음과 같습니다.
업데이트 후 앱 런치
사용자 로그인
권한 설정 변경
인증서 회전 작업

푸시 관련 지원 티켓 후 복구 흐름

보안 및 규제는 스프린트의 끝에 속하지 않습니다.

Expo 튜토리얼의 많은 부분은 기계적 측면에만 초점을 맞추고 운영 위험을 무시합니다. 실무 지침이 없는 동의 로깅, 감사 기록,敏感 데이터 노출 최소화와 관련된 문제를 강조합니다. 엔지니어링의 직접적인 takeaway은 간단합니다:

敏감한 비즈니스 데이터를 알림 텍스트나 페이로드 메타데이터에 넣지 마십시오.
서버 측에서 동의 변경 로그를 기록하십시오.
어떤 알림 의도도 어떤 토큰에 전송되었는지 기록하십시오.
페이로드에 ID를 사용하고 앱이 열린 후에 보호된 콘텐츠를 가져오십시오.

릴리즈 운영을 더 넓은 앱 스토어 규정 준수 및 __CAPGO_KEEP_0__ 보안 관행과 일치시키는 팀에게는 푸시 알림이 인증, 분석, 백엔드 이벤트 로깅과 같은 동일한 검토 범위에 포함되어야 합니다. app store compliance and API security practices일반적으로 작동하는 것과 일반적으로 깨지는 것

일반적으로 작동하는 것

일반적으로 깨지는 것

push should be included in the same review discipline as auth, analytics, and backend event logging.	Push notifications are user-facing messages, but they’re also a distributed systems problem. Treat them with the same care you apply to auth state and payment events.
허용 권한 요청 후 명확한 값 설명	첫 번째 프레임에서 경고
실제 장치에서 테스트	시뮬레이터 등록에 신뢰
장치.context와 함께 토큰 저장	사용자 레코드당 하나의 토큰
작은 메타데이터 페이로드 전송	대형 또는敏感 blob을 임베드
전면 및 탭 이벤트를 별도로 처리	모든 알림이 한 경로를 따르는 것으로 가정
더러워진 토큰을 적극적으로 만료	죽은 토큰을 영원히 재시도

A solid Expo push setup isn’t complicated. It’s disciplined.

If your team ships frequent app logic changes and needs tighter control over release behavior, rollbacks, and delivery visibility, Capgo is worth a look. It helps mobile teams push updates quickly without waiting on store review, which is especially useful when notification flows, routing logic, or client-side fixes need to reach users fast.

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

Table of Contents

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

Expo가 실제로 추상화하는 것

실제 프로덕션 준비가 무엇을 의미하는가

초기 프로젝트 설정 및 구성

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

프로젝트 수준 구성 추가

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

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

권한 요청 및 푸시 토큰 캡처

기본적인 클라이언트 함수가 되어야 합니다.

왜 `Device.isDevice` 필수는 아닙니다.

__CAPGO_KEEP_0__

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

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

패키지 크기를 작고 단조롭게 유지하세요

유용한 서버 측 습관

배송은 기능의 반만입니다. 알림이 도착했을 때 앱이 무엇을 해야 하는지, 사용자가 알림을 클릭했을 때 앱이 무엇을 해야 하는지 모두 처리해야 합니다.

Foreground receipt and user response are different events

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

앱이 활성화 될 때 앱의 동작은 사용자의 맥락과 일치해야 합니다.

생산 환경에서 최선의 실천 방법과 일반적인 함정

토큰은 영구적이지 않고, 식별 정보가 아닙니다.

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

푸시 관련 지원 티켓 후 복구 흐름

일반적으로 깨지는 것

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

Table of Contents

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

Expo가 실제로 추상화하는 것

실제 프로덕션 준비가 무엇을 의미하는가

초기 프로젝트 설정 및 구성

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

프로젝트 수준 구성 추가

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

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

권한 요청 및 푸시 토큰 캡처

기본적인 클라이언트 함수가 되어야 합니다.

왜 Device.isDevice 필수는 아닙니다.

__CAPGO_KEEP_0__

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

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

패키지 크기를 작고 단조롭게 유지하세요

유용한 서버 측 습관

배송은 기능의 반만입니다. 알림이 도착했을 때 앱이 무엇을 해야 하는지, 사용자가 알림을 클릭했을 때 앱이 무엇을 해야 하는지 모두 처리해야 합니다.

Foreground receipt and user response are different events

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

앱이 활성화 될 때 앱의 동작은 사용자의 맥락과 일치해야 합니다.

생산 환경에서 최선의 실천 방법과 일반적인 함정

토큰은 영구적이지 않고, 식별 정보가 아닙니다.

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

푸시 관련 지원 티켓 후 복구 흐름

일반적으로 깨지는 것

왜 `Device.isDevice` 필수는 아닙니다.