애플이 검토한 2025년 9,100,620개의 앱 제출 중 2,093,244개를 반려했습니다.iOS 앱 제출 387,087 건이 심사 후 승인되었습니다.Apple의 앱 스토어 투명성 데이터에 따르면 약 387,087 건이 심사 후 승인되었습니다.초기 거부율은 약 23%입니다. iOS 앱 제출은 단순 업로드 단계가 아닌, 심사 과정을 거치는 출시 과정입니다.Apple은 또한
90%의 제출물이 24시간 이내에 검토된다고 말합니다. App Review 페이지 빠른 검토는 유용하지만 승인은 자동이 아닙니다. 정상적으로 출시하는 팀은 제출을 출시 과정으로 다루는 경향이 있습니다.submission 반려 회피 시스템: native shell의 안정성을 확보하고 리뷰어 친화적인 빌드를 준비하고, 웹-layer 문제를 해결하기 위한 안전한 경로를 유지하는 반면, 모든 급한 복사본 또는 스타일링 버그를 새로운 스토어 제출으로 변환하지 않도록 주의한다.
목차
- iOS 앱 제출이 실제로 무엇을 포함하는가
- 서명 실패를 방지하는 전제 조건
- Capacitor 앱을 릴리스하기 위해 Xcode에서 프로젝트를 준비
- iOS 앱 제출
- 앱 리뷰를 처리하고 일반적인 거절을 피하는 방법
- 새로 제출하지 않고 모든 것을 다시 제출하지 않고 최종 확인과 배송 업데이트
iOS 앱 제출이 실제로 무엇을 포함하는지
Consider a typical failure pattern: a team finishes a Capacitor app late on a Friday, archives it in Xcode, uploads the build, and assumes the hard part is over. During review, Apple finds that the login account fails, a backend endpoint is unavailable, or a feature described in the metadata cannot be reached. The rejection may arrive quickly, but the fix still requires a new build, another upload, another review cycle, and a release plan that never allowed for interruption.
제출을 반려-회복 시스템Xcode에서 시작하는 완전한 경로가 아님
- 애플 개발자 프로그램에 가입하세요 인증 및 앱 스토어 연결에 대한 접근 권한이 있는 사람들을 확인하세요.
- 앱 식별자 및 기능, 인증서 및 배포 설정을 포함하여 앱 식별자를 생성하고 구성하세요.앱 스토어 연결 레코드를 생성하세요.
- 앱 스토어 연결 레코드의 매칭된 번들 식별자와 일치해야 합니다. 릴리즈 아카이브를 빌드하고 서명하세요.
- Xcode 또는 제어된 CI 워크플로우를 통해 빌드하고 서명하세요. 바이너리를 업로드하세요.
- 바이너리를 업로드한 후 테스트 플라이트를 사용하여 배포할 예상되는 정확한 아티팩트를 실행하세요.__CAPGO_KEEP_0__
- Complete metadata and review information, 애플의 결정을 위해 버전을 제출하고 반응합니다.
Apple이 평가하는 세 가지 층
패키지에는 세 개의 연결된 층이 있습니다.
The 바이너리 층 컴파일된 애플리케이션, 서명, 권한, 네이티브 플러그인, 개인 정보 공개, 런타임 동작입니다. The 메타데이터 층 스크린샷, 설명, 키워드, URL, 연령 등급 응답, 개인 정보, 앱 리뷰 정보가 포함됩니다. The 정책 층 앱이 어떻게 동작하는지, 사용자 데이터를 어떻게 처리하는지, 스토어ーフ런트 구현이 애플의 규칙을 따르는지 등이 포함됩니다.
A Capacitor 앱은 특정 복잡성을 추가합니다. 자바스크립트와 CSS는 플랫폼을 가리지 않지만 iOS wrapper는 여전히 Xcode target, 네이티브 의존성, 권한 설정, 서명 설정 및 내장 웹 자산 집합이 있습니다. 플러그인, URL scheme, 푸시 알림 기능 또는 네이티브 구성의 변경은 정상적인 웹 릴리스를 네이티브 릴리스로 바꿀 수 있으며 검토를 통과해야 합니다.
실용적인 규칙: 모든 제출을 개발자의 로컬 컴퓨터의 최신 폴더로 간주하지 말고 재현 가능한 릴리스 아티팩트로 다루세요.
애플의 검토 큐도 릴리스 계획에 영향을 미칩니다. 애플은 동일한 플랫폼에서 최대 두 개의 제출을 동시에 검토할 수 있습니다. 하나의 앱 버전과 하나의 아이템, 예를 들어 In-App Event에 따라 애플의 제출 지침에 따라.릴리스 критカル한 변경 사항을 하나의 큐 위치로 배치하면 피할 수 있는 위험이 발생합니다. 앱 버전을 먼저 스테이지하고, 제출 전에 App Review 정보를 완료하고, 웹 레이어 수정과 네이티브 변경을 가능한 한 분리하세요. 웹 레이어 수정은 제어된 라이브 업데이트 통해 배포할 수 있습니다. 네이티브 변경은 여전히 일반 검토 큐에 속합니다. 팀은 App Store 검토 관리를 통해 소유권, 상태 확인 및 응답 절차를 문서화할 수 있습니다.이러한 절차는 거부가 발생하면 제어된 수정 대신緊急 재구축을 방지합니다.
검토를 통과하기 위한 서명 실패를 방지하는 필수 조건 App Store review managementApp Store review management
App Store review management
구독 실패는 일반적으로 구성漂移로 시작됩니다. App Store Connect의 Bundle ID는 Xcode의 대상과 다르며, 프로젝트에는 기능이 있지만 개발자 포털에는 없거나, 인증서가 프로비전 프로파일을 포함하지 않아 CI 머신에 있는 경우가 있습니다. 개발이 릴리스 주에 도달하기 전에 이러한 문제를 해결하는 것은 아카이브가 실패한 후에 더 느립니다.
계정 및 소유 모델을establish합니다.
Apple Developer 계정이 활성화되어 있고, 릴리스에 대한 책임이 있는 사람들은 개발자 포털과 App Store Connect에 접근할 수 있는지 확인합니다. 팀은 책임을 분리하기 때문에 인증서를 관리하는 사람과 메타데이터를 제출하는 사람으로 구분할 수 있습니다. 특히 기관, 계약자 또는 스타트업 창업자와 관련된 경우, 각 액션의 소유자를 기록하세요.
업로드하기 전에 App Store Connect 앱 레코드를 선택합니다. 올바른 플랫폼, 주요 언어, 앱 이름, Bundle ID, 및 SKU를 선택하세요. Bundle ID는 Xcode의 대상과 정확히 일치해야 합니다. 잘못된 식별자를 가진 레코드는 파일 이름을 변경하여 수정할 수 없습니다.
식별자 및 기능을 확인합니다.
Apple Developer 포털에서 앱과 관련된 App ID를 검사합니다. 필요한 기능만 활성화하세요. 예를 들어, 푸시 알림, 연관된 도메인, Sign in with Apple, 또는 키 체인 공유와 같은 기능입니다. 그런 다음 Xcode의 Signing & Capabilities 탭과 비교합니다.
또한, Capacitor에서 식별자를 확인하세요. capacitor.config 또는 capacitor.config.ts, the iOS project target, and the app record. If you’ve changed the app ID, run the appropriate Capacitor synchronization command and inspect the native project instead of assuming the generated configuration updated every target.
자동 인증서 및 프로파일 관리를 원하는 경우 Xcode가 정기적인 인증서 및 프로파일 관계를 관리하도록 자동 인증서를 사용하세요.
릴리즈 전 검사를 실행하세요
아카이브하기 전에 확인하세요
- 계정 접근 권한: 선택한 Apple 팀이 의도한 조직이 아닌 개인 또는 유산 팀인지 확인하세요
- 앱 번들 식별자: Xcode 대상, Capacitor 구성, 앱 ID, App Store Connect 기록이 동일한 식별자를 사용하는지 확인하세요
- 능력: 권한이 App ID에 활성화된 서비스와 일치하는지 확인하세요
- 배포 인증: 선택한 배포 식별자가 유효하고 빌드 환경에 사용 가능한지 확인하세요
- 설정: 프로파일은 올바른 App ID, 인증서 및 배포 방법과 일치합니다.
- 대상: 확장, 알림 서비스 및 기타 패키지된 대상은 호환되는 서명 설정을 사용합니다.
- 비밀: CI는 저장소에 노출되지 않도록 인증서 및 프로파일이 필요합니다.
성공적인 개발 빌드는 앱을 실행할 수 있는 팀이 있다는 것을 증명합니다. 그러나 배포할 수 있다는 것을 증명하지는 않습니다.
여러 앱이나 환경을 관리하는 팀의 경우 인증서 소유권은 전용 프로세스가 필요합니다. 만료일, 책임 있는 소유자, 갱신 단계 및 프로파일이 설치된 위치를 기록하세요. Capacitor 인증서 관리 __CAPGO_KEEP_0__ 인증서 관리는 개발자 한 명의 로컬 설정에 의존하지 않고 workflow를 구조화하는 유용한 참고 자료입니다.
Capacitor 앱을 릴리스하기 위한 빌드 및 서명
릴리스 아카이브에는 배포하려는 웹 자산이 포함되어야 합니다. Capacitor 프로젝트의 경우, 프론트엔드 빌드를 먼저 수행한 다음 네이티브 프로젝트를 동기화하고 iOS 대상 확인하고 아카이브를 생성하세요. 오래된 www 디렉토리는 유효한 서명된 애플리케이션을 생성할 수 있지만陈舊한 화면, 누락된 수정 사항, 또는 불일치된 구성이 있을 수 있습니다.
Xcode에서 프로젝트를 준비하세요.
믿을 수 있는 순서는 다음과 같습니다.
- 프로덕션 구성으로 웹 애플리케이션을 빌드하세요.
- Run
npx cap sync iosnative 의존성과 웹 자산이 일치되도록 하세요. - Xcode에서 워크스페이스를 열지 마세요. 옛날 프로젝트 파일을 열지 마세요.
- 선택한 앱 스키마와 일반 iOS 배포 대상 선택하세요.
- 마케팅 버전과 빌드 번호를 확인하세요.
- 앱 및 모든 확장 대상의 서명 및 기능을 검토하세요.
- 릴리스 빌드 또는 아카이브를 실행하세요.
App Store Connect에 표시되는 버전은 Xcode 대상에 구성된 버전과 일치해야 합니다. 업로드된 아티팩트와 관련된 각 버전에 대해 빌드 번호가 증가해야 합니다. 소스 제어에서 이러한 값을 유지하거나 CI에서 생성하십시오. 여러 대상에 수동으로 편집하는 것은 업로드한 잘못된 아티팩트를 올리는 쉬운 방법입니다.
Xcode가 프로비저닝 프로파일을 찾을 수 없다고 보고하면 먼저 팀과 Bundle ID를 확인하십시오. 서명 인증서가 유효하지 않다고 말하면 기계가 수행하는 아카이브를 검사하십시오. 특권이 거부되면 App ID에 활성화된 기능과 파일을 비교하십시오. 이러한 오류를 해결하기 위해 임의로 서명 옵션을 토글하지 마십시오. 일치하는 부분을 찾으십시오. .entitlements 파일과 활성화된 기능을 비교하십시오.
Xcode에서 선택하십시오.
Product ,Archive .처리 후 Organizer를 열고 Distribute App ,테스트 플라이트와 앱 스토어의 배포 경로를 선택하십시오. Xcode는 업로드 전에 아카이브를 검증하지만 검증은 설치된 빌드 테스트와 대체되지 않습니다.
테스트 플라이트를 통해 업로드된 빌드를 설치하고 Apple이 검사할 가능성이 있는 흐름을 실행하십시오:
- 첫 번째 런칭 및 온보딩
- 계정 생성 및 로그인
- 비밀번호 초기화 또는 마법 링크 접근
- 구매 및 구독 복원
- 카메라, 마이크, 위치, 알림 권한
- 깊이 있는 링크 및 외부 인증
- 오프라인 동작 및 요청 실패 후 복구
- 스크린샷 또는 메타데이터에 설명된 모든 기능
Capacitor 앱은 개발 환경의 백엔드 URL, 웹 자산 경로, 네이티브 권한 문자열 또는 플러그인 구성이 프로덕션 환경과 다르기 때문에 컴파일을 통과할 수 있지만 런타임에 실패할 수 있습니다. 테스트를 위해 깨끗한 기기 또는 깨끗한 시뮬레이터 상태에서 테스트하고, App Review에 제공할 계정 세부 정보와 정확히 동일한 계정 세부 정보를 사용하여 테스트하세요.
관리형 빌드 인프라 또는 CI를 사용하는 팀은 신뢰할 수 있는 Mac 릴리즈 환경이 없는 경우 Capacitor iOS 빌드를 자동화하는 GitHub Actions은-archive 생성, 서명, 아티팩트 처리를 공식화할 수 있습니다. 내부적으로 이 과정을 소유하는 조직이 채용할 경우 __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ iOS 개발자 채용 스타트업을 위한 iOS 개발자 채용에 대한 정보
아래의 비디오는 Xcode의 워크플로우의 시각적인_walkthrough입니다.
업로드하기 전에, 압축파일의 ID, 버전, 빌드번호, 포함된 아키텍처, 권한, 임베디드 자산을 검사하세요. 압축파일은 커밋, 웹 빌드, 환경 설정, 릴리즈 노트와 함께 유지하세요. 검토 중에 질문이 발생하면, 추적성은 정확한 답변을 제공할 수 있습니다.
테스트 파일럿과 앱 스토어 메타데이터 완료
바이너리 업로드는 완료된 제출이 아닌 제어된 릴리즈 프로세스를 시작합니다. Xcode Organizer는 아카이브를 App Store Connect로 전송할 수 있으며, Transporter는 별도의 전달 도구를 선호하는 팀을위한 선택입니다. App Store Connect는 업로드를 처리하기 전에 빌드는 테스트 파일럿 또는 버전 선택에 사용할 수 있습니다. 릴리즈 윈도우가 급박해지기 전에 프로세싱 지연과 유효성 검사 경고를 해결하세요.
테스트 파일럿을 릴리즈 게이트로 사용하세요
TestFlight를 통해 처리된 빌드를 설치하세요. 지역 Xcode 런치에서는 App Store Connect 팀 외의 사람들에 의해 발생할 수 있는 분산 특정 동작, 특권, 구성 차이점을 놓치실 수 있습니다. 내부 테스터들은 핵심 흐름을 빠르게 확인할 수 있습니다. 외부 테스터들은 App Store Connect 팀 외의 사람들에 의해 발생할 수 있는 문제를 노출할 수 있습니다. 그룹을 목적에 맞게 유지하세요: 제품 그룹은 기능 동작을 검증할 수 있지만 릴리즈 그룹은 업그레이드, 인증, 권한, 충돌 위험이 있는 경로를 확인할 수 있습니다.
베타 노트는 변경된 내용과 테스터가 어디서 확인해야 하는지 설명해야 합니다. 동일한 증거를 준비하세요. 앱 리뷰 정보. 로그인 요구 시 작동하는 데모 계정을 제공하세요. 설정 단계를 설명하고 첫 번째 화면에서 명확하지 않은 기능을 식별하세요.
제품 페이지를 완성하세요.
메타데이터는 바이너리가 지켜야 하는 약속입니다.
앱 이름, 서브 타이틀(필요한 경우), 설명, 키워드, 스크린샷, 카테고리, 연령 등급 응답, 개인 정보 세부 정보, 지원 URL, 마케팅 URL을 준비하세요. 개발 네트워크 외의 모든 URL을 테스트하세요. 내부 VPN 요구 사항, 인증서 오류, 깨끗한 기기 로그인 오류는 그렇지 않으면 안정적인 제출을 약화시킬 수 있습니다.
스크린샷은 현재 인터페이스와 사용 가능한 기능을 반영해야 합니다. 임시 복사본, 디버그 레이블, 완성되지 않은 빈 상태, 환경 특정 콘텐츠를 제거하세요. 여러 스토어하우스 또는 언어를 지원하는 경우 각 지역화된 버전을 검토하는 것이 번역된 문자가 충분하다고 가정하는 것보다 낫습니다. 개발자용 앱 스토어 메타데이터 가이드 제품 흐름을 설명하는 것은 완전한 field만으로는 불가능합니다. 제품 페이지에 표시된 가치를 이해하기 위해서는 리뷰어도 추가적인 작업이 필요합니다.
버전 제출을 의도적으로 분리합니다.
버전 제출과 홍보 물품을 별도의 릴리즈 결정으로 다룹니다. 앱 고정 제어가 가용성에 영향을 미치는 경우 릴리즈-중요한 버전을 먼저 제출합니다. 해당 버전과 연관된 In-App Event가 있다면, 릴리즈 계획과 함께 준비한 asset와 date를 함께 제출할 때까지, 리뷰된 빌드에서 작동할 수 있는지 확인합니다. 이로 인해 마케팅 아이템이 버전 패키지의 이유가 되지 않도록 하며, 관련된 런칭 작업을 추적할 수 있습니다.
App Store Connect가 빌드를 처리한 후, 버전에 해당 빌드를 선택하고, 수출 준수 및 콘텐츠 권리 질문에 답변하고, 리뷰 노트를 첨부한 후 제출합니다. 제출한 빌드 번호와 정확한 메타데이터 스냅샷을 기록합니다. Apple이 리뷰어에게 어떤 흐름, 계정, 또는 백엔드 버전을 만났는지 물어본다면, 이 기록은 정확한 답변을 지원합니다.
Capacitor 팀은 웹-layer 수정과 네이티브 릴리즈 변경을 분리하여야 합니다. 제어된 라이브 업데이트는 자바스크립트나 자산 오류를 수정할 수 있습니다. 네이티브 code, 권한, 플러그인 및 설정은 일반 빌드 및 검토 경로를 필요로 합니다. 이 분리는 제출을 거부에 대한 내구성 시스템으로 바꾸어, 검토된 바이너리를 철저히 테스트하고, 네이티브 승인 필요로 하는 변경 사항에 대한 급한 재제출을 예약합니다.
애플리케이션 검토 및 일반적인 거부를 피하는 방법
거부 데이터는 실용적인 결론을 내립니다: 팀은 더 이상 모호한 검토자의 선호도에 대한 추측을 하며, 앱이 완전한, 기능적인, 그리고 접근성이 있는지 증명하는 시간을 더 보내야 합니다. 애플의 2025년 분석에 따르면 1,354,418 건의 성능 관련 거부 사례가 발생했습니다.그리고 애플의 앱 검토 지침 은 완전한 버전의 앱에 완전한 메타데이터, 기능적인 URL, 라이브 백엔드 서비스, 데모 접근 권한, 그리고 비직관적인 기능에 대한 자세한 설명이 포함된 버전을 요구합니다.
제출된 빌드를 내구화하세요
검토자는 팀의 맥락 없이 앱을 만날 수 있습니다. 만약 첫 번째 화면이 계정 요구를 하는 경우 사용 가능한 자격 증명을 제공하세요. 만약 구독이 특정 탐색 경로 뒤에 숨겨져 있다면 설명하세요. 만약 하드웨어 기능이 설정이 필요하다면 설명하세요. 만약 백엔드가 유지 보수 기간이 있다면 제출을 해당 기간에 맞추세요.
실제 조건에서만 나타나는 성능 문제는 특히 위험합니다. 테스트할 수 있는 조건은冷시작, 느린 네트워크, 중단된 요청, 큰 계정, 권한 거부, 배경에서 돌아오기 등입니다. Capacitor 셸 내부의 웹-layer 오류는 리뷰어에게 네이티브 앱 오류처럼 보일 수 있으므로 프론트엔드 오류와 네이티브 크래시 리포트를 함께 캡처하세요.
스토어 фрон트 규칙을 릴리즈 입력으로 다루세요.
2025년 애플의 변경 사항은 미국 스토어 프론트 앱과 버튼, 외부 링크, 대체 구매 방법을 위한 호출을 포함한 규칙을 변경했습니다. 애플은 변경된 규칙을 Guidelines 3.1.1, 3.1.1(a), 3.1.3, 3.1.3(a)로 식별했습니다. 그것은 스토어 프론트의 가정에 맞는 모니터링 흐름이 다른 곳에서는 다른 처리가 필요하다는 것을 의미합니다. 그것은 리뷰어에게 숨기지 말라는 것이 아니라, 제출하기 전에 의도한 스토어 프론트, 결제 흐름, 버튼, 링크, 설명서를 맵핑해야 한다는 것을 의미합니다. 리뷰어는 정책 분석이 기대하는 동작을 동일하게 볼 수 있어야 합니다.
리뷰 거부 요인
| 예방 조치 | 재제출 필요 | 인COMPLETE 앱 흐름 |
|---|---|---|
| 장치에서 제거된 placeholder를 제거하고 온보딩을 완료하고 모든 광고된 기능을 테스트하세요. | 일반적으로, 이진 동작이 완전하지 않으면... | Usually, if the binary behavior is incomplete |
| 로그인 오류 또는 백엔드 unavailable | 작업 가능한 데모 접근 권한 제공하고 리뷰 중에 프로덕션 서비스 유지 | Yes, 바이너리 또는 서비스 계약 내부의 실패 시 |
| 성능 및 안정성 문제 | 냉각된 런칭 테스트, 네트워크 중단, 권한, 및 오랜 흐름 | 보통, 특히 네이티브 또는 패키지 code 변경 시 |
| 비직관적인 기능 | 단순한 App Review 메모 작성에 정확한 네비게이션 단계 포함 | 항상 그렇지 않음, 만약 문제가 오직 미흡한 컨텍스트만이고 빌드가 이미 작동하는 경우 |
| 브레이크된 URL 또는 미완성된 메타데이터 | 깨끗한 환경에서 개인 정보, 지원, 마케팅, 및 기능 링크를 유효화 | Yes, 만약 URL이 앱 내부에 포함되어 있거나 메타데이터를独立적으로 수정할 수 없는 경우 |
| 구매 및 외부 링크 정책 불일치 | 스토어 프론트에 구현된 내용을 현재 지침 섹션과 비교하여 검토하십시오 | 버튼, 링크 또는 네이티브 구매 동작이 변경되어야 할 때 일반적으로 |
네이티브.fixes와 웹-layer.fixes를 분리하십시오
Capacitor 팀의 경우, 재건축 이전에 고장 회복 시스템이 고장을 분류해야 합니다. Swift code, 플러그인, 권한, 네이티브 구성, 임베디드 SDK 또는 앱의 기본 동작에 대한 변경은 일반 App Store 검토 큐에 속합니다. JavaScript, CSS, 복사본 및 웹 자산은 때때로 Apple의 규칙을 준수하는 경우에만 live-update 메커니즘을 통해 전달될 수 있으며, 업데이트가 검토된 제품과 물리적으로 다르지 않도록 유지되면 됩니다.
Capgo은 목표 채널로 전달되는 서명된 웹 번들을 제공하는 데 사용할 수 있는 옵션입니다. 이에 따라 중간에 롤백 제어가 가능하며, 네이티브 변경은 여전히 정상적인 검토 경로를 따릅니다. 이는 정책 준수에 대한 대안이 아닙니다. 제출된 네이티브 셸과 선언된 기능은 완전하고 검토 가능한 상태여야 합니다.
최종 확인 및 제출 업데이트
신뢰보다는 확인을 통해 신뢰할 수 있는 릴리스 루프를 마무리하십시오. 제출 전에 확인하십시오. 버전 및 빌드 번호iOS 앱 제출
승인 후, 충돌 보고서, 프론트엔드 오류, 로그인 실패, 지원 티켓을 감시하십시오. 거부 후, Resolution Center 메시지를 신중히 읽으십시오, 정확한 문제를 재현하고, 구체적인 네비게이션 단계를 제시하거나 수정된 빌드를 제출하십시오. 만약 거부가 잘못된 것처럼 보인다면, Apple의 통신 및 항변 채널을 사용하십시오.
live-update 워크플로우는 적격한 웹层 수정을 단축할 수 있습니다. App Store-safe OTA 업데이트에 대한 Capgo 이 설명서에서는 운영 모델을 설명합니다: 서명된 번들을 제어된 채널에 게시하고, 선택된 대상에게 배포하고, 수용과 실패를 모니터링하고, 롤백 보호를 유지합니다. 프로덕션 릴리즈는 좁게 유지하고, 업데이트를 테스트하기 위해 스테이징 채널을 사용하고, 변경이 검토된 네이티브 표면을 영향받는 경우에는 네이티브 제출을 요구하십시오.
유지 가능한 속도는 간단합니다: 네이티브 변경을 의도적으로 제출하고, 모든 약속된 흐름을 테스트하고, 제어된 릴리즈 시스템을 통해 적격한 웹-layer 개선 사항을 제공하십시오.그것은 iOS 앱 제출을 반복적인 화재 훈련에서 팀이 운영할 수 있는 릴리즈 프로세스로 변환합니다.
Capgo는 Capacitor 팀이 서명된 자바스크립트, CSS, 복사본, 구성, 및 자산 업데이트를 대상 채널에 통해 롤아웃 모니터링 및 롤백 보호를 제공하는 동안 네이티브 변경은 App Review를 통해 계속됩니다. Visit Capgo iOS 앱 제출에 실제로 무엇이 포함되는지 보기 위해 iOS 릴리스 워크플로에 그 거절 저항적인 업데이트 경로를 추가하는 방법을 알아보세요.
