주말에 핫픽스를 배포했다. 월요일에, 지원팀은 여전히 사용자로부터 핫픽스를 받지 못한 사용자들의 신고를 받고 있고, 베타 테스터들은 오래된 버전으로 고착되어 있고, 한 기업 고객은 정확히 자신의 팀원이 실행 중인 버전을 알고 싶어한다. 그 순간, 앱 업데이트 알림 __CAPGO_KEEP_0__은 모달이 아닙니다. 릴리스 관리를 위한 운영 체제입니다.
Capacitor 및 Electron 프로젝트에서 hardest 부분은 업데이트가 존재하는지 감지하는 것이 아닙니다. 업데이트가 존재하는지 감지하는 것 외에 모든 것: 업데이트를 볼 사람, 업데이트를 볼 때, 업데이트를 무시할 때, 업데이트가 CI/CD를 통해 어떻게 이동하는지, 롤아웃 후에 수집하는 통계 정보가 무엇인지 등이 hardest 부분입니다. 업데이트를 표시하는 UI를 간단하게 생각하면 noisy한 알림, brittle한 릴리스 로직, 혼란스러운 사용자 경험을 얻습니다. 업데이트를 제품 라이프 사이클의 일부로 생각하면 safer한 롤아웃과 더 평온한 지원 큐를 얻습니다.
목차
- 앱 업데이트 전략이 중요합니다.
- Capgo을 사용하여 업데이트 감지를 implement하는 방법
- 효과적인 알림 패턴을 디자인합니다.
- 업데이트 흐름과 사용자 선택 자동화
- 채널과 테스트미터리와 함께 고급 롤아웃
- 일반적인 알림 문제 해결
앱 업데이트 전략이 왜 중요합니까?
업데이트는 유지보수에만 영향을 주지 않습니다. 사용자 참여도도 영향을 받습니다.
업데이트는 단순히 버그를 고치고 사용자에게 알리고 다음 단계로 넘어가기만 하면 된다고 생각하는 팀이 많습니다. 하지만 제품의 영향력을 놓치고 있습니다.
푸시 알림은 설치 후 앱으로 돌아오게 할 수 있는 앱 라이프 사이클 채널 중 거의 유일한 것입니다. 데이터는 Invesp의 모바일 푸시 알림 연구 푸시 알림이 앱 참여도를 88%까지향상시킬 수 있으며, 옵트인한 사용자는 약 2배 __CAPGO_KEEP_0__의 사용자 비율이 낮습니다. 업데이트 전략에서 중요합니다. 왜냐하면 모든陈舊한 클라이언트는 업데이트한 기능, 수정, 또는 준수 변경을 절대 볼 수 있는 사용자입니다.
약한 업데이트 흐름은 동시에 세 가지 문제를 만듭니다.
- 제품 지연 새로운 기능이 불균형하게 출시되기 때문에 PM은 분석에서 혼동된 신호를 읽습니다.
- 지원 지연 agent가 스크린샷, 버전, 장치 정보를 요청하기 전에 문제를 재현할 수 없을 때 나타납니다.
- 보안 노출 기존 클라이언트가 이미 이동한 API와 계속 통신할 때 발생합니다.
실용적인 규칙 업데이트 전달을 릴리스 관리의 일부로 다루세요. 스프린트의 마지막에 친절한 메시지로 다루지 마세요.
스토어 업데이트와 라이브 업데이트는 서로 다른 문제를 해결합니다.
앱 스토어와 플레이 스토어 업데이트는 여전히 중요합니다. 네이티브 의존성 변경, 정책에 의한 릴리스, 권한 변경, 바이너리 수준 수정은 여기에 속합니다. 그러나 스토어에 의한 업데이트는 시스템의 한 층으로만 존재하고, 검토와 사용자 수용이 직접 제어할 수 없는 이유로 느립니다.
Capacitor와 Electron 앱의 경우, 라이브 업데이트는 다른 업무 범위에 해당하는 카테고리입니다. 그들은 JavaScript, CSS, 복사본, 자산 및 기능 플래그와 같은 웹 번들 변경에 적합합니다. 이들은 새로운 바이너리가 필요하지 않습니다. 실제로, 이는 두 개의 릴리스 질문을 분리하는 것을 의미합니다.
| 릴리스 질문 | 적합한 것 |
|---|---|
| 새로운 네이티브 바이너리가 필요한지 여부 | 스토어 릴리스 |
| 웹 번들이 안전하게 전달될 수 있는지 여부 | 라이브 업데이트 |
| 계속하기 전에 사용자에게 알릴 필요가 있는지 여부 | 인앱 알림 결정 |
| 현재 일부 사용자에게만 필요할지 여부 | 채널 기반 롤아웃 |
이 분리는 클라이언트 앱을 개발하는 대행사들이 단일 '업데이트가 준비되었습니다.' 팝업을 설계하는 것을 중단해야 하는 이유입니다. 전문 팀은柔한 지시, 무음 적용 경로, 롤백 규칙, 채널 대상 설정 및 후속 지원이 나중에 검사할 수 있는 로그가 필요합니다.
The trust angle matters too. 사용자는 업데이트가 거의 이루어지지 않는 중단으로 인한 불확실한 중단보다 업데이트를 더 싫어한다. 앱이MOOTH하게 업데이트를 완료하고 주요 변경 사항을 명확하게 설명하며 실제로 중단되거나 보안 위협이 될 경우에만 사용을 차단하면, 이는 전문성을 읽힌다.
Capgo를 사용하여 Implementing Update Detection
첫 번째 작업은 간단하다: 사용자가 실행 중인 버전을 알리고, 사용자가 속한 채널을 알리고, 업데이트가 필요한지 결정하는 것이다. 대부분의 DIY 업데이트 시스템은 이러한 결정이 섞여서 복잡해진다. 그들을 분리하라.
버전 인식으로 시작하라
신뢰할 수 있는 업데이트기는 런타임에 다음 세 가지 값을 사용할 수 있어야 한다.
- 설치된 앱 버전
- assign된 릴리스 채널
- 현재 업데이트 상태예를 들어, idle, checking, available, downloading, ready, failed와 같은 상태 모델
상태 모델을 생략하면 알림 버그가 빠르게 나타난다. 앱이 너무 자주 확인한다. 동일한 알림이 매번 실행될 때 나타난다. 배경 다운로드가 완료되었지만 UI는 여전히 “checking”이라고 나타난다.
관리 서비스는 일반적으로 이러한 이유로 올바른 선택이다: code Snippet가 제안하는 것보다 운영 작업이 더 무거운다. signed bundles, channel rules, rollback support, version history, device-level logs, delivery infrastructure가 필요하다. Capgo Capacitor과 Electron 앱을 위한 업데이터 플러그인과 호스팅된 배포 워크플로우를 제공하기 때문에 대부분의 클라이언트 팀은 내부적으로 스택을 재구축하는 것보다 사용하는 것이 더 좋습니다.
업데이터를 앱 시작 시에 연결하세요
쉘이 준비되면 앱 시작 시에 가볍게 체크를 실행하세요. 업데이트가 필요하지 않으면 첫 번째 화면을 블록하지 마세요.
Capacitor 앱의 일반적인 패턴은 다음과 같습니다.
import { App } from '@capacitor/app'
// import your updater SDK here
type UpdateDecision =
| { kind: 'none' }
| { kind: 'soft'; version: string }
| { kind: 'hard'; version: string }
| { kind: 'silent'; version: string }
async function checkForUpdate(): Promise<UpdateDecision> {
try {
// Replace with your updater SDK call
const result = await updater.check()
if (!result || !result.available) {
return { kind: 'none' }
}
if (result.metadata?.mandatory === true) {
return { kind: 'hard', version: result.version }
}
if (result.metadata?.silent === true) {
return { kind: 'silent', version: result.version }
}
return { kind: 'soft', version: result.version }
} catch {
return { kind: 'none' }
}
}
App.addListener('appStateChange', async ({ isActive }) => {
if (!isActive) return
const decision = await checkForUpdate()
handleUpdateDecision(decision)
})의 목적은 "새로운 것이 있는가"뿐만 아니라 "이 사용자가 이 채널에 대해 새로운 것이 있는가"입니다. check() 이러한 사용자와 채널에 대한 새로운 것이 있는지 확인하고 앱이 이를 어떻게 반응해야 하는지에 대한 것입니다. 건전한 구현에서는 마지막으로 성공적으로 체크한 시간과 마지막으로提示된 버전을 저장합니다. 이로 인해 앱 업데이트 알림 로직이 중복되지 않고 지속적으로 표시되지 않습니다. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ __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__
- __CAPGO_KEEP_7__ __CAPGO_KEEP_8__
- __CAPGO_KEEP_9__ __CAPGO_KEEP_10__
__CAPGO_KEEP_11__
이 walkthrough는 Capacitor 앱을 둘러싼 더 광범위한 설정을 보는 데 유용합니다:
code 시작 시에 지혜는 rollout 정책에 속해야 합니다.
효과적인 알림 패턴 설계
업데이트提示이 실패하는 이유는 대부분 팀이 하나의 패턴을 선택하고 모든 것에 사용했기 때문입니다. 그 결과, 복사 수정에 대한 차단 모달을 표시하거나 nobody가 주목하지 못하는 중요한 마이그레이션을 토스트 뒤에 숨기게 됩니다.
환경은 이미 꽉 차 있습니다. Business of Apps의 Airship 벤치마크 요약 __CAPGO_KEEP_0__ 앱 사용자의 평균 미국 스마트폰 사용자는 일일 평균 46개의 푸시 알림을 받습니다.푸시 알림 반응 및 클릭률은 iOS에서 3.4%, Android에서 4.6%로 비교적 낮습니다. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ __CAPGO_KEEP_0__. 사용자에게 주목을 끌면서도 피로를 주지 않는 앱 업데이트 알림이 있어야 한다.
사용자에게 최소한의 방해를 주면서도 효과가 있는 패턴을 사용하라.
좋은 업데이트 UI는 방해의 비용을 존중한다. 사용자가 결제 정보를 입력하고 있거나, 환자 기록을 입력하거나, 재고를 스캔하고 있다면, 모달은 고쳐야 할 버그보다 나쁠 수 있다.
나는 보통 이런 패턴을 매핑한다.
- 상단 또는 하단 배너 소규모 수정, 낮은 긴급성 개선, 무음 업데이트 확인에 사용한다.
- 토스트 배경 상태, 예를 들어 “다음 런칭 시 업데이트 준비됨”, 하지만 중요하지 않은 결정에 사용하지 않는다.
- 설정 또는 프로필 진입점 컨트롤과 변경 로그의 가시성을 원하는 사용자에게 사용한다.
- 차단 모달 새로운 버전이 설치되지 않은 경우에만 사용할 수 있습니다.
슬기로운 배너는 종종 드라마틱한 모달보다 더 많은 일을 합니다. 왜냐하면 사용자가 인터페이스와 싸울 필요가 없기 때문입니다.
주요 패턴 간의 빠른 비교
| 패턴 | 좋은 점 | 주요 위험 | implementation note |
|---|---|---|---|
| 배너 | 선택적 업데이트, 낮은 긴급성의 유도 | 쉽게 무시할 수 있습니다 | 버전당 무시할 수 있는 거부 |
| 토스트 | 배경 상태 변경 | 바로 사라지기 | 강한 설정 항목과 pair |
| 앱 내 메시지 | 상황에 맞는 기능 출시 | 빠르게 보이지 않을 수 있음 | 관련된 화면과 연결 |
| 모달 | 필수 동작 | 사용자 불만 | 어려운 게이트에만 예약 |
implementation에 가장 중요한 세부 사항 상태 유지. 사용자가 “나중에”를 탭하면, 해당 버전을 저장하세요. 사용자가 배너를 닫으면, 모든 경로 변경 시 다시 표시하지 마세요. 이 점을 잊으면, 업데이터가 작동해도 사용자가 앱이 고장 났다고 느낄 수 있습니다.
팀이 이미 push를 라이프사이클 스택의 일부로 사용 중이라면, 앱 업데이트 UX를 더 광범위한 메시징 설정과 비교하는 것이 가치가 있습니다. Capgo의 가이드 아이온IC과 Capacitor 푸시 알림을 Firebase와 함께 사용하세요. 앱 내부 표면이 사용자에게 동작을 요청하는 것을 분리하는 데 도움이 되므로, 이 기능은 여기서 유용합니다.
푸시만으로는 이야기가 다르다
OS-level 업데이트의 배지와 스토어 알림이 사용자를 보호해 줄 것이라고 가정하는 것은 일반적인 실수입니다. 실제로 사용자는 장치 설정, 배지 권한, 자동 업데이트 동작, 또는 전원 절약 모드와 같은 이유로 이러한 알림을 놓치기 쉽습니다. 따라서 스토어 생태계가 올바르게 작동하는 경우에도 앱 내 메시징이 여전히 중요합니다.
전자 애플리케이션의 경우, 이점이 훨씬 더 명확합니다. 데스크톱 사용자는 불필요한 상태 표시줄 대신 workflow 중간에 초점을 빼앗는 시스템 대화 상자를 예상하지 않습니다. 셸에 작은 "업데이트 준비" 칩이 시스템 대화 상자보다 더 전문적인 대안일 수 있습니다.
업데이트의 위험과 사용자의 현재 작업을 맞추는 패턴이 가장 좋습니다. 그 외의 모든 것은 무용극입니다.
업데이트 흐름 자동화 및 사용자 선택
대상 언어: 한국어 보호 토큰: Cloudflare, Capacitor, GitHub, Capgo, code, API, SDK, CLI, npm, bun 텍스트: 감지 및 UX 패턴이 구축된 후, 핵심 시스템은 워크플로우입니다. 이 안에서 팀들은 종종 과도한 자동화로 제어를 잃거나, 지원 부채를 발생시키는 자동화 부족을 겪습니다.
코드리오의 앱 유지 관리 지침 개발자 두려움에 의한 것이 아니라, 릴리스 유형에 따라 결정해야 합니다. low-risk 변경에 대한 silent 업데이트 silent 업데이트는 __CAPGO_KEEP_0__ 앱에서 가장 많이 사용되지 않는 경로입니다. 스타일링, 복사본, 기능 플래그 연결, 또는 중단되지 않는 자바 스크립트 버그를 수정한 경우, 사용자에게 중단하지 않아도 됩니다. 업데이트 흐름은 간단합니다: low-risk 변경에 대한 silent 업데이트 low-risk 변경에 대한 silent 업데이트low-risk 변경에 대한 silent 업데이트
low-risk 변경에 대한 silent 업데이트
Silent updates are the most underused path in Capacitor apps. If you fixed styling, copy, feature-flag wiring, or a non-breaking JavaScript bug, there’s usually no reason to interrupt the user at all.
low-risk 변경에 대한 silent 업데이트
- __CAPGO_KEEP_0__은 새로운 번들을 확인합니다.
- 배경 적용이 안전하다고 표시된 업데이트가 있는 경우 배경에서 다운로드합니다.
- 앱은 다음 런칭 시 새로운 번들을 활성화합니다.
- 리스트를 다시 시작한 후 사용자는 성공적으로 업데이트된 메시지를 잠시 보거나 아무것도 보지 않을 수 있습니다.
마지막 선택은 변경에 따라 달라집니다. 만약 업데이트가 가시적인 워크플로를 변경했다면 다음 런칭 시 작은 “새로운 기능” 카드를 통해 사용자가 방향을 찾을 수 있습니다. 만약 그렇지 않았다면 침묵이 좋습니다.
간단한 상태 핸들러는 다음과 같이 생길 수 있습니다.
async function handleUpdateDecision(decision: UpdateDecision) {
if (decision.kind === 'silent') {
await updater.download()
await updater.setNextBundle()
localStorage.setItem('pendingUpdateVersion', decision.version)
return
}
if (decision.kind === 'soft') {
showBanner(decision.version)
return
}
if (decision.kind === 'hard') {
showForcedUpdateScreen(decision.version)
}
}가시적인 제품 변경에 대한 사용자 선택 흐름
사용자 선택 흐름은 사용자가 인터럽션에 동의해야 하는 충분히 충분한 동작 변경이 있는 경우에 적합합니다. 새로운 네비게이션, 개정된 온보딩, 승인 흐름의 변경, 또는 대규모 데스크톱 리디자인 모두 이 그룹에 속합니다.
prompt는 좁아야 합니다.
- 무엇이 변경되었나요?
- 왜 중요합니까?
- 업데이트를 지금하면 무슨 일이 일어날까요?
- What happens if they wait
Don’t write release-note poetry into the dialog. One clear sentence and two buttons usually outperform a wall of copy.
I like this pattern:
새로운 버전이 사용 가능합니다. 업데이트된 보고서 workflow와 내보내기 문제를 해결하는 업데이트가 포함되어 있습니다. 업데이트 하거나 나중에 설치할 수 있습니다.
“나중에”를 신중하게 사용하세요. 이전 클라이언트가 유효한 경우 사용자가 계속 진행할 수 있습니다. 이전 클라이언트가 API 마이그레이션으로 인해 깨질 경우, 옵션처럼 보이지 마세요.
애플리케이션 배포를 넘어 지배를 생각하는 팀에게도 동일한 논리는 보안 운영에 나타납니다. 좋은 자동화는 정기적인 변경을 조용히 처리하고 위험을 정당화하는 경우에만 중단합니다. 그 이유 중 하나는 이 보안 자동화의 개요가 SOC 팀에게 유용한 이유입니다. 그것은 더 광범위한 설계 원칙을 보여줍니다: 이벤트를 분류하고 안전한 경로를 자동화하고, 인간의 중단을 의도적으로 만듭니다. 보안 자동화의 개요 사용자 빈도 세분화에 대한 __CAPGO_KEEP_0__의 기사
You can also tighten this with audience logic. Capgo’s article on 좁은 крит적 사례에 대한 강제 업데이트 __CAPGO_KEEP_0__
__CAPGO_KEEP_0__
강제 업데이트는 합법적입니다. 또한 그들을 남용하기도 쉽습니다.
하드 게이트를 사용할 때 다음 중 하나가 참일 때 사용하십시오.
| 조건 | 강제 업데이트 |
|---|---|
| 알려진 취약점이 있는 보안 패치 | Yes |
| 중요한 안정성 문제로 인한 심각한 파괴 | Yes |
| 백엔드 계약을 깨는 경우 | Yes |
| 미소한 UI 개선 | No |
| 선택적 기능 출시 | 아니요 |
implementation은 명확해야 합니다. 앱이 시작될 때 설치된 버전을 확인하고, 최소 지원 버전과 비교하여 사용자가 그 아래에 있는 경우에만 사용자를 차단 상태로 만듭니다. "필수"를 "새 버전이 존재한다"에서 추론하지 마십시오.
강제 업데이트 화면은 세 가지 속성을 필요로 합니다:
- 죽은 길이 없습니다. 사용자에게 명확한 다시 시도 경로를 제공하십시오.
- 명확한 설명. 사용자에게 업데이트 이유를 설명하십시오.
- 오프라인 처리. 네트워크가 사용할 수 없을 때도 설명하십시오.
이러한 화면은 "Update" 버튼 하나만 있는 모달이 실패할 때 나타나야 합니다. 사용자가 네트워크가 불안정할 때도 알 수 있도록 하십시오. 앱이 차단된 경우, 복구 경로는 일반 경로보다 더 정제되어야 합니다.
채널 및 센서를 사용한 고급 출시
Most update incidents don’t happen because detection failed. They happen because the team shipped broadly before they learned what the update was doing in the wild.
채널은 폭파 반경을 줄여준다.
채널 기반의 롤아웃은 클라이언트 앱에서 실시간 업데이트 SHIPPING의 가장 안전한 방법이다. 모든 사용자에게 하나의 패키지를 배포하는 대신, 내부, QA, 베타, 스테이징, 프로덕션, 또는 고객별 스트림과 같은 대상으로 배포한다.
이것은 운영 제어보다 바이너리 런칭보다 더 많은 릴리스 형태를 제공한다. 하나의 빌드는 각 대상이 다음 그룹이 업데이트 내용을 확인하기 전에 자신에게 신뢰를 제공하는 대상의 순서를 따라간다.
업데이트 워크플로우와 관련된 계획 구조를 포함한 상업용 롤아웃 모델의 유용한 스크린샷은 아래에 있다.
이것은 알림 전략에도 중요하다. Adapty의 푸시 알림 최적화 가이드 보고서에 따르면 최적화된 전송 시간은 반응률을 40%까지 증가시킬 수 있다. 그리고 고급 타겟팅은 반응률을 3배까지 증가시킬 수 있다.. 업데이트시스템에서 이건 채널에 의존하는 롤아웃과 버전별 메시징으로 번역됩니다. 전체 설치 기반에 대한 일반적인 경고를 보낼 필요가 없습니다.
측정치는 사용자가 실제로 이동했는지 여부를 알려줍니다.
전문적인 업데이트시스템은 다음과 같은 질문에 대한 답변을 제공해야 합니다. 엔지니어링이 ad hoc 로그를 뒤지지 않고:
- 각 기기는 어떤 버전의 배포본을 사용하고 있습니까?
- 업데이트가 다운로드되었습니다.
- 다음 런칭 시에 성공적으로 적용되었습니다.
- 롤아웃 후 시작 오류가 증가했습니다.
- deprecated 버전에 고착된 사용자는 누구입니까?
측정치는 업데이트를 출시 행위에서 운영 프로세스로 바꾸는데 도움이 됩니다. 없으면 shipped 한 것을만 알 수 있습니다. 있으면 사용자가 채택한 것을 알 수 있습니다.
지원팀이 업데이트 상태를 볼 수 없다면, 지원팀은 실제로 롤아웃 문제가 아닌 제품 문제로 제품 문제를 상승시킵니다.
나는 단일 기기 타임라인을 aggregate-only 대시보드보다 선호합니다. aggregate-only 대시보드는 유용하지만, 하나의 기업 고객이 1주일 후에도 이전 배포본을 여전히 앱을 열고 있는 이유를 설명하지 못합니다. 기기별 로그는.
특정 계층을 분리할 수 있기 때문에 버전별 배포도 더 실용적이게 됩니다. 이 문서는 특정 버전을 사용자에게 전송하는 경우 여러 고객 환경을 지원하는 경우 기업 팀이 종종 필요한 제어의 예입니다.
CI/CD는 빌드만 하는 것이 아니라, 빌드와 관찰을 해야 합니다.
현대 pipeline는 '빌드 성공'에 그치지 말아야 합니다. 그것은:
- 빌드 배ंडल
- 권한 있는 채널에 배포
- 릴리즈 메타데이터 첨부
- 수용과 실패를 모니터링
- 건강이 악화되면 롤백
롤백은 데모 업데이터와 프로덕션 업데이터의 차이입니다. 배ंडल이 런치 충돌이나 시작 중단을 일으키면 팀은 빠르게 폭파 반경을 막아야 합니다. 그게 가장 큰 이유로 관리 도구가 DIY보다 대부분의 대행사에 이길 수 있는 이유입니다. 배달, 경계, 관찰성, 롤백은 부가 기능이 아닙니다. 그것은 시스템입니다.
CI/CD 통합 자체가 복잡해질 필요는 없습니다. 중요한 것은 배포가 결정적이고 추적 가능해야 합니다. 릴리즈는 커밋, 환경, 액터, 채널에 대한 정보로 attributable해야 합니다. 만약에 그 네 가지 정보를 빠르게 답변할 수 없다면, 사고 대응이 난해해집니다.
통지 문제를 해결하는 일반적인 방법
Capacitor와 Electron 업데이트워크에서 반복적으로 나타나는 문제는 주로 상태漂移에서 비롯됩니다. 네트워크에서 비롯되는 것이 아닙니다.
앱이 시작될 때마다 나타나는 알림입니다.
증상: 사용자는 앱 업데이트 알림을 무시하지만, 앱이 열릴 때마다 다시 나타납니다.
가능한 원인: 정상적으로 확인했지만, 제공된 버전에 따라 프롬프트 상태를 영구적으로 저장하지 않습니다.
해결 방법: 사용자가 무시하거나 미루었던 버전을 저장하고, UI를 다시 보여주기 전에 비교합니다.
function shouldPrompt(version: string): boolean {
const dismissed = localStorage.getItem('dismissedUpdateVersion')
return dismissed !== version
}
function dismissPrompt(version: string) {
localStorage.setItem('dismissedUpdateVersion', version)
}이것은 팀이 “사용 가능”과 “중단해야 함”을 혼동하는 곳입니다. 두 가지 결정은 다릅니다.
무음 업데이트가 다운로드되지만 활성화되지 않습니다.
증상: 로그에 표시된 바에 따르면, 패키지가 다운로드되었지만, 이전 UI가 계속 로드됩니다.
가능한 원인: 앱이 업데이트 다운로드를 완료했지만 다음 실행을 위해 표시하지 않았거나, 마지막 활성화된 번들을 참조하는 시작 경로가 여전히 있습니다.
수정: code와 분석에서 "다운로드"와 "활성"을 별도의 상태로 모델링하고, 활성화를 명시적으로 하며 부트 중에 확인하세요.
많은 버그가 lifecycle 모델을 하나의 불리언 대신에 "다운로드"와 "활성"과 같은 별도의 상태로 모델링할 때 사라집니다. available -> downloading -> ready -> active 체크는 개발자 모드와 프로덕션 모드에서 다르게 동작합니다.
증상:
릴리스 빌드에서 업데이트 감지가 작동하지만 로컬 개발 환경에서 작동하지 않거나, 그 반대 경우. 가능한 원인:
환경에 따라서 구성이 다릅니다. 개발자 모드에서 채널 이름이 다르거나, 플러그인이 비활성화되거나, 시작 __CAPGO_KEEP_0__이 올바른 보호자로 wrapping되지 않았습니다. environment-specific configuration. Different channel names, disabled plugins in debug, or startup code wrapped in the wrong guard.
__CAPGO_KEEP_0__ 환경 동작을 보이도록 로그 채널, 앱 버전, 및 빌드 모드를 시작 시 표시하십시오. 메모리에 의존하지 마십시오.
- 개발용 빌드 일반적으로 라이브 업데이트 검사를 무시하거나 전용 테스트 채널을 가리 킵니다.
- 스테이징 빌드 프로덕션과 같은 동작을 하지만 고립된 롤아웃 스트림에 대해 테스트합니다.
- 프로덕션 빌드 내부 QA 트래픽과 채널을 공유하지 않습니다.
네트워크가 불안정할 때 사용자는 오프라인입니다.
증상: 사용자가 네트워크가 불안정할 때 앱을 열면 업데이트 상태가 깨진 상태로 나타납니다.
원인: 체크 경로가 네트워크 성공을 가정하고 실패를 오류 UI로 대신하는 대신 중립적인 상태로 맵핑합니다.
수정: 현재 버전을 유지하고 실패한 체크를 기록한 후 앱이 다시 활성화 될 때까지 다시 시도하십시오.
오프라인은 일반적인 런타임 상태이며 예외적인 상태가 아닙니다.
강제 업데이트의 경우 오프라인 경로가 더 많은 주의가 필요합니다. 최소 지원 버전이 이미 유효하지 않은 경우 앱이 블록되도록 유지해야 할 수 있습니다. 그 경우, 네트워크 연결이 돌아올 때까지 다시 시도할 수 있는 이유를 명확하게 설명하고 punish하지 마십시오. 만약 업데이트가 선택적이라면, 임시 네트워크 손실로 사용자를 벌지 마십시오.
이러한 모든 경우의 반복되는 원칙은 간단합니다: 탐지, 정책, UI, 활성화. 그들의 관심사들이 하나의 훅 또는 하나의 화면 컴포넌트로 통합될 때, 디버깅은 추측으로 변합니다.
If your team is shipping Capacitor or Electron apps and you need a controlled update system with channels, signed bundle delivery, rollback protection, and device-level observability, Capgo __CAPGO_KEEP_0__이 팀에 적합합니다. __CAPGO_KEEP_0__은 업데이트가 즉시 반영되는 릴리즈 인프라와 같은 경험을 원하는 팀에 적합합니다.
__CAPGO_KEEP_0__에서 계속 Effective App Update Notification Strategies
__CAPGO_KEEP_0__을 사용 중이라면 Effective App Update Notification Strategies CI/CD 자동화 계획을 위해 연결하세요. Capgo CI/CD Capgo CI/CD에서 제품 워크플로우를 위해 Capgo Native Builds Capgo Native Builds에서 제품 워크플로우를 위해 Capgo Integrations Capgo Integrations에서 제품 워크플로우를 위해 CI/CD 통합 CI/CD 통합 구현 세부 사항에 대해, 그리고 GitHub 액션 통합 GitHub 액션 통합 구현 세부 사항에 대해.
