Capgo 기본 채널이 기기를 업데이트하지 않는 문제 수정

Cloud Default 변경하기 Capgo 새 기기는 즉시 라우팅됩니다. 기존 설치본은 다시 체크인할 때까지 이전 채널에 남아 있을 수 있으며, 이 때문에 Capgo cloud default channel이 기기를 업데이트하지 않는 경우가 많습니다.

점검 항목을 순서대로 진행하세요. 먼저 기기 할당을 확인한 다음, 앱 빌드, 동기화 상태, 롤아웃 규칙, 로그, 롤백 설정을 검토하세요.

목차

• 1단계: 디바이스가 Default Channel에 할당됐는지 확인
• 2단계: 앱, Native Runtime, 업데이트 호환성 확인
• 3단계: 배포가 실제로 Default Channel에 반영됐는지 확인
• 4단계: 강제로 새로 동기화하고 디바이스 측 로그 확인
• 5단계: 롤아웃 규칙, 버전 게이트, 자동 롤백 검토
• 6단계: 실시간 분석으로 정확한 실패 지점 찾기
• 7단계: Default Channel이 오래된 상태로 남지 않도록 방지
• 자주 묻는 질문
• 마치며

1단계: 디바이스가 Default Channel에 할당됐는지 확인

목표는 현재 어떤 규칙이 디바이스의 채널을 결정하는지 파악하는 것입니다. Cloud Default는 더 강한 할당이 디바이스를 아직 선점하지 않았을 때만 적용됩니다.

Capgo 대시보드를 열어 해당 디바이스를 점검하세요. 현재 채널, app ID, 버전, 마지막 체크인 시간을 확인합니다. 업데이트가 정상적으로 적용된 디바이스와 이 값들을 비교해 보세요. 이 비교만으로도 문제를 빠르게 파악할 수 있는 경우가 많습니다.

채널 선택에는 순서가 있습니다. 강제 채널이 최우선입니다. 다음은 대시보드 또는 API 디바이스 오버라이드입니다. 그다음이 앱에서 설정한 로컬 채널입니다. 이어서 Capgo 체크가 진행됩니다.defaultChannel네이티브 앱 설정에 정의됩니다. Cloud Default가 fallback입니다.

이 우선순위 때문에 대시보드에 오류가 없어도 기기는 변경된 Cloud Default를 무시할 수 있습니다. 예를 들어 테스트 빌드에 이전 테스트의 로컬 채널이 남아 있을 수 있습니다. 앱은 해당 로컬 값을 지우기 전까지 계속 그 값을 사용합니다.

트레이드오프를 평가하려면 Capgo updater 디버깅 가이드 결정된 채널이 비어 있거나 예상과 다를 때 유용합니다. 앱에 사용할 수 있는 기본값이 없고 기기에 오버라이드도 없는 경우를 다룹니다.

다음으로 Capacitor 설정을 확인하세요. 일반적인 설정에는 다음과 같은 채널이 포함될 수 있습니다:

const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}

이 필드는 선택 사항입니다. 생략하면 기기는 Cloud Default를 상속받을 수 있습니다. 채널 라우팅이 Capgo Cloud에 그대로 유지되므로 프로덕션 빌드에 잘 맞을 수 있습니다. 이 필드를 포함한다면 실제 배포하는 채널과 값이 일치하는지 확인하세요.

이제 애플리케이션 code에서 로컬 오버라이드를 찾아보세요. 다음 호출은setChannel()로컬 캐시를 변경합니다. 백엔드 Device Override를 생성하지 않습니다. 따라서 앱이 로컬 채널을 계속 사용해도 대시보드에는 오버라이드가 없는 것으로 표시될 수 있습니다.

기기가 정상 라우팅으로 돌아가야 할 때 해당 로컬 값을 지우세요. 기기의 채널 할당을 제거하는 플러그인 메서드를 사용하거나, 채널을 설정하는 code를 제거하고 클린 테스트를 위해 앱을 재설치하세요.

핵심 요약: 변경된 Cloud Default는 기기, 앱 또는 로컬 채널 할당보다 우선순위가 낮아 이를 대체할 수 없습니다.

2단계: 앱, Native Runtime, 업데이트 호환성 확인

목표는 설치된 앱이 업로드한 bundle을 수락할 수 있는지 확인하는 것입니다. 채널 설정이 올바르더라도 호환되지 않는 native runtime에는 업데이트를 전달할 수 없습니다.

먼저 app ID를 확인하세요. 기기에 설치된 앱은 bundle을 업로드한 프로젝트와 동일한 app identity를 사용해야 합니다. ID가 일치하지 않으면 기기가 잘못된 Capgo 앱을 확인하게 되어 채널 문제처럼 보일 수 있습니다.

그 다음 native runtime 버전과 bundle의 호환성 규칙을 비교하세요. Capgo live updates는 JavaScript, CSS, web assets를 변경할 수 있습니다. 하지만 앱 출시 후 native plugin을 추가하거나 native project code를 변경할 수는 없습니다. Native 변경 사항은 여전히 새로운 store build가 필요합니다.

native runtime을 web code를 감싸는 프레임이라고 생각하세요. 새 bundle이 설치된 앱에 없는 native API를 요구한다면 Capgo는 이를 적용해서는 안 됩니다. 해당 bundle을 테스트하기 전에 호환되는 native 버전을 build해서 upload 하세요.

설치된 앱의 버전과 플랫폼을 확인하세요. Android bundle은 Android에서, iOS bundle은 iOS에서 먼저 테스트하세요. 채널에서 version gates를 사용한다면 bundle이 올바른 앱 버전을 대상으로 하는지도 확인하세요.

변경 후defaultChannel, 프로젝트 루트에서 sync 명령어를 실행하세요:

npx cap sync

이 단계는 업데이트된 설정을 native projects로 복사합니다. sync 없이capacitor.config수정만 하면 native 앱은 이전 채널 설정을 그대로 유지합니다. 이 오래된 native project에서 다시 build하면 같은 결과가 계속 재현됩니다.

깨끗한 테스트를 위해 동기화 후 새 앱을 빌드하세요. 휴대폰에 설치된 오래된 바이너리에 의존하지 마세요. 캐시된 로컬 채널 상태를 제거해야 할 때는 앱을 삭제한 후 새 빌드를 설치하고 다시 채널을 확인하세요.

이 Capgo 업데이트 동작 문서 업데이터가 번들을 확인하는 시점을 설명합니다. 테스트할 때 이 타이밍을 따르세요. 앱을 실행하거나 포그라운드로 복귀시킨 후, 업데이트 실패로 판단하기 전에 확인이 완료되도록 기다리세요.

번들의 네이티브 버전 게이트도 확인하세요. 번들이 올바른 채널에 있어도 최소 앱 버전이 기기와 일치하지 않아 사용할 수 없는 경우가 있습니다. 최신 업로드가 모든 설치에 적용된다고 가정하지 말고 대시보드에서 릴리스 세부 정보를 확인하세요.

앱이 이 체크를 통과했다면 문제 범위를 좁혔습니다. 다음으로 확인해야 할 것은 릴리스가 의도한 채널에 실제로 도달했는지 여부입니다.

3단계: 배포가 실제로 Default Channel에 반영됐는지 확인

목표는 디바이스가 해석하는 채널에 bundle이 존재하는지 확인하는 것입니다. 한 채널에 bundle을 업로드한다고 해서 모든 채널에서 사용 가능해지는 것은 아닙니다.

Capgo Cloud에서 채널을 엽니다. 활성 bundle, 버전, 배포 상태를 확인하세요. 채널 이름을 앱이 반환하는 값과 비교하세요. 다음과 같은 미세한 차이에 주의하세요.production와prod의 차이. 채널 이름은 정확히 일치해야 합니다.

CI/CD로 배포한다면, 번들을 업로드한 동일한 job의 명령 출력을 확인하세요. CLI에 전달된 app ID와 channel이 맞는지 확인하세요. 파이프라인은 실수로 staging 채널을 대상으로 한 채 업로드 성공으로 끝날 수 있습니다.

다음으로 번들의 상태를 확인하세요. 대시보드에는 draft 또는 inactive 릴리스가 보일 수 있지만, 기기에서는 사용할 수 없습니다. 채널에 staged rollout이 설정되어 있다면, 해당 기기가 롤아웃 규칙을 충족하지 못했을 수도 있습니다.

테스트용 기기 하나를 정하고 역할을 명확히 하세요. 예를 들어, 기기 하나는 test 채널에 고정(pin)하고 다른 기기는 Cloud Default에 둡니다. 무해한 변경 사항을 업로드한 뒤 각 기기의 check-in 기록을 비교해 보세요. 이렇게 하면 테스트에서 추측을 없앨 수 있습니다.

Capgo의 live OTA 엔진은 웹 레이어 변경 사항을 위해 설계되었습니다. 스토어 심사를 기다릴 필요 없이 JavaScript 번들, CSS 또는 에셋 업데이트를 적용할 수 있습니다. 이 속도는 기기가 체크하는 정확한 채널에 릴리스가 활성화되어 있는지에 달려 있습니다.

방금 Cloud Default를 변경했다면 기기의 업데이트 타이밍을 고려해야 합니다. 새로 설치한 기기는 즉시 새 경로를 사용하지만, 기존 기기는 보통 다음 업데이트 체크를 수행할 때 전환됩니다. 앱을 종료 후 다시 열면 체크를 유도할 수 있지만, 고정된(pinned) 채널 설정을 무시할 수는 없습니다.

이제 앱 내부에서 결과를 확인하세요. 다음을 호출하세요.getChannel()updater가 시작된 후, 반환된 channel을 앱 버전 및 번들 버전과 함께 로그로 남기세요. 이는 대시보드만 확인하는 것보다 유용합니다. 기기가 실제로 인식하는 상태를 보여주기 때문입니다.

앱이 실행 시 또는 포그라운드에서만 체크한다면 지연이 발생할 수 있습니다. 업데이터를 시작하지 않는 화면을 열어 테스트하지 마세요. 짧은 테스트 빌드에서는 알려진 시작 경로에 체크를 넣어 확인한 뒤, 릴리스 전에 추가 로깅을 제거하세요.

반환된 채널이 맞는데 번들이 도착하지 않으면 호환성 및 롤아웃 규칙으로 넘어가세요. 반환된 채널이 잘못됐다면 1단계로 돌아가 Cloud Default보다 우선하는 할당을 해제하세요.

4단계: 강제로 새로 동기화하고 디바이스 측 로그 확인

목표는 오래된 로컬 상태와 서버 측 전달 문제를 구분하는 것입니다. 새 체크인은 새로운 증거를 제공합니다.

먼저 기기의 네트워크 연결을 확인하세요. 앱 세션이 정상이라고 해서 업데이터가 엔드포인트에 도달할 수 있다는 증거는 아닙니다. 기업 필터, VPN 규칙, 캡티브 포털 또는 만료된 세션이 업데이트 요청을 차단할 수 있습니다.

다음으로 앱을 포그라운드로 전환하고 업데이터 체크가 완료될 때까지 기다리세요. 앱에서 업데이트 상태 이벤트를 노출한다면 현재 채널과 함께 해당 이벤트를 로깅하세요. “update started”만 로깅하지 마세요. 앱이 번들을 찾았는지, 다운로드했는지, 검증했는지, 설치했는지, 거부했는지 알아야 합니다.

Capgo의 디바이스 로그를 사용하여 처음 실패한 단계를 찾으세요. 마지막 “update failed” 메시지보다 첫 번째 에러가 보통 더 유용합니다. 예를 들어, 채널 누락은 라우팅 문제를, 호환성 거부는 네이티브 런타임이나 버전 게이트 문제를, 다운로드 에러는 네트워크 액세스나 번들 요청 문제를 나타냅니다.

재설치는 유용한 테스트이지만 증거를 변경합니다. 재설치 시 로컬 channel 상태가 초기화될 수 있습니다. 현재 channel과 logs를 캡처한 후에 사용하세요.

반복 가능한 확인을 위해 다음 값을 한 줄의 log에 기록하세요:

• App ID 및 네이티브 앱 버전
• 에서 해석된 channelgetChannel()
• 마지막 updater 확인 시간
• 서버가 발견한 bundle 버전
• 설치 또는 거부 결과

이 작은 기록은 기기가 문제를 즉시 재현할 수 없는 테스터의 기기일 때 도움이 됩니다. 또한 CI 팀이 자동화된 스모크 테스트를 할 때 명확한 신호를 줍니다.

플러그인의 API 동작을 조사해야 한다면 공식 Capgo Capacitor Updater 소스 저장소를 사용하세요. 특히 로컬 채널 변경과 대시보드 기기 할당의 차이에 주의하세요.

유용한 팁: 채널을 지우기 전에 확정된 채널을 캡처하세요. 그렇지 않으면 상태를 고치는 과정에서 실패 원인을 설명해 주던 단서를 잃을 수 있습니다.

5단계: 롤아웃 규칙, 버전 게이트, 자동 롤백 검토

목표는 Capgo이 의도적으로 번들을 보류하거나 되돌렸는지 확인하는 것입니다. 업데이트가 없는 것은 때로 안전 규칙이 설계대로 동작한 결과일 수 있습니다.

채널 설정을 열고 릴리스에 연결된 모든 규칙을 검토하세요. 최소 앱 버전, 퍼센트 롤아웃 설정, 기기 필터, 릴리스와 연결된 조건을 확인하세요. 규칙을 벗어난 기기는 채널이 올바르더라도 현재 번들을 그대로 유지합니다.

버전 형식도 확인하세요. Capgo은 릴리스 비교에 semantic versioning을 사용합니다. 사람 눈에 맞아 보이는 버전 게이트라도 앱이나 번들이 예상치 못한 형식을 쓰면 다르게 동작할 수 있습니다. 네이티브 빌드와 OTA 릴리스 간에 형식을 일관되게 유지하세요.

그다음 롤백 동작을 검토하세요. 헬스 체크 실패 후 자동 롤백으로 디바이스가 이전 번들로 돌아갈 수 있습니다. 이 경우 대시보드에는 이전 활성 code가 표시되지만, 예상한 릴리스는 존재하되 사용할 수 없는 상태로 남을 수 있습니다.

이벤트를 검토하기 전에 의심스러운 번들을 삭제하지 마세요. 삭제하면 유용한 증거가 사라집니다. 먼저 번들 버전, 채널, 롤아웃 상태, 롤백 사유를 기록하세요. 그런 다음 릴리스를 일시 중지할지, 검증된 정상 버전을 게시할지 결정하세요.

위험한 변경에는 스테이지드 채널을 사용하세요. 먼저 번들을 소규모 테스트 그룹에 보내세요. 채택률과 오류 신호를 지켜보세요. 릴리스가 예상대로 동작하면 롤아웃을 진행하세요. 이렇게 하면 잘못된 웹 레이어 변경이 모든 활성 디바이스에 한 번에 도달하는 것을 막을 수 있습니다.

롤백은 OTA로 변경할 수 있는 code만 복구합니다. 누락된 네이티브 플러그인이나 호환되지 않는 네이티브 API 때문에 실패한 경우에는 스토어용 새 빌드가 필요합니다. 이전 JavaScript 번들을 보내도 앱에 없는 네이티브 부분이 추가되지는 않습니다.

규칙을 점검할 때는 세 가지를 확인하세요:

• 이 디바이스가 앱 버전 조건을 충족하나요?
• 디바이스가 롤아웃 그룹에 포함되어 있나요?
• 헬스 체크나 수동 조치로 이전 번들로 되돌아갔나요?

Capgo은 여기서 유용합니다. 같은 채널 모델로 스테이지드 릴리스, 롤백 지원, 업데이트 활동 표시를 하나의 워크플로우에서 처리할 수 있기 때문입니다. 규칙 세트는 작게 유지하세요. 짧은 정책이 장애 중에 쌓인 예외 규칙 더미보다 감사하기 쉽습니다.

API 기반 검사가 필요하다면, Capgo 공개 API 문서 디바이스, 채널, 번들에 대한 리소스를 설명합니다. 서버에서 보이는 정보와 앱이 보고하는 내용을 비교할 때 사용하세요. 이 비교를 통해 오래된 대시보드 필터나 자동화로 생성된 디바이스 할당을 찾아낼 수 있습니다.

롤백은 안전장치일 뿐, 테스트를 대신할 수는 없습니다. 모든 프로덕션 채널에는 검증된 번들을 항상 하나 이상 유지하세요.

6단계: 실시간 분석으로 정확한 실패 지점 찾기

목표는 '업데이트 안 됨'을 하나의 실패로 취급하지 않는 것입니다. 분석을 통해 디바이스가 체크인하지 않았는지, 적합한 번들을 찾지 못했는지, 다운로드 중 실패했는지, 아니면 나중에 롤백되었는지 확인할 수 있습니다.

문제가 발생한 디바이스 그룹부터 시작하세요. 앱 버전, 플랫폼, 채널, 번들 버전으로 필터링하며 패턴을 찾으세요. 구버전 앱 빌드에서만 실패한다면 네이티브 호환성 게이트 문제일 수 있고, 한 채널의 모든 디바이스가 실패한다면 채널이나 배포를 점검하세요.

시간 경과에 따른 채택률을 비교하세요. 출시 후 그래프가 평탄하다면 라우팅이나 대상 자격 문제일 가능성이 큽니다. 상승 후 하락한다면 설치 오류나 롤백을 의미하고, 완만한 상승은 디바이스에서 아직 앱을 열지 않았을 뿐일 수 있습니다.

타임스탬프는 주의해서 보세요. 대시보드의 이벤트 시간은 사용자의 로컬 시간과 다를 수 있습니다. 업데이트 이벤트를 디바이스의 마지막 체크인과 맞춰 보세요. 테스터가 앱이 실제로 체크인하기도 전에 업데이트가 실패했다고 말할 때 도움이 됩니다.

Analytics는 채널 변경을 안전하게 테스트하는 데도 도움이 됩니다. 한 번에 변수 하나만 바꾸세요. 라우팅을 테스트할 때는 bundle을 고정하고, 새 bundle을 테스트할 때는 라우팅을 고정하세요. 둘 다 바꾸면 데이터만으로는 어떤 변경이 문제를 해결했는지 알 수 없습니다.

장애 발생 시, 다음과 같은 최소한의 증거 데이터를 저장하세요:

• 디바이스 식별자 또는 내부 테스트 라벨
• 적용된 채널
• 네이티브 앱 버전
• 예상 bundle과 설치된 bundle
• 마지막 check-in 시간
• Rollback 또는 rejection 이벤트

배포 프로세스가 CI/CD를 통해 업데이트를 전송한다면 Capgo의 실시간 뷰가 가장 유용합니다. 배포 작업에서 bundle을 업로드하고, 모니터링 단계에서 테스트 디바이스가 의도한 채널과 bundle을 보고하는지 확인할 수 있습니다. 이렇게 하면 수동으로 처리하던 불만을 릴리스 게이트로 바꿀 수 있습니다.

Analytics 데이터를 릴리스 기록과 연결해 두세요. 배포 노트에 commit 또는 build 참조를 기록하세요. 두 bundle의 버전 라벨이 비슷할 때 build 참조를 보면 어떤 code이 실제로 적용됐는지 알 수 있습니다.

Cloud Default 변경 후 기존 디바이스에서만 문제가 발생한다면, 다른 설정을 변경하기 전에 해당 디바이스의 다음 check-in을 기다리세요. 신규 설치는 유용한 대조군이 됩니다. 신규 설치를 통해 이전 로컬 상태가 없는 디바이스에서도 기본 라우팅이 정상 작동하는지 확인할 수 있습니다.

7단계: Default Channel이 오래된 상태로 남지 않도록 방지

목표는 채널 드리프트가 사용자에게 영향을 주기 전에 드러나게 하는 것입니다. 간단한 릴리스 체크리스트만으로도 대부분의 반복 사례를 막을 수 있습니다.

각 앱 환경마다 라우팅 모델 하나를 선택하세요. 프로덕션에서는defaultChannel생략하고 Capgo Cloud가 기본값을 제어하게 하세요. 테스트 빌드에서는 명시적인 채널을 설정할 수 있습니다. 위험한 구성은 오래된 로컬 오버라이드, 오래된 네이티브 설정, 아무도 검증하지 않는 새 Cloud Default가 뒤섞인 상태입니다.

넣기npx cap sync추가하세요. 동기화 단계가 실패하면 빌드도 실패하도록 하세요. 명령어는 간단하지만, 건너뛰면 어제의 채널이 오늘의 네이티브 바이너리에 그대로 들어갈 수 있습니다.

배포 후 스모크 테스트를 추가하세요. 테스트 기기에서 앱을 실행하고, 호출한 다음getChannel()예상 번들이 있는지 확인하고 결과를 기록해야 합니다. OTA 워크플로우에서 검증 단계가 빠지는 경우가 많습니다. upload만으로는 거의 아무것도 입증되지 않습니다.

로컬 채널 code은 명확한 피처 플래그 뒤에 두세요. 테스트 헬퍼가 호출하더라도setChannel()프로덕션 빌드에 실수로 포함되지 않도록 하세요. 로컬 캐시는 대시보드 오버라이드로 표시되지 않을 수 있으므로, UI만으로는 모든 문제를 잡아낼 수 없다는 점을 기억하세요.

다음과 같은 릴리스 체크리스트를 사용하세요:

1. 앱 ID와 네이티브 버전을 확인합니다.
2. 대상 채널을 선택합니다.
3. 해당 채널에 번들을 업로드하세요.
4. 번들이 활성화되었는지 확인하세요.
5. 디바이스 스모크 테스트를 실행하세요.
6. 반환된 채널을 다음으로 확인하세요getChannel().
7. 롤아웃 범위를 넓히기 전 채택률을 모니터링하세요.

프로덕션 릴리스에는 롤백 보호를 켜 두세요. 명확한 채널이나 롤백 계획 없이 배포하는 것은 흔한 실패 패턴입니다. 이렇게 하면 잘못된 번들을 중단할 수 있는 안전한 방법이 줄어듭니다.

Capgo는 조직당 구독제를 사용하며 14일 무료 체험을 제공합니다. 무료 체험은 대시보드를 확인하는 데 그치지 말고, 실제 앱 빌드에서 릴리스 플로우를 테스트하는 기회로 활용하세요. 단계적 배포, 롤백 테스트, 자동 채널 점검을 각각 한 번씩 해보세요.

보안도 같은 체크리스트에 포함해야 합니다. CI/CD 토큰을 보호하고, Cloud Default를 변경할 수 있는 사람을 제한하세요. 프로덕션 배포 자격 증명은 로컬 스크립트에 두지 마세요. 승인되지 않은 채널 변경은 감사 로그를 확인하기 전까지 기기가 오래된 것처럼 보일 수 있습니다.

자주 배포하는 팀이라면 프로세스를 단순하게 유지하세요. 배포는 명령어 하나로. 테스트 기기는 지정된 기기 하나로. 채널 규칙은 하나로 명확하게. 추적, 적용, 롤백.

핵심 요약: 설정을 동기화하고, 숨겨진 로컬 오버라이드를 피하고, 최종 결정된 채널을 테스트하고, 롤백을 준비해 오래된 라우팅을 방지하세요.

자주 묻는 질문

Capgo 클라우드 기본 채널이 기존 기기를 업데이트하지 않는 이유는 무엇인가요?

기존 기기는 다음 업데이트 확인 전까지 이전 채널을 유지할 수 있습니다. 로컬 채널, 대시보드 오버라이드 또는 강제 할당이 Cloud Default보다 우선할 수도 있습니다. 기기에 최종 적용된 채널을 확인하려면getChannel()를 실행한 뒤 더 강한 할당을 해제하고 앱을 포그라운드로 전환하세요.

Capgo Cloud Default를 변경하면 설치된 모든 앱이 변경되나요?

아니요, Cloud Default를 변경해도 설치된 모든 앱의 채널이 즉시 다시 쓰이지는 않습니다. 새 기기는 새 기본값을 바로 사용할 수 있습니다. 기존 설치본은 전환하려면 먼저 체크인해야 하며, 더 강한 채널 규칙이나 로컬 오버라이드가 적용되면 여전히 전환되지 않습니다.

Capgo 채널 변경 시 npx cap sync는 무엇을 하나요?

npx cap sync업데이트된 Capacitor 구성을 네이티브 프로젝트에 복사합니다. 만약defaultChannel채널을 변경했지만 sync를 건너뛰면, 다음 네이티브 빌드에는 여전히 이전 채널 설정이 포함될 수 있습니다. 프로젝트 루트에서 명령을 실행한 뒤 새 테스트 바이너리를 빌드하고 설치하세요.

setChannel이 Capgo에서 기기 오버라이드를 생성하나요?

아니요,setChannel()setChannel은 앱이 로컬에 저장하는 채널을 변경합니다. 백엔드 기기 오버라이드를 생성하지 않으므로 Capgo 대시보드에 기기가 오버라이드된 것으로 표시되지 않을 수 있습니다. 기기가 기본 라우팅으로 돌아가야 할 때 로컬 할당을 해제한 뒤, 결과를 확인하려면getChannel().

Capgo은 OTA 번들을 통해 네이티브 code을 업데이트할 수 있나요?

아니요, Capgo OTA 업데이트는 JavaScript, CSS, 에셋 같은 웹 레이어 code에만 적용됩니다. 네이티브 플러그인, 권한 또는 네이티브 API 변경에는 스토어용 새 빌드가 필요합니다. 번들이 요구하는 네이티브 code가 설치된 앱에 없다면, 채널이 올바르더라도 업데이트가 거부될 수 있습니다.

마치며

대시보드 기본값이 아닌, 실제 적용된 채널부터 확인하세요. 할당을 점검하고 실행한 다음,npx cap sync네이티브 런타임과 번들을 대조하고, 배포 규칙을 변경하기 전에 디바이스 로그를 확인하세요. 그런 다음 Capgo에 간단한 배포 후 테스트를 추가해 호출한 뒤getChannel()예상한 번들을 확인하도록 하세요.