릴리스 후보가 내부 검토를 모두 통과한 직후 거절 통보가 날아옵니다. 바이너리는 설치되고 로그인도 되는데, 출시 팀은 이미 일정만 바라보고 있는 상황이죠. 그런데 App Store Connect가 가이드라인과 리뷰어 노트를 가리키며 제출이 차단됐다고 알려옵니다. Capacitor 또는 Electron을 쓰는 팀이라면 가장 빠른 복구는 또 한 번 업로드하는 데서 시작하지 않습니다. 리뷰어가 빌드 결함을 발견했는지, 메타데이터가 부정확했는지, 정책에 맞지 않는 부분이 있었는지, 아니면 설명만 보완하면 되는 문제인지 파악하는 것에서 시작합니다.
Apple의 심사 관문은 팀에 대한 개인적 판단이 아니라 정상적인 출시 과정의 일부입니다. Apple의 2024 App Store 투명성 보고서 기록 앱 제출 777만 건 심사, 193만 건 거절, 약 4건 중 1건, 성능, 법률, 디자인, 비즈니스, 안전이 주요 거절 사유로 꼽혔습니다 (Apple 2024 App Store 보고서 요약). 메시지를 인시던트 티켓으로 취급하고, 증거 기록을 남기며, 규정을 준수하는 최소한의 복구 경로를 선택하세요.
목차
- App Store 거절이 지금 정말 의미하는 것
- 거절의 진짜 원인 진단하기
- 심사를 통과하는 규정 준수 재제출 준비
- 효과적인 이의 제기 작성 및 리뷰어 소통법
- 전체 심사가 필요 없을 때 기다리지 않고 수정하기
- 더 나은 제어로 다음 App Store 거절 방지하기
App Store 거절이 지금 정말 의미하는 것
팀들이 가장 먼저 하는 실수는 거절 이메일을 최종 판결로 받아들이는 것입니다. 실제로 이는 하나의 제출된 바이너리와 하나의 메타데이터 세트, 리뷰어 지침을 바탕으로 하나의 심사 경로에서 나온 테스트 결과일 뿐입니다. 리뷰어는 크래시, 작동하지 않는 로그인, 오해를 부르는 스크린샷, 설명되지 않은 결제 흐름, 또는 제품과 맞지 않는 권한 요청 프롬프트에서 심사를 멈췄을 수 있습니다.
Apple의 규모를 보면 이 구분이 중요합니다. 2024년 Apple이 보고한 7,771,599건의 제출 중 1,931,400건이 거절되었으며, 약 24.8%, 즉 제출 4건 중 약 1건꼴입니다 (Apple 2025 투명성 보고서). 이전 보고서에서도 2023년에 1,763,812건의 제출이 거절되었고, 인용된 2022년 보고서에서는 1,679,694 (Apple 2023 App Store 투명성 보고서). 따라서 App Store 거절은 출시 과정에서 반복되는 관문일 뿐, 제품에 유독 결함이 있다는 증거가 아닙니다.
메시지를 장애 보고서로 읽으세요
Resolution Center에서 시작하세요. 코드베이스가 아닙니다. 정확한 가이드라인 번호를, 리뷰어의 재현 단계, 영향을 받은 화면 또는 계정, 첨부 파일, 심사 중인 빌드 번호가 포함됩니다. 가이드라인 2.1을 인용하며 화면 녹화가 포함된 메시지는 부제목이나 스크린샷을 명시하는 메타데이터 보류와는 다른 문제입니다.
작업을 할당하기 전에 결과를 분류하세요:
- 강제 차단: 동작, 설정, 권한, 결제, 콘텐츠 또는 빌드 자체를 변경하기 전까지는 제출된 바이너리를 승인할 수 없습니다.
- 메타데이터 수정: 바이너리는 문제가 없을 수 있지만, 스토어 등록 정보가 사용자가 받게 될 내용을 정확히 설명하지 못합니다.
- 설명 요청: 리뷰어가 비즈니스 모델, 하드웨어 의존성, 계정 경로 또는 네이티브 기능을 이해하지 못했을 수 있습니다.
- 이의 신청 후보: 인용된 가이드라인이 잘못 적용되었다고 판단하거나, 제출된 빌드가 이미 이를 충족하며 빠르게 증명할 수 있는 경우입니다.
Capacitor 앱은 네이티브와 웹 레이어 사이의 경계에서 각별한 주의가 필요합니다. 리뷰어는 빈 WebView, 오래된 JavaScript bundle, 잘못된 경로로 열리는 딥링크, 핵심 제품처럼 보이는 외부 페이지, 또는 실제 기능이 보이지 않는 권한 prompt를 마주할 수 있습니다. Electron 제출물도 외부 콘텐츠, 업데이트 동작, 플랫폼 권한, 그리고 패키징된 경험이 브라우저 창 그 이상을 제공하는지 여부와 관련해 유사한 경계 문제를 겪습니다.
실무 원칙: 정확한 리뷰어 경로, 해당 빌드, 그리고 그 경로가 이제 정상 작동한다는 증거를 명확히 제시할 수 있을 때까지 단순히 “수정 완료”라고 답하지 마세요.
리뷰 일정은 Apple의 대기열, 문제의 복잡성, 그리고 리뷰어가 추가 검토가 필요한지에 따라 달라집니다. 예상 처리 시간을 근거로 출시일을 약속하지 마세요. 문제가 명확하다면 수정 후 재제출하세요. 피드백이 모호하거나 오류로 보인다면, 다음 빌드 사이클을 소모하기 전에 집중적인 질문을 하세요. 어려운 릴리스를 처리하는 팀은 다음 제출 시 기억에 의존하기보다 실패 패턴을 전용 사후 분석(postmortem) 문서로 기록하는 것이 도움이 됩니다. 예를 들어 이 글처럼요. App Store 반려 사고 사례다음 제출 시 기억에 의존하는 것보다
거절의 진짜 원인 진단하기
리뷰어의 카테고리는 시작점일 뿐, 항상 근본 원인은 아닙니다. Apple의 2024년 보고서는 성능, 법률, 디자인, 비즈니스, 안전을 거절 사유의 상위에 배치했으며, 해당 데이터에 대한 독립적 분석은 앱 완성도와 성능 관련 실패를 가장 큰 기술적 원인으로 지목합니다. 그 분석은 2024년 성능 문제 관련 인용 120만 건 이상이 있다고 말하며 미해결 거절 건 중 40% 이상이 해당 카테고리에 속한다고 합니다 (App Store 거절 사유 분석).
유용한 대응은 짧은 트리아지입니다. 제출된 바로 그 아티팩트에서 동일한 계정 상태, 환경, 권한으로 리뷰어의 경로를 재현하세요. 거절이 광범위하게 느껴진다고 해서 무관한 화면을 바꾸거나 메타데이터를 다시 쓰는 것부터 시작하지 마세요.
리뷰 노트를 실제 실패와 매핑하기
| 리뷰어 신호 | 먼저 테스트할 항목 | 흔한 Capacitor 또는 Electron 함정 |
|---|---|---|
| 성능 또는 앱 완성도 | 콜드 런치, 온보딩, 로그인, 주요 액션, 딥링크, 오프라인 및 오류 상태 | 아카이브에서 Web bundle 누락, 스테이징 API, 거부된 라우트, 네이티브 플러그인 실패 |
| 법률 또는 개인정보 보호 | 개인정보 매니페스트, 데이터 선언, 권한 문자열, 계정 삭제, 콘텐츠 권리 | 서드파티 SDK가 미선언된 API 또는 수집 동작을 도입 |
| 디자인 또는 스팸 | 스크린샷, 미완성 상태, 네비게이션, 차별성 부족, 중복된 카탈로그 메타데이터 | 일반적인 래퍼, 플레이스홀더 문구, 중복된 제품 소개 |
| 비즈니스 | 결제 흐름, 구독 문구, 액세스 모델, 외부 결제 언급 | 웹사이트로 연결되는 디지털 권한 또는 리뷰할 수 없는 IAP 제품 |
| 안전성 | 연령 등급, 사용자 생성 콘텐츠(UGC) 제어, 신고, 모더레이션, 민감한 권한 | 프로덕션에는 기능이 존재하지만 제출된 빌드에는 안전장치가 없는 경우 |
성능 문제로 거절된 경우, 클린 설치 및 기존 계정으로 동일한 흐름을 실행하세요. 크래시, 프리징, 빈 API 응답, 플레이스홀더 화면, 깨진 링크, 누락된 에셋, 리뷰 시 다르게 동작하는 피처 플래그를 확인하세요. 로그인이 일회용 code, 개인 기기 또는 백엔드 화이트리스트를 필요로 한다면, 운영자 개입 없이 작동하는 리뷰어용 경로를 만들고 이를 Review Notes에 설명하세요.
법적·개인정보 보호 문제라면 바이너리, App Store Connect 선언, 게시된 정책 세 가지 산출물을 비교하세요. 셋은 동일한 동작을 설명해야 합니다. 2026년에는 독립적인 보도에서 프라이버시 매니페스트 누락, 제3자 또는 AI 데이터 공유 공개, 그리고 도입을 앞둔 요구 사항이 강조됩니다 2026년 4월 28일 App Store Connect 업로드 시 사용하는 iOS 26 계열 SDK이 포함된 Xcode 26 이상 (최근 App Store 및 Play Store 거절 정책 변경 사항 정리). 툴체인을 마지막 순간의 빌드 옵션이 아닌 컴플라이언스의 일부로 취급하세요.
그럴듯한 첫 번째 설명에 그치지 마세요
디자인 관련 항의는 최소 기능 부족이나 스팸 문제를 가릴 수 있습니다. 결제 관련 항의는 StoreKit code 문제가 아니라 비즈니스 모델 자체를 반영할 수 있습니다. 로그인 실패는 인증 버그가 아니라 앱 미완성의 표면적 증상일 수 있습니다.
Google Play에는 자체적인 심사 언어와 정책 집행 방식이 있지만, 동일한 운영 방법이 적용됩니다. 정확한 메시지를 보존하고, 재현하며, 정책 영역을 식별한 뒤 바이너리 변경과 리스팅 또는 커뮤니케이션 변경을 구분하세요. 실용적인 메타데이터 감사는 다음을 포함해야 합니다. 개발자가 알아야 할 App Store 메타데이터 요구 사항, 모든 스크린샷과 주장이 제출된 경험과 일치하는지 여부도 포함됩니다.
심사를 통과하는 규정 준수 재제출 준비
좋은 재제출은 조급한 대체 업로드가 아니라 통제된 변경입니다. 먼저 거부된 아티팩트를 고정하세요. 빌드 번호, JavaScript 번들 버전, 네이티브 의존성 lockfile, 메타데이터 내보내기, 개인정보 보호 선언, 심사 노트를 저장하세요. 이 스냅샷이 없으면 팀은 무엇이 변경되었는지 증명하거나, 두 번째 거부가 다른 실패를 가리키는 이유를 설명할 수 없습니다.
스토어 등록 정보와 바이너리 일치시키기
리뷰어는 스토어 페이지를 실제 사용 가능한 제품과 비교합니다. 출시되지 않은 레이아웃이 보이는 스크린샷은 교체하고, 빌드로 입증할 수 없는 주장은 삭제하세요. 홍보 문구, 키워드, 연령 등급, 카테고리, 지원 링크는 한 묶음으로 점검해야 합니다. 기능이 실제로 작동하더라도 스크린샷에 placeholder 문구가 있으면 메타데이터 문제가 생길 수 있습니다.
구독과 구매는 별도 심사가 필요합니다. 제품명, 가격, 무료 체험 문구, 복원 동작, entitlement 접근, 구매 버튼이 실제 흐름과 일치하는지 확인하세요. 지역 및 제품별 구현이 규정을 준수하고 명확히 문서화된 경우가 아니라면, 디지털 콘텐츠에 대한 외부 결제 언급으로 혼동을 주는 부분은 삭제하세요.
개인정보 보호 및 권한 증빙 자료 재구축
최종 아카이브의 모든 native plugin과 SDK를 점검하세요. 각 권한마다 해당 권한을 사용하는 기능, 사용자에게 표시되는 설명, prompt가 나타나는 시점, 액세스 거부 시의 대체 동작을 기록하세요. 앱에 필요 없는 권한은 제거하세요. Capacitor plugin은 JavaScript code가 무해해 보여도 native 선언을 추가할 수 있으므로, 웹 레이어를 믿지 말고 생성된 iOS 프로젝트와 아카이브된 앱을 검사하세요.
개인정보 보호 라벨과 매니페스트가 실제 동작과 일치하는지 확인하세요. AI, 분석, 광고, 크래시 리포팅 또는 identity SDK가 데이터를 공유하거나 처리한다면, 그 관계를 문서화하고 일관되게 공개해야 합니다. 계정 생성에는 필요한 경우 앱 내 삭제 경로가 포함되어야 하며, 리뷰어 계정에서 해당 경로에 접근할 수 있어야 합니다.
리뷰어가 확인하기 쉬운 바이너리 제작
Capacitor의 경우, 아카이브에 의도한 웹 자산이 포함되어 있는지, 앱이 개발 서버에 의존하지 않는지 확인하세요. 콜드 런칭 상태에서 유니버설 링크나 딥 링크를 테스트하고, 푸시 알림 동작을 확인하며, 메인 여정에 사용된 모든 네이티브 플러그인을 실행해 보세요. Electron의 경우, 프로덕션 웹 콘텐츠를 패키징하고, 업데이트 기능 및 오프라인 동작을 테스트한 뒤, 외부 내비게이션이 핵심 데스크톱 경험을 대체하지 않는지 확인하세요.
제출 날짜에 필요한 Xcode 및 SDK 버전으로 빌드하세요. 시뮬레이터 테스트나 개발자 설치만으로는 부족하며, 클린 디바이스 테스트를 수행해야 합니다. 릴리스 후보에는 아카이브, 웹 번들, 테스트 보고서, 리뷰 노트를 연결하는 불변 식별자가 하나 있어야 합니다.
리뷰 노트를 사용하여 심사자의 추측을 제거하세요:
- 접근: 작동하는 자격 증명을 제공하고, 필요한 설정 사항을 설명하세요.
- 주요 경로: 제출된 기능을 시연하는 첫 번째 화면과 정확한 액션을 명시하세요.
- 하드웨어: 주변기기, 카메라, 위치 신호 또는 알림 권한이 사용 불가능할 때 발생하는 상황을 설명하세요.
- 구매: 샌드박스 제품, 복원 절차, 그리고 심사자가 권한을 테스트할 수 있는 위치를 식별하세요.
- 변경 사항: 거부 사유, 구체적인 수정 사항, 그리고 이를 검증하는 테스트 경로를 명시하세요.
집중적인 제출 워크플로우는 또한 App Store 리뷰 관리 가이드에 문서화되어 있습니다. 노트는 사실에 기반해야 합니다. 출시 시급성으로 설득하는 것이 아니라, 리뷰어가 몇 분 안에 변경 사항을 검증할 수 있도록 도와야 합니다.
효과적인 이의 제기 작성 및 리뷰어 소통법
거부가 잘못되었거나, 모호하거나, 이미 제출된 빌드에서 해결된 경우에 이의를 제기하세요. 명확한 크래시, 미완성 기능, 부정확한 선언, 또는 결제 위반을 수정하지 않으려고 이의를 제기하지 마세요. 리뷰어는 간결한 설명을 바탕으로 업무를 수행할 수 있습니다. 하지만 자신의 제품을 재구성해야 하는 방어적인 에세이를 효율적으로 평가할 수는 없습니다.
증거 중심의 구조 활용하기
네 가지 짧은 항목을 작성하세요:
- 가이드라인을 인정하세요. 가이드라인을 명시하고 우려 사항을 이해하고 있음을 보여주세요.
- 쟁점이 된 사실을 명시하세요. 제출한 동작이나 모델이 요구 사항을 충족하는 이유를 정확히 설명하세요.
- 검증 경로를 제시하세요. 필요한 경우 계정 정보, 화면 이름, 작업, 타임스탬프를 포함하세요.
- 증거를 첨부하세요. 핵심만 담은 화면 녹화, 주석이 달린 스크린샷, logs, 정책 문서 또는 제품 설정 증거를 추가하세요.
디자인 또는 스팸 관련 이슈의 경우, 브랜딩 문구가 아닌 실제 경험을 통해 차별성을 입증하세요. 리뷰어가 놓쳤을 수 있는 고유한 워크플로우, 네이티브 기능, 독창적인 콘텐츠 또는 타깃 사용 사례를 식별하세요. 비즈니스 거절의 경우, 실물 상품, 서비스, 구독, 디지털 콘텐츠를 구분한 뒤 결제가 어디서 발생하고 사용자가 무엇을 받는지 정확히 보여주세요.
성능 관련 답변에는 테스트한 기기 또는 환경, 실패한 경로, 수정 사항 및 새로운 결과를 포함해야 합니다. 관련 증거가 특정 경로만 다루고 있다면 단순히 “모든 것이 잘 작동한다”라고 주장하는 것은 피하세요. 리뷰어는 지적된 이슈에 대한 핵심만 짚은 답변을 원합니다.
커뮤니케이션 표준: 리뷰어가 추가 질문 없이 당신의 주장을 확인할 수 있어야 합니다.
안내문에 구체적인 재현 방법이 없는 광범위한 가이드라인만 인용되어 있다면, Resolution Center를 통해 명확한 설명을 요청하세요. 반복된 답변에도 모호한 해석이 해결되지 않으면, 대화를 요청하고 구체적인 질문 목록을 서면으로 준비하세요. 에스컬레이션을 위협하거나 대화를 협상처럼 구부지 마세요. 생산적인 태도는 다음과 같습니다: “이것이 가이드라인이고, 이것이 동작이며, 이것이 테스트 방법이고, 이것이 증거입니다.”
이의 신청은 자체적으로 성립해야 합니다. 필요 시 관련 정책 페이지를 링크하되, 무관한 문서로 논점을 흐리지 마세요. 거부 후 앱을 수정했다면 솔직히 명시하고, 제출되지 않은 수정 사항이 유효하다고 주장하기보다 새로운 빌드를 다시 제출하세요.
전체 심사가 필요 없을 때 기다리지 않고 수정하기
다음으로 구분하면 릴리스 결정이 명확해집니다. 웹 레이어 동작 과 네이티브 권한. Capacitor 또는 Electron 팀은 네이티브 바이너리를 변경하지 않고도 카피, 스타일링, 라우트 로직, 기능 플래그, 설정 및 기타 JavaScript나 CSS 동작을 수정할 수 있습니다. 네이티브 code, 권한, 권한 선언, 번들링된 플러그인, 서명 설정 및 SDK 변경은 새로운 스토어 제출을 요구합니다.
이 구분이 허점을 만들지는 않습니다. OTA 업데이트로 금지된 비즈니스 모델이 승인되거나, 바이너리에 이미 있는 권한 선언이 제거되거나, 리뷰어가 평가해야 할 누락된 네이티브 기능이 대체될 수는 없습니다. 설치된 바이너리와 업데이트 메커니즘이 이미 스토어 규칙을 준수하고 있다면, 웹 계층의 결함을 수정할 수는 있습니다.
최소한의 안전한 경로 선택하기
| 상황 | 적절한 릴리스 경로 | 필요한 제어 |
|---|---|---|
| 오타, 문구 불일치, CSS 결함, 라우트 버그 | 타겟 지정 웹 업데이트 | 변경된 화면 검토 및 대상 사용자 제한 |
| 작동하지 않는 API 엔드포인트 또는 기능 플래그 | 웹 업데이트 또는 백엔드 롤백 | 폴백 경로 확인 및 에러 모니터링 |
| 네이티브 플러그인 크래시 또는 권한 누락 | 새 바이너리 | 다시 빌드, 아카이브 테스트, 선언 업데이트 |
| IAP 구현 또는 엔타이틀먼트 문제 | 새 바이너리 및 스토어 설정 | 샌드박스 구매 및 복원 동작 테스트 |
| 정책 해석 또는 메타데이터 거부 | 리스팅 변경, 설명 보완 또는 재제출 | Review Notes에 정확한 수정 사항을 설명하세요 |
웹 레이어 수정이라면 먼저 스테이징에 릴리스하세요. 서명된 번들, 소규모 테스트 그룹, 디바이스 수준 로그, 적용률과 실패 신호, 명시적인 롤백 버전을 활용하세요. 지원되는 모든 디바이스에서 해당 경로가 정상 작동하면, 추적되지 않은 변경 사항으로 다시 빌드하지 말고 동일한 아티팩트를 프로덕션으로 승격하세요.
Capgo는 대상 채널에 서명된 웹 번들을 전달하여 CapacitorJS 및 Electron 애플리케이션을 위한 이 운영 모델을 지원합니다. 버전 히스토리, 차분 업데이트, 디바이스별 관측성, 자동 롤백 보호 기능을 갖춥니다. 팀은 스테이징, 베타, 프로덕션 또는 고객 전용 스트림용 채널을 사용할 수 있지만, 통제는 긴급성보다 더 엄격하게 유지되어야 합니다. live update은 복구를 더 안전하게 만들어야지, 릴리스 리뷰를 보이지 않게 만들어서는 안 됩니다.
실전 App Store에서 안전한 OTA 업데이트 가이드 거절된 동작이 업데이트 가능한 웹 레이어에 있는지 네이티브 패키지에 있는지 판단할 때 유용합니다. 영향받는 모든 대상에 대해 설치된 네이티브 버전, 전달된 번들, 정책 상태, 롤백 결정을 기록해 두세요.
더 나은 제어로 다음 App Store 거절 방지하기
팀이 제출 후에야 예방 가능한 결함을 알게 되면 거절 비용이 커집니다. 지속 가능한 해결책은 스토어 바이너리, 웹 번들, 메타데이터, 개인정보 보호 선언, 리뷰어 경로를 하나의 프로덕션 변경으로 다루는 릴리스 제어 시스템입니다.
CI에서 시작하세요. 필요한 Xcode 또는 SDK 툴체인이 잘못되었거나, 프라이버시 매니페스트가 누락되었거나, 선언된 권한에 매핑된 기능이 없거나, 프로덕션 아카이브에 개발용 엔드포인트가 포함된 경우 빌드를 실패시키세요. 오래된 스크린샷, 플레이스홀더 문자열, 누락된 지원 URL, 제품에서 더 이상 나타나지 않는 메타데이터 문구에 대한 검사도 추가하세요. 이 검사는 사람의 리뷰를 대체하지 않습니다. 피할 수 있는 누락을 제거할 뿐입니다.
릴리스 증빙 자동화하기
유용한 릴리스 기록에는 다음이 포함됩니다:
- 아티팩트 식별: 네이티브 빌드, 웹 번들, 소스 리비전, 의존성 lockfile, 서명 컨텍스트.
- 리뷰어 경로: 테스트 계정, 온보딩 경로, 구매 경로, 하드웨어 가정, 리뷰 노트.
- 동작 증거: 클린 설치 테스트, 재방문 사용자 테스트, 딥링크 테스트, 권한 거부 테스트, 오프라인 또는 API 실패 시 동작.
- 운영 제어: 스테이징 채널, 프로덕션 대상, 롤백 대상, 텔레메트리 대시보드, 담당 온콜.
텔레메트리는 리뷰어가 문제를 발견하기 전에 크래시, 실패한 런칭, 라우트 오류, 플러그인 예외, 로그인 실패, 업데이트 채택률을 노출해야 합니다. 데이터는 개인정보 보호를 준수하면서도 인시던트를 디바이스, 네이티브 버전, 웹 번들과 연결할 수 있을 만큼 유용해야 합니다. 롤백은 문제를 일으킨 아티팩트를 정확히 알고 추가 배포를 중단할 수 있을 때만 안전합니다.
공식 스토어 외에서 Android 애플리케이션을 유지 관리하는 팀도 검토할 수 있습니다 사이드로딩 앱을 위한 APKUpdater 별도의 배포 관리 참고 자료로. 사이드로딩은 플랫폼 정책 의무를 면제하지 않지만, 통제된 내부 또는 대안 배포 시나리오에 관련될 수 있습니다.
인간 체크리스트는 짧고 필수적으로 유지하세요. 프로덕트는 리스팅이 경험과 일치하는지 확인합니다. 엔지니어링은 아카이브와 네이티브 선언을 확인합니다. QA는 리뷰어 경로를 확인합니다. 보안 또는 개인정보 담당자는 데이터 공개 사항을 확인합니다. 릴리스 매니지먼트는 아티팩트와 롤백 계획을 기록합니다. 앱 릴리스 품질 보증 프로세스 는 채팅 스레드에 남겨두지 않고 해당 승인 사항을 가시화해야 합니다.
지루한 리뷰가 목표입니다. CI가 매니페스트 드리프트를, 스테이징이 라우트 실패를, 텔레메트리가 크래시를, 롤백이 사용자를 보호할 때 앱 스토어 거절은 런칭 위기가 아닌 통제된 릴리스 인시던트가 됩니다.
Capgo는 CapacitorJS 및 Electron 팀이 웹 레이어 수정을 제어하고, 스테이징 및 프로덕션 채널을 통해 타겟 릴리스를 수행하며, 채택률과 실패를 관찰하고, 업데이트에 문제가 발생하면 롤백할 수 있도록 지원합니다. 방문하기 Capgo 앱 스토어 반려 워크플로우를 더 안전한 릴리스 및 복구 프로세스로 연결하세요.
