Ionic Live Update Services: 2026 Guide

아이오닉 live update 서비스를 선택하는 것은 실제로 릴리스 디자인 작업입니다. OTA 업데이트는 웹层 버그를 수정할 수 있지만 새로운 스토어 빌드를 필요로 하지 않습니다. 그러나 native 릴리스를 대체할 수는 없습니다. 나는 아래의 워크플로를 사용하여 업데이트 경계를 정의하고 서비스를 비교하고 Capgo을 설정하고 안전한 롤아웃 규칙을 추가합니다.

목차

• 4단계: Capgo을 설정하여 안전하고 차등적인 아이오닉 업데이트를 위한
• 1단계: 아이오닉 앱의 live update 요구 사항을 정의하기
• 2단계: 호환성, 업데이트 범위 및 native-code 한계를 확인하기
• 3단계: 가장 강력한 아이오닉 live update 서비스를 비교하기
• 5단계: CI/CD PIPELINE에 채널 기반 롤아웃을 빌드하기
• 6단계: 릴리스를 모니터링하고 자동 롤백을 구성하기
• FAQ
• 결론

4단계: Capgo을 설정하여 안전하고 차등적인 아이오닉 업데이트를 위한

Capgo Ionic 팀에게 암호화 OTA 업데이트를 위한 집중된 경로를 제공합니다. 목표는 웹-layer 배달을 위한 작은 패키지를 하나의 명령으로 보내고, 릴리스가 잘못되면 명확한 방법으로 돌아가기 위한 것입니다.

시작하기 위해 Capgo Capgo 가격은 조직당 구독이며, 단일 판매 또는 사용자당 요금이 아닙니다. 가격은 12달러로 시작하며, 현재 가격 정보를 확인하기 전에 예산을 설정하기 전에 계획 세부 정보를 확인하세요.

Next, install the Capgo CLI in the project. Keep the CLI version in your project setup so a future build uses the same release tool. Then connect the app to its Capgo project and choose a channel such asdevelopment또는production.

채널은 패키지의 이름입니다. 내부 장치에 테스트 빌드를 보내기 전에 프로덕션 사용자가 볼 수 있도록 합니다. 릴리스 프로세스와 채널 이름을 연결하세요. 이름이 모호한 경우latest6개월 후에 사고 검토가 어려워집니다.

웹层를 빌드하기 전에 릴리스하세요. 생성된 HTML, CSS, JavaScript, 및 자산 파일을 검토하세요. 테스트 키 및 디버그 플래그를 제거하세요. 올바른 API 환경을 참조하는지 확인하세요. live update가 빨리 도착할 수 있으므로 잘못된 환경 값을 사용하면 빠르게 퍼질 수 있습니다.

Capgo는 유지보수되는 CodePush-style 워크플로우를 사용하여 끝-to-end 암호화합니다. 차등 업데이트의 접근 방식은 변경된 파일이 패키지의 일부인 경우 데이터를 줄일 수 있습니다. 정확한 결과는 패키지와 변경된 파일에 따라 달라집니다. 결과를 가능한 결과로 간주하고 모든 릴리스에 대한 약속으로 간주하지 마세요.

게시하기 전에, __CAPGO_KEEP_0__ 버전을 정의하세요. 웹 버블은 호환성 범위를 선언해야 합니다. 만약 버블이 더 오래된 바이너리가 없는 네이티브 플러그인을 호출한다면 업데이트를 차단하세요. 이건 OTA 시스템에서 가장 중요한 안전 체크 중 하나입니다.

CLI를 사용하여 테스트 채널에 버블을 업로드하세요. 기기에 맞는 네이티브 앱을 설치하세요. 앱을 열고 업데이트를 pull하세요. 앱을 닫고 다시 열어보세요. 차가운 시작, 느린 네트워크 연결, 캐시된 더 오래된 버블이 있는 기기를 테스트하세요.

Capgo는 롤백과 채널을 지원하며, 채널 기반 롤아웃 제어의 부분 지원을 제공합니다. 따라서 릴리즈 계획에서 버블을 채널 간에 이동하는 사람을 명시하세요. 마지막 순간에 한 사람의 수동 클릭으로 승격하지 마세요.

팀이 업데이트 시스템에 대한 더 넓은 시각이 필요하다면, 모바일 앱의 live updates 시스템 비교

secure differential Ionic __CAPGO_KEEP_0__ 배포 워크플로 Key Takeaway:

게시하기 전에, live update가 설치된 네이티브 바이너스와 일치하는 웹 레이어 변경 사항만 게시하세요. 그리고 테스트 채널을 통해 버블을 테스트하세요.

Step 1: live update의 Ionic 앱에 대한 요구 사항을 정의하세요. (context: About Capgo page. Role: UI label. Seen in: page about.astro. Message key `about_how_step_label` (About How Step Label). )

앱 스택에서 시작하세요. Ionic 버전, Capacitor 버전, iOS 및 Android 네이티브 타겟, 사용 중인 네이티브 플러그인, OTA 번들을 수용할 수 있는 최소 설치된 앱 버전을 기록하세요. 릴리스 PIPELINE과 함께 이 기록을 유지하세요.

계획된 변경 사항을 두 그룹으로 분류하세요.

• 웹层 변경 사항: HTML, CSS, JavaScript, 이미지 및 앱이 로드할 수 있는 다른 자산.
• 네이티브 변경 사항: 권한, 특권, 네이티브 SDK 업데이트, 새로운 네이티브 플러그인 및 네이티브 구성 변경 사항.

첫 번째 그룹은 앱 정책 및 스토어 규칙이 허용할 때만 OTA를 통해 전송하세요. 두 번째 그룹은 일반 iOS 또는 Android 빌드로 전송하세요. 새로운 카메라 권한은 네이티브 변경 사항입니다. 화면 레이블에 있는 잘못된 글자는 일반적으로 웹 레이어 변경 사항입니다.

다음으로, 각 릴리스에 필요한 사람과 기기를 목록하세요. 내부 테스트 채널, 고객 피로트 채널, 프로덕션 채널이 필요할 수 있습니다. 네이티브 버전에 따라 별도의 채널이 필요할 수도 있습니다. 지원하는 버전의 수가 많을수록 매핑이 중요해집니다.

평범한 언어로 릴리스 규칙을 작성하세요. 예를 들어, “내부 테스트에서 번들을 1일 동안 유지한 후, smoke 테스트가 통과하면 릴리스 매니저가 피로트로 이동시킵니다. 프로덕션 승격은 2차 리뷰어가 필요합니다.”와 같은 규칙을 작성하세요. 이러한 규칙은 “안전하게 릴리스하세요.”와 같은 모호한 목표보다 유용합니다.

배포하기 전에 실패 신호를 설정하세요. rollout을 중단할 이벤트를 선택하세요. 이 이벤트는 실패한 시작이 증가한 경우, 새로운 배포와 관련된 충돌, 로그인 경로가 깨진 경우, 앱이 빈 화면을 보여주는 경우 등이 될 수 있습니다.

이 시장에서 분석 커버리지가 균일하지 않습니다. 여기서 비교한 서비스 중에서 3개만 분석을 언급합니다. Capgo은 장치 로그를 목록화하고, OtaKit은 분석과 함께, Microsoft CodePush는 분석과 제한된 기간 동안 진단을 목록화합니다. 서비스가 필요로하는 신호를 노출하지 않는다면 외부 모니터링 경로를 계획하세요.

또한, 나쁜 업데이트가 장치에서 빠져나가야 하는 속도를 결정하세요. 무해한 복사 수정은 수동 검토를 기다릴 수 있습니다. 그러나 깨진 체크아웃 화면은 자동 롤백이 필요할 수 있습니다. 팀이 테스트할 시간이 없도록 롤백 규칙을 선택하지 마세요.

Capgo은 유지보수 코드 푸시 스타일의 경로와 암호화, 채널, 롤백, CI/CD 훅을 지원하는 팀을 위해 설계되었습니다. 또한 GitHub Actions, Jenkins, GitLab CI도 지원합니다. 그러나, 높은 위험의 프로덕션 앱을 이동하기 전에 전체 경로를 작은 앱에서 테스트하는 것이 좋습니다.

이 테스트는 네 가지 질문을 해결해야 합니다:

• 개발자는 CI에서 배포할 수 있는지?
• 리뷰어는 어떤 네이티브 버전이 받을 수 있는지 볼 수 있나요?
• 팀은 rollout을 중단하거나 역전할 수 있나요?
• 지원 팀은 영향을 받은 장치에서 배포를 식별할 수 있나요?

어떤 질문도 명확하지 않다면, 요구사항이 완료되지 않았습니다. 프로세스를 수정하세요. 그리고 비교할 수 있는 플랜 페이지를 만들기 전에.

Step 2: 호환성, 업데이트 범위, 네이티브 code 제한을 확인하세요.

Ionic live update 서비스는 자바스크립트를 통해 네이티브 변경을 만들 수 없습니다. 이 단계는 OTA 작업과 스토어 릴리스 사이의 경계를 그립니다.

code 서비스를 시작하려면 호환성 매트릭스를 만드세요. 네이티브 앱 버전을 첫 번째 열에, 채널을 위쪽에 넣으세요. 각 칸에, 해당 바이너리에서 안전한 웹 번들의 버전을 표시하세요. 이 단계는 기본적인 것처럼 보이지만, 이전 앱이 새로운 네이티브 브리지를 기대하는 code를 받지 않도록 방지합니다.

각 계획된 업데이트에 대해 code 함수를 호출하는지 물어보세요. 새로운 플러그인 Capacitor을 추가하는 변경은 설치된 바이너리 내에 플러그인을 포함해야 합니다. 페이지 템플릿만 수정하는 변경은 현재 셸을 사용할 수 있습니다. 불확실한 경우 네이티브 빌드를 먼저 배포하세요.

앱 스토어 규칙을 검토하세요. OTA 배포는 웹层에만 해당되며, 앱의 주요 목적을 변경하거나 필수 검토를 피하기 위한 숨겨진 경로가 될 수 없습니다. 법률 및 릴리스 팀이 정책을 관리해야 합니다.

첫 번째 드라이 러닝을 위해 작은 테스트 변경을 사용하세요. 하나의 가시적인 레이블을 변경하거나 무해한 디버그 마커를 추가하세요. 개발 채널에 배포한 후, 동일한 네이티브 빌드에서 앱을 설치한 후, 업데이트를 양쪽 플랫폼에서 검증하세요.

live update 서비스의 채널 제어를 사용하여 어떤 바이너리 릴리스가 업데이트를 받을지 결정하고, 배경화면 후에 앱이 업데이트를 적용할 때 정의하세요.

그 시간이 중요합니다. 사용자는 OTA 패키지를 즉시 볼 수 없습니다. 앱은 다음 런치, 배경 기간, 또는 다른 싱크 메서드가 실행될 때까지 기다릴 수 있습니다. 이 규칙을 문서화하여 지원 팀이 앱이 지연 전략을 사용할 때 즉시 동작을 약속하지 않도록 합니다.

앱 내에 기본값을 유지하세요. 업데이트가 다운로드되지 못하면 현재 패키지가 로드되어야 합니다. 새로운 패키지가 검증을 실패하면 앱은 알려진 좋은 버전을 유지해야 합니다. 테스트를 위해 장치가 오프라인일 때 기본값을 테스트하세요. 빠른 Wi-Fi 네트워크에서만 작동하는 롤백 계획은 아직 롤백 계획이 아닙니다.

배포 전에 패키지 크기를 확인하세요. 차등 업데이트는 웹层의 작은 부분만 변경되었을 때 유용하지만 큰 자산 교체는 여전히 큰 다운로드를 생성할 수 있습니다. 적합한 경우 자산을 압축하세요. 사용하지 않는 파일을 배포하지 마세요. 프로덕션 패키지에 맵과 테스트 파일을 포함하지 마세요. 필요하지 않다면.

보안 검사도 여기서 수행됩니다. 서비스가 패키지를 서명하거나 암호화하는 방법을 확인하세요. 키가 어디에 있는지 확인하세요. 프로덕션으로 배포할 수 있는 사람을 제한하세요. Capgo의 종단-to-종단 암호화 및 CodePush-style 흐름은 팀이 OTA 경로에 대한 제어를 원하는 경우 유용한 매칭이지만 키 정책이 여전히 중요합니다.

호환성 테스트를 사용하여 다음 경우를 거부하세요:

• 패키지가 바이너리에서 누락된 네이티브 메서드를 호출합니다.
• 패키지가 앱이 읽을 수 없는 데이터 형식을 기대합니다.
• 패키지가 권한 또는 특권을 변경합니다.
• 다운로드가 중간에 중단되면 앱이 복구할 수 없습니다.

이러한 사례는 원시 릴리스 또는 스테이지드 마이그레이션에 속합니다. OTA에 강제로 넣지 마십시오. 스토어 큐가 느리다고 느껴질 수 있기 때문입니다.

프로 팁: 테스트 장치에 하나의 이전 프로덕션 바이너리를 유지하세요. 모든 새로운 웹 번들을 더 넓은 롤아웃 전에 테스트 장치에서 통과시켜야 합니다.

Step 3: Ionic live update 서비스를 비교하세요

Ionic live update 서비스를 비교할 때, 릴리스 경로를 기능 수보다 판단하세요. 암호화, 번들 호환성, 채널 제어, 롤백, CI/CD 접근, 분석, 서비스의 장기적인 상태를 확인하세요.

Capgo은 Capacitor 앱이 암호화된 OTA 전송을 위해 큰 연간 플랫폼 비용 없이 테스트하는 첫 번째 서비스입니다. 제공된 플랜 데이터는 조직당 월 $12부터 시작됩니다. 또한 GitHub 액션, 젠킨스 및 지틀랩 CI와 연결되어 팀이 이미 사용하는 pipe라인 내에서 계속해서 배포할 수 있도록 도와줍니다.

OtaKit 및 Capawesome Cloud는 단계적 또는 점진적인 롤아웃이 주된 필요성인 경우 직접 기술적인 검토가 필요합니다. 연구는 이러한 제어를 두 서비스 모두에 대해 명시적으로 언급합니다. 그러나 이러한 서비스를 테스트하는 필요성은 제거되지 않습니다. native 버전 확인 또는 롤백 동작을 앱에서 테스트해야 합니다.

Ionic Appflow는 다른 형태를 가지고 있습니다. 실시간 업데이트 기능을 보다 광범위한 유료 플랫폼에 통합하여 네이티브 빌드 및 CI/CD 기능을 제공합니다. 이는 한 벤더가 릴리스 시스템의 대부분을 소유하고 있을 때 의미가 있을 수 있습니다. 그러나 서비스의 가용성 또는 장기적인 서비스 상태가 불확실한 경우 새로운 평가에 적합하지 않습니다.

독립된 CodePush는 특별한 경우입니다. 원래 프로토콜을 유지하지만 아카이브된 저장소는 보안 업무를 팀에 전환합니다. 패치, 호스팅, 접근 제어 및 인시던트 대응과 같은 책임을 소유해야 합니다. 익숙한 프로토콜은 이러한 책임을 제거하지 않습니다.

가격 비교는 또한 어려울 수 있습니다. 제공된 설문조사에 따르면 57%의 서비스가 가격을 공개했습니다. 그 중에서 중간값은 월 14달러였으며, 범위는 앱플로우의 연간 5,000달러의 청구까지 뻗어났습니다. 가격만으로는 패키지 제어 또는 운영 위험에 대한 정보를 얻을 수 없습니다.

이동 경로에 대한 더 넓은 시야를 원한다면 Capacitor 및 이온의 CodePush 대체품에 대한 정보는 CodePush 대체품 페이지에서 확인할 수 있습니다. 5단계: CI/CD PIPELINE에 채널 기반 롤아웃을 빌드합니다.

5단계: CI/CD pipeline에 채널 기반 롤아웃을 빌드하십시오

A good Ionic live update service should fit the same CI/CD path as your app. The aim is simple: build once, verify the bundle, publish to a channel, then promote it with a recorded action.

빌드:

1. Build: 체크:
2. Check: 배포:
3. Publish: 개발 또는 미리보기 채널에 번들을 업로드하세요.
4. Promote: 동일한 승인된 번들을 피로트 또는 프로덕션으로 옮겨주세요.

프로덕션 작업이 code을 다시 빌드하지 않도록 하세요. 두 번째 빌드는 변경된 의존성이나 다른 환경 변수를_pull할 수 있습니다. 테스트된 아티팩트를 옮겨주세요. 이로써, 리뷰 중인 번들이 사용자들이 받는 번들과 동일한 상태가 유지됩니다.

CI secret store에 Capgo API 토큰을 저장하세요. 작업을 지원하는 가장 좁은 접근 권한을 부여하세요. 번들을 앱에 포함시키거나 저장소에 커밋하지 마세요. 팀원이나 빌드 시스템이 변경될 때 토큰을 회전하세요.

Capgo은 CI/CD 훅을 GitHub Actions, Jenkins, GitLab CI와 지원합니다. 이로써, 단일 명령어로 배포할 수 있는 여러 경로가 제공됩니다. 명령어는 번들이 호환되지 않는 네이티브 버전을 대상으로하거나 필요한 채널이 누락된 경우 실패해야 합니다.

채널 승인을 명시적으로 요구하세요. pull request는 code 리뷰를, 릴리스 승인은 프로덕션 승인을 담당할 수 있습니다. 두 가지 기록을 유지하세요. 나중에, 지원 팀은 승인한 번들과 대상 네이티브 버전을 확인할 수 있습니다.

다양한 위험 수준에 맞는 별도의 채널을 사용하세요. 일반적인 설정은 다음과 같습니다:

• dev개발 중인 기능을 위한 채널
• pilot내부 또는 초청된 사용자만을 위한 작은 그룹 채널
• production공개 앱을 위한 채널

여러 네이티브 버전을 가진 앱의 경우 버전별 채널을 추가하거나 엄격한 호환성 범위를 강제하세요. 오래된 바이너리가 활성화된 기간에 따라 올바른 선택을 하세요. 호환되지 않는 릴리스 규칙을 한 채널에 부여하지 마세요.

서비스를 중단하고 다시 시작하기 전에, 프로모션 단계 사이에 일시 정지를 추가하세요. 짧은 관찰 기간도 깨진 자산 경로나 API 불일치로 인해 모든 장치에 배포되기 전에 문제를 잡아낼 수 있습니다. 서비스가 점진적인 롤아웃을 지원하는 경우 사용하세요. 그렇지 않다면, 피로트 채널을 안전 게이트로 사용하세요.

pipeline 출력이 유용하게 유지되도록 하세요. 배포 버전, 커밋 해시, 대상 채널, 네이티브 호환성 범위, 승인 링크를 출력하세요. '배포 성공'만 출력하는 로그는 사고 시에 도움이 되지 않습니다.

마지막으로, 실패한 릴리스를 연습하세요. 무해한 테스트 배포를 발행하세요. 실패로 표시하세요. pipeline가 프로모션을 중단하고 롤백 액션으로 이전 배포를 복원하는지 확인하세요. 하나의 명령어로 배포하세요. 하나의 명확한 액션으로 중단하세요.

OTA 업데이트에 대한 더 자세한 정보를 원하는 팀은 또한 이 문서를 참조하세요. Capacitor OTA 업데이트에 대한 선택지 안내서 릴리스를 모니터링하고 자동 롤백을 구성하는 단계 6

Step 6: 릴리스 모니터링 및 자동 롤백 구성

모니터링을 통해 이온IC live update 서비스를 운영 프로세스로 변환하세요. 장치가 어느 버전의 배포를 가지고 있는지, 앱이 배포를 수용했는지, 변경 후에 무슨 일이 일어났는지 알아야 합니다.

배포 채택부터 시작하세요. 각 배포 버전의 활성 장치의 공유 비율을 추적하세요. 배포 채택 속도가 느리다면, 배경 동기화 타이밍, poor 연결성, 호환성 규칙이 많은 장치를 제외하는지 확인하세요.

업데이트 실패를 추적하세요. 다운로드 실패와 설치 실패를 분리하세요. 다운로드 문제는 네트워크 또는 CDN 문제일 수 있습니다. 설치 문제는 손상된 패키지, 유효하지 않은 서명 또는 앱 시작 오류에 대한 지시를 제공할 수 있습니다.

업데이트 후 첫 번째 화면을 관찰하세요. 빈 화면은 사용자가 이벤트 추적을 시작하기 전에 중단할 수 있습니다. 시작 이벤트에 패키지 버전, 네이티브 앱 버전 및 채널을 포함하세요. 이러한 로그에 개인 사용자 데이터를 보내지 마세요.

Capgo은 장치 로그 분석을 포함합니다. 로그를 사용하여 보고서를 패키지와 연결하세요. 앱이 별도의 충돌 도구를 가지고 있다면, 릴리스 ID 대신 인간 읽을 수 있는 이름에 의존하지 말고 레코드를 연결하세요.

제품 환경에서 롤백 규칙을 설정하세요. 예를 들어, 시작 오류율이 팀이 동의한 기준을 넘어섰을 때 프로모션을 중단할 수 있습니다. 기준 자체는 다른 제품에서 복사한 숫자가 아닌 앱의 일반적인 기준에서 가져와야 합니다.

자동 롤백에는 안전한 목표가 필요합니다. 마지막으로 알려진 좋은 패키지를 유지하고 Approve로 표시하세요. 롤백 패키지는 영향을 받는 채널에 있는 모든 네이티브 버전을 지원해야 합니다.

롤백을 테스트할 때 세 가지 상태를 고려하세요:

• 다운로드만 받은 장치
• 다운로드 및 설치한 나쁜 패키지를 재시작한 장치
• 네트워크를 잃은 장치

각 경우 앱이 사용 가능해야 합니다. 그렇지 않다면 네이티브 셸이 더 강력한 복구 경로를 필요로 합니다.

Capgo를 사용하여 폭파 크기를 제한하세요. 내부 장치부터 시작하여 pilot 그룹으로 이동하세요. 릴리스를 관찰하고 나서 승격하세요. 이곳에서 Capgo의 채널과 롤백 워크플로가 잘못된 웹 레이어 변경에 노출된 사용자 수를 줄일 수 있습니다.

고위험 릴리스에 대해 인간이 루프에 있도록 유지하세요. 자동 롤백은 유용하지만 낮은 이벤트 수는 문제를 숨길 수 있습니다. 작은 그룹에 영향을 미치는 체크아웃 문제는 글로벌 기준을 넘지 않을 수 있습니다. 지표와 지원 보고서 및 제품 검사를 combination하세요.

사고 후에 모든 롤백을 검토하세요. 실패한 번들, 네이티브 버전, 채널, 트리거, 그리고 복구 시간을 기록하세요. 그런 다음 문제를 일찍 잡을 수 있는 테스트를 추가하세요. 다음 릴리스는 더 평온한 릴리스가 아닌, 더 예쁜 사고 보고서가 아닌 것입니다.

주요 takeaway: 장치가 실행하는 번들을 추적하고, 승격 후 시작 건강을 관찰하고, 테스트된 알려진 좋은 번들을 준비하세요.

FAQ

What is an Ionic live update service?

An Ionic live update service delivers approved web-layer changes to an installed app without a new store submission. It can update HTML, CSS, JavaScript, and assets. It can’t safely replace native code, permissions, or native plugins. The right service also needs compatibility checks, channel control, security, and a way to reverse a bad bundle.

애플 스토어 없이 아이오닉 앱이 업데이트 할 수 있나요?

Ionic 앱은 새로운 App Store 또는 Google Play 릴리스 없이 웹-layer 업데이트를 받을 수 있습니다. 네이티브 변경은 일반 앱 빌드 및 스토어 프로세스가 필요합니다. OTA 변경은 릴리스 정책 내에서 유지하고 설치된 네이티브 셸에 테스트하여 플랫폼 검토가 필요한 변경 사항을 숨기지 말아야 합니다.

Capgo은 Capacitor과 호환되나요?

Capgo은 Ionic 및 Capacitor 앱에 OTA 전달을 위한 빌드된 것입니다. CodePush 모델을 따르는 워크플로우는 채널, 롤백, 종단-to-종단 암호화, 차등 배포, CI/CD 연결을 지원합니다. 네이티브 호환성 범위는 스테이징 채널에서 테스트한 후 프로덕션 사용자에게 배달할 때 배포를 확인하세요.

Ionic live update 서비스의 가격은 얼마인가요?

가격은 서비스 간에 매우 다양합니다. Capgo 가격은 단체당 월 $12의 구독으로 시작하며 14일 무료试用이 있습니다. Appflow의 $5,000의 연간 비용은 이러한 서비스 중 가장 높은 가격입니다. 전체 릴리스 워크플로우를 비교하십시오.

OTA 업데이트는 네이티브 code을 변경할 수 있나요?

아니요, OTA 업데이트는 네이티브 code을 변경해서는 안 됩니다. 설치된 네이티브 셸이 이미 실행할 수 있는 웹-layer에 해당합니다. 새로운 플러그인, 권한, 특권, 네이티브 SDK 변경은 스토어 빌드를 필요로 합니다. 호환되지 않은 배포는 시작 전에 거부되도록 네이티브 버전 체크를 추가하세요.

결론

Capgo의 Capacitor 또는 Ionic 팀이 암호화된 OTA 전송에 대한 채널 제어 및 롤백이 필요하다면, 나는 Capgo을 테스트하기 위해 스테이징 앱을 시작할 것이다. 개발 채널을 만들고, 작은 번들을 하나만 내보내고, 롤백 연습을 하기 전에 프로덕션을 시작한다. Appflow 대체 정보를 참조하고, 워크플로우가 릴리스 요구 사항과 일치한다면 14일 무료试用 시작.