앱이 작동하는 단계에서 확실히 있을 것입니다. 사용자가 로그인했으며 제품이 재참여 흐름을 원할 때, 카트 알림, 리뷰 지시, 새로운 메시지 알림, 릴리스 발표 등이 필요합니다. 첫 번째 직관은 종종 "푸시를 연결하기만 하면 되겠지" 라는 생각이지만, 한 주 후에는 디버깅을 시작하게 됩니다. 왜 한 기기는 알림을 받고, 시뮬레이터는 정상적으로 등록되는 것처럼 보이지만, nobody가 왜 탭이 올바른 화면을 열지 않는지 설명할 수 없을 때가 있습니다.
그것이 엑스포 푸시 알림의 경우입니다. 그것은 매우 간단하거나 놀랍게도 약한 경우입니다.
엑스포는 APNs 및 FCM 위에 실용적인 층을 제공하여 React Native 팀에게 편리합니다. 하지만 데모와 프로덕션 준비 구현 간의 격차는 실제입니다. 토큰 라이프 사이클, 권한 타이밍, 리스너 설정, 페이로드 디자인, 백엔드 청소 등이 모두 중요합니다. 만약 빈번한 앱 논리 변경을 배포하는 경우, 운영적 규율이 필요성이 더 강해집니다. 특히 신뢰할 수 있는 메시징과 릴리스 속도에 의존하는 경우, 그것은 더 큰 우려입니다. 모바일 앱 사용자 유지 관리 작업: 사용자 경험을 예측할 수 있는 환경에서만 배송이 유용합니다.
목차
- 사용자와 Expo 푸시 알림을 매력적으로 연결하는 데 필요한 기초
- 초기 프로젝트 설정 및 구성
- 권한 요청 및 푸시 토큰 캡처
- 서버에서 알림을 보내는 방법
- 앱에서 알림을 수신하는 방법
- 프로덕션 최적화 및 일반적인 오류
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
__CAPGO_KEEP_0__
API __CAPGO_KEEP_0__, __CAPGO_KEEP_0__와 일 평균 오류율 0.17% 수십만 건의 일일 메시지 Knock의 Expo 푸시 __CAPGO_KEEP_0__ 벤치마크 분석에 따르면Expo가 실제로 추상화하는 것 Knock’s Expo push API benchmark analysisProvider routing:
Expo는 메시지를 APNs로 전달합니다.
API
- SDK CLI npm iOS 및 FCM Android용.
- 토큰 형식: 서버는 Expo Push Token 대신 플랫폼별 토큰 처리를 관리하는 것을 먼저하는 대신 토큰을 저장하고 전송합니다.
- 요청 계약: Expo의 푸시 API로 페이로드를 POST하는 대신 원시 제공자 API에 직접 통합하지 않습니다.
그것은 유용하지만 실제로는 앱 code,陈舊한 토큰, 잘못된 페이로드, 또는 허용된 흐름이 실패의 원인이 되는 경우가 많습니다.
실용적인 규칙: Expo를 신뢰할 수 있는 전송層로 간주하고, 클라이언트 및 백엔드 설계에 대한 좋은 대안으로 간주하지 마십시오.
실제로 프로덕션 준비가 무엇을 의미하는지
작동하는 데모는 단지 한 기기에서 한 페이로드를 한 번 수락했음을 증명한다는 것을 의미합니다. 프로덕션 준비는 다른 것을 의미합니다:
| 관심사 | 데모 마음가짐 | 생산 마음가짐 |
|---|---|---|
| 권한 | 즉시 묻기 | 사용자 가치가 명확한 후에 묻기 |
| 토큰 | 한 번 저장 | 갱신, 중복 제거, 만료, 일치시키기 |
| 페이로드 | 모든 것을 포함 data |
페이로드를 작고 동작 지향적으로 유지 |
| 앱 동작 | 알림 표시 | 정확하게 이동하고 전면 상태를 처리 |
| 작업 | 수동 테스트 | 수표, 정리, 로그 및 사고 처리 |
‘通知 보내기’와 ‘실제 제품 워크플로우를 지원하는通知’의 차이입니다.
초기 프로젝트 설정 및 구성
Expo 푸시의 많은 고통은 첫 번째 권한 요청 전부터 시작됩니다. 프로젝트 구성이 엉망이면 클라이언트 code가 올바르게 보일 수 있지만 빌드 간에 앱이 일관되지 않게 동작할 수 있습니다.
올바른 라이브러리가 설치되어 개발 환경이 빌드 경로와 일치하는 경우 시작하세요. Expo Go를 넘어 작업하는 경우, 개발 클라이언트 설정을 맞춰주는 것이 도움이 됩니다. 개발 환경을 맞춰주면 도움이 됩니다., 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권한 요청을 위한 토큰 취득을 보호해야 합니다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 다음 몇 가지 세부 사항이 중요합니다: 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"
}
}
}
}__CAPGO_KEEP_0__
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
- __CAPGO_KEEP_1__ __CAPGO_KEEP_2__
- __CAPGO_KEEP_3__ __CAPGO_KEEP_4__
__CAPGO_KEEP_5__
__CAPGO_KEEP_6__
import * as Notifications from 'expo-notifications';
Notifications.setNotificationHandler({
handleNotification: async () => ({
shouldShowAlert: true,
shouldPlaySound: false,
shouldSetBadge: true,
}),
});__CAPGO_KEEP_7__
__CAPGO_KEEP_8__
__CAPGO_KEEP_9__
__CAPGO_KEEP_10__
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,
});
}__CAPGO_KEEP_11__
권한 요청 및 푸시 토큰 캡처
많은 팀이 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 };
}순서는 중요합니다. 장치 유형을 확인한 후 안드로이드 채널 동작을 설정하고 권한을 해결한 후, 프로젝트 구성이 유효한지 확인하고 Expo 토큰을 요청합니다.
왜 Device.isDevice 필수입니다
이것은 많은 잡음이 발생하는 것처럼 보이지만 위험하지 않은 오류 중 하나입니다. 전문 팀은 Device.isDevice true일 때만 권한 요청을 조건적으로 요청하고, 그 가드를 생략하는 것은 개발자가 비유효한 시뮬레이터 토큰으로 알림을 보내고 Expo를 비난하는 일반적인 실수입니다. 이 문제는 실제로 앱 구성에 설명된 것과 같이 앱 구성이 잘못되었기 때문입니다. 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은 유용한 시각적 참조입니다:
릴리즈-중심 앱을 개발하는 팀에게도 토큰 등록을 앱의 운영 상태의 일부로 생각하는 것이 도움이 됩니다. 이는 온보딩의 일부로만 생각하는 것과는 다릅니다. 이러한 마음가짐은 더 넓은 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를 버스정류장으로 생각하지 마세요. 각 필드를 의도적으로 사용하세요.
| 필드 | 목적 | 실용적인 조언 |
|---|---|---|
to |
Expo Push 토큰 목표 | __CAPGO_KEEP_0__ |
title |
현재 기기 기록에 속하는지 확인하세요 | __CAPGO_KEEP_1__ |
body |
알림 제목 | __CAPGO_KEEP_2__ |
sound |
간결하고 사용자 친화적인 내용으로 유지하세요 | __CAPGO_KEEP_3__ |
data |
주요 표시 텍스트 | __CAPGO_KEEP_4__ |
액션을 명확하게 하세요 data __CAPGO_KEEP_5__
__CAPGO_KEEP_0__
Capgo에 따르면 Courier의 Expo 알림에 대한 안내서Expo Push 토큰은 임시적인 것으로 처리되어야 합니다. 4 KB 작은 JSON 또는 인라인 미디어가 아닌 { "type": "new_review", "id": 123 } 작은 메타데이터 페이로드를 보낼 때, 더 자주 실패하지 않고 앱 로직이 변경될 때 더 오래 살아남습니다.
사용자를 라우팅하기 위한 데이터를 충분히 보내고 앱이 열릴 때 나머지 데이터를 가져옵니다.
유용한 서버 측 습관
테스트를 위한 기본적인 보내기 함수는 충분합니다. 실제 프로덕션 환경에서는 보내기 함수에 몇 가지 추가 책임이 있습니다.
- 보내기를 시도한 기록을 유지합니다: 사용자 ID, 토큰, 페이로드 타입, 및 타임스탬프와 함께 알림 의도 저장합니다.
- 내용 생성과 전송을 분리하십시오: 한 층에서 메시지 복사본을 빌드하고 Expo API 요청을 다른 층에서 처리하십시오.
- invalidation feedback를 처리하십시오: Expo가 나중에 __CAPGO_KEEP_0__를 오래된 것으로 표시하고 무의식적으로 다시 시도하지 않도록 하십시오.
DeviceNotRegistered웹 훅에 친화적인 디자인을 사용하십시오: - 시스템이 이미 이벤트를 내뿜고 있다면, notification triggers를 같은 backend webhook 처리 패턴을 통해 라우팅하십시오. 클라이언트 리스너를 디버깅하기 전에 수동 테스트 푸시를 먼저 보내십시오. 토큰이 평범한 notification에 작은 payload를 받았다면, 전송 경로가 건강한 것입니다. 그렇지 않다면, __CAPGO_KEEP_0__의 네비게이션을 변경하기 전에 토큰, payload 형태, 그리고 권한 상태를 확인하십시오. 앱 내에서 Incoming Notifications를 처리하십시오: 배송은 기능의 반만입니다. 알림이 도착했을 때 앱이 일관된 동작을 하며, 사용자가 알림을 탭했을 때도 일관된 동작을 해야 합니다.
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.
Delivery는 기능의 반만입니다. 알림이 도착했을 때 앱이 일관된 동작을 하며, 사용자가 알림을 탭했을 때도 일관된 동작을 해야 합니다.
Delivery는 기능의 반만입니다. 알림이 도착했을 때 앱이 일관된 동작을 하며, 사용자가 알림을 탭했을 때도 일관된 동작을 해야 합니다.
이것은 두 가지 별도의 시점을 처리하는 것을 의미합니다:
- 앱이 열려 있는 동안 알림이 도착하는 경우
- 시스템 트레이 또는 잠금 화면에서 알림에 상호 작용하는 경우
앱이 활성화되었을 때와 사용자가 전달된 알림을 탭했을 때는 다른 이벤트입니다.
신뢰할 수 있는 설정은 두 개의 리스너를 모두 포함하는 경우가 많습니다.
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');
}클릭한 알림은 하나의 명확한 목적지로 이어져야 합니다. 만약 여러분의 대체 경로는 모호하다면 사용자는 즉시 이를 알아차립니다.
이 패턴은 알림이 전송된 시점 이후에 주문이 변경된 경우에도 견고합니다. 알림이 전송된 시점 이후에 서버 상태를 가져올 수 있기 때문입니다.
사용자 환경에 맞는 전면 동작이 되어야 합니다.
앱이 이미 열려 있는 경우, 시스템 스타일 알림을 무작위로 표시하는 것은 불편할 수 있습니다. 때로는 올바른 움직임은 앱 내 배너, 배지 업데이트, 또는 무음 리프레시입니다. 사용자가 이미 대화 내용을 읽고 있는 경우, 지원 이메일箱 화면에는 표시할 필요가 없습니다.
이러한 이유로, 전면 리스너는 경로와 알림 유형에 따라 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가 너무 제한적이라는 것이 아니다. 실패하는 이유는 팀이 토큰이 영구적이라고 가정하고, 패킷이 어떤 내용이든지 포함할 수 있고, 앱 업데이트가 알림 로직에 영향을 주지 않는다고 가정하기 때문이다.
이런 가정은 실제 운영 환경에서 살아남지 못한다.
토큰은 임시적이기 때문에, 사용자 식별 정보가 아니다.
Expo Push Token은 임시적이기 때문에, 장치 식별자와 같은 영구적 인식으로 다루지 말아야 한다. 토큰은 재설치, OS 변경, 또는 기타 라이프 사이클 이벤트 후에 회전할 수 있다. 만약 토큰이 결국 돌아오면, 백엔드에서는 더 이상 이를 활성 토큰으로 다루지 않아야 한다. DeviceNotRegistered실용적인 백엔드 모델은 다음과 같은 정보를 저장한다:
사용자 ID
- 플랫폼
- 설치 범위의 메타데이터
- 현재 토큰
- 최근으로 확인된 타임스탬프
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
사용자 정보를 저장하지 말고 단순히 끝내지 마세요. 사용자는 여러 장치에 접속할 수 있고, 장치 상태도 바뀝니다.
리프레시 전략은 대부분의 튜토리얼에서 인정하지 못하는 중요한 부분입니다.
official ecosystem guidance는 실제 운영 환경에서 발생하는 gap을 남깁니다. existing Expo push notification content는 token의 유효성을 유지하는 방법을 설명하지 않습니다. App Store 리뷰 주기와 OTA 업데이트와 같은 상황에서 token의 유효성을 유지하는 것이 중요합니다.Expo notifications documentation에서 언급한 바와 같이 push의 신뢰도는 token의 현재 상태와 백엔드 동기화에 의존합니다. 리프레시 트리거를 디자인할 때 token의 유효성을 유지하는 방법을 고려해야 합니다..
token 상태를 일치시키는 좋은 시점은 다음과 같습니다.
- 앱 업데이트 후 앱 런치
- 사용자 로그인
- 권한 설정 변경
- 인증 정보를 rotate하는 작업을 릴리스 프로세스에 포함하세요.
- push 관련 지원 티켓 이후 복구 흐름
스프린트의 끝에 보안 및 준수는 속하지 않습니다
Expo 튜토리얼의 많은 것들은 기계적 측면에 초점을 맞추고 운영 위험을 생략합니다. 그것은 취미 앱에 괜찮습니다. 그것은 의료-관련, 금융 기술, 또는 규제 상업 제품에 괜찮지 않습니다.
Courier의 Enterprise-focused Expo 알림 간극 토론 Expo 알림 간극에 대한 실용적인 지침에 대한 결핍을 강조합니다.-consent 로깅, 감사 트레일, 민감한 데이터 노출 최소화.
- 직접 엔지니어링 takeaway는 단순합니다:
- Sensitive business data를 알림 텍스트나 페이로드 메타데이터에 넣지 마십시오.
- consent 변경을 서버 측에서 로깅하십시오.
- 알림 의도와 토큰에 대한 기록을 하십시오.
페이로드에 ID를 사용하고 앱이 열리면 보호된 콘텐츠를 가져오십시오. 릴리즈 운영을 broader 앱 스토어 준수 및 API 보안 관행과 동기화하는 팀에서push는 auth, analytics, backend 이벤트 로깅과 같은 리뷰 дисцип라인에 포함되어야 합니다.
사용자에게 보이는 메시지이지만, push 알림은 분산 시스템 문제이기도 하다. 인증 상태와 결제 이벤트와 같은 주의를 기울여야 한다.
What이 일반적으로 작동하고 무엇이 일반적으로 깨지는지
| 일반적으로 작동한다 | 일반적으로 깨진다 |
|---|---|
| 허용 권한을 요청하기 전에 명확한 설명이 있는 값 | 첫 번째 프레임에서 프롬프트 |
| 실제 장치에서 테스트 | 심уля이터 등록에 신뢰 |
| 장치 컨텍스트와 함께 토큰 저장 | 사용자 레코드당 하나의 토큰 |
| 작은 메타데이터 페이로드 전송 | 대형 또는敏感한 블롭을 임베드 |
| 배경과 터치 이벤트를 별도로 처리하는 방법 | 모든 알림이 한 경로를 따르는 것으로 가정합니다. |
| 기한이 지난 토큰을 적극적으로 만료합니다. | 죽은 토큰을 영원히 다시 시도합니다. |
solid Expo push 설정은 복잡하지 않습니다. 그것은 discipline입니다.
팀이 자주 앱 논리 변경을 배포하고 release 행동, 롤백, 배달 시각성에 대한 더 강한 제어를 필요로 하는 경우, Capgo 앱 팀이 스토어 리뷰를 기다리지 않고 빠르게 업데이트를 푸시하는 데 도움이 됩니다. 알림 흐름, 라우팅 논리, 클라이언트 측 수정이 사용자에게 빨리 도달해야 하는 경우 especialmente.
