대부분의 비용 최적화 조언은 잘못된 곳에서 시작됩니다. 그것은 서버와 저장소에서만 비싼 부분이 존재한다는 것처럼 팀에게 클라우드 비용을 줄이기를 권장합니다. 그러나 모바일 팀은 릴리즈 경로 자체에서 비용이 많이 드는 부분이 종종 발견됩니다. 여기서 모든 oversized 배포, 리뷰 지연, 롤백, 지원 불상사 등은 예방할 수 있었던 작업에 대한 비용이 됩니다.
Capacitor 및 Ionic, Electron 팀을위한 비용 최적화 비용 최적화는 저렴한 청구서를 추적하는 것보다 모든 릴리즈의 표면 영역을 줄이는 것에 더 중점을 둡니다. 가장 견고한 절약은 비용을 구조적 제약으로 다루고, 지속적으로 측정하고, 업데이트를 디자인하여 가능한 가장 작은 변경이 올바른 사용자에게 최소한의 운영摩擦와 함께 도달할 수 있도록 하는 것입니다. 그게 비용 최적화 전략의最佳 사례의 마음가짐입니다. 비용 최적화 전략의最佳 사례, 그리고 그것은 릴리즈 엔지니어링이 재무 및 제품에 앉아있는 이유와 같습니다.
유용한 렌즈는 Capgo의 운영 효율성 지침 점향하는 렌즈입니다. 불필요한 전달을 줄이고, 빠른 복구, 그리고 code 준비된 것과 code shipped 사이의 폐기물을 줄입니다. 그 렌즈를 모바일 전달에 적용하면 작은 패키지, 적은 지원 티켓, 적은 핫픽스, 그리고 다음 스토어 리뷰를 기다리는 시간을 줄이는 이익이 나타납니다.
목차
- 컨텍스트: Capgo 마케팅 웹사이트. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 위치: 페이지 blog/[slug].astro. 메시지 키 `table_of_contents` (목차).
- 릴리즈 표면 영역을 줄여라
- 실제로 모바일 릴리스 비용을 드러내는 KPI
- 최대 절약을 위한 릴리스 전략 비교
- Capgo 시간이 지남에 따라 비용 절약을 증대시키는 전략
- 90일간의 비용 최적화 계획을 만드는 방법
- 실제 세계 비용 최적화
모바일 팀이 자신의 비용 최적화 플레이북이 필요하다
클라우드 최초의 조언은 모바일 비용이 누적되는 방식에 대해 무시한다. 모바일 팀은 일반적으로 서버 인스턴스가 oversized 한 이유로 예산을 초과하지 않는다. 그러나 CI 분량이 동일한 자산을 다시 빌드하는 데 소요되는 시간, 앱 검토 지연이 수정을 지연시키는 경우, 지원 티켓이 나쁜 릴리스로 인해 트리거되는 경우, 사용자가 다운로드하는 데이터가 변경된 code 만큼의 양을 초과하는 경우에 돈을 잃는다.
비용 최적화 작업은 릴리스 PIPELINE에서 시작해야 하며 저장층에서 시작하지 않아야 한다. AWS, FinOps 프레임워크 및 클라우드 비용 연구에서 제공하는 클라우드 지침은 모두 같은 discipline을 강조한다. 즉, 관리할 수 있는 레버를 추적하고, 작업별로 waste를 측정하고, 지속적으로 최적화하는 것이다. 단 한번의 정리만으로는 충분하지 않다. 클라우드 비용 최적화 지표. 동일한 논리가 앱 전달에 적용된다. 릴리스 경로가 waste를 생성하는지 알 수 없다면, 그것을 줄일 수 없다.
릴리스 속도를 비용 변수로 다루어라
릴리스 속도가 느리면 비용이 많이 들다. 수정이 스토어 승인待ち일 때, 지원이 동일한 문제를 계속 처리하고, 엔지니어링이 컨텍스트 Switching을 계속하고, 제품이 결정을 미루고 있는 경우가 많다. 결함 발견부터 사용자 복구까지의 시간 차이가 길수록, 각 사고당 시간, 명성, 추후 작업 비용이 증가한다.
이것은 왜 mobile 팀이 릴리스 속도와 회복을 함께 측정해야 하는 이유입니다. 릴리스 경로가 빠르지만 모든 작은 콘텐츠나 설정 변경에 대해 전체 빌드를 다시 빌드해야 하는 것은 효율적이지 않습니다. 그것은 단지 잘못된 양의 작업을 더 빠르게 수행하는 것입니다.
릴리스 표면 영역을 줄이십시오
릴리스 효율성을 최적화하는 가장 실용적인 방법은 작은 변경에 대해 앱이 얼마나 움직여야 하는지 줄이는 것입니다. 만약에 복사본, 설정, 또는 하나의 기능 branch만 변경되었다면, 전체 배포를 보내는 것은 단지 한 장이 수정된 책을 우편하는 것과 같습니다. 차등 업데이트, 대상된 롤아웃, 런타임 구성은 이러한 waste를 줄여 릴리스를 더 정확하게 만듭니다.
작은 diff, 반복된 다운로드 횟수, 롤백의 고통을 줄이는 데 대한 아키텍처 규칙은 간단합니다. 변경이 스토어 릴리스가 필요하지 않다면, 그 변경을 강제하지 마십시오. 롤아웃이 모든 사용자가 필요하지 않다면, 모든 사용자에게 배포하지 마십시오. 이것이 모바일 팀이 가장 많이 절약하는 곳입니다.모바일 앱 팀이 통제할 수 있는 모든 앱 팀의 핵심 비용 조절 매개변수
모바일 릴리스 waste는 일반적으로 5가지 곳에 나타나며, 팀이 그것을 측정하기만 하면, 팀이 통제할 수 있습니다. 첫 번째는
빌드 PIPELINE 효율성 이것은 시간과 클라우드 분량을 소모하는 느리고 중복된 CI 작업입니다.두 번째는 업데이트 페이로드 크기다음은 5가지 비용 최적화의 중요성에 대한 이유입니다. 배포 인프라배포 인프라는 CDN 동작, 에지 라우팅, 업데이트된 바이트의 경로를 포함합니다. 롤백 및 사고 대응하나의 잘못된 릴리즈는 수 시간의 조사로 이어질 수 있습니다. 대상 지정모든 사용자에게 동시에 변경이 필요하지 않기 때문에.
모바일 팀은 클라우드 팀이 사용하는 비용 дисцип린이 같은 것을 생각해야 합니다. 하지만 waste는 릴리즈 경로에 있지 않고 가상 머신에 있습니다. 메트릭은 여전히 중요합니다. 왜냐하면 메트릭은 노력의 유출, 할당의 너무 넓은 범위, 그리고 무작위 작업이 쌓이는 곳을 보여주기 때문입니다..
자세한 설명을 위해서는我们的
- 자원 최적화 가이드 If your pipeline recompiles unchanged assets, reruns identical tests, or produces multiple artifacts for the same code state, you are paying for duplication. That is repeated work, plain and simple.
- 테스트 인프라스트럭처. 장치 농장, 시뮬레이터 및 수동 QA 모두 비용이 있습니다. 팀은 종종 불필요한 전체 릴리스 확인을 통해 더 작은 업데이트 경로가 더 적은 검증이 필요한 경우에 장치 농장을 바쁘게 유지합니다.
- 데이터 저장소. 릴리스 아티팩트, 로그 및 분석 데이터는 시간이 지남에 따라 확장됩니다. 릴리스 아티팩트, 로그 및 분석 데이터를 영원히 보존하지 않고 보존 정책이 없는 경우, 프로세스에 저장소 세금을 부과합니다.
- 배포 채널. 스토어 리뷰, CDN 트래픽 및 업데이트 메커니즘은 각 릴리스가 추가하는 운영적 마찰의 정도를 모두 영향합니다. 목표 업데이트 경로를 사용하면 트래픽을 줄이고 대규모 오류의 가능성을 낮출 수 있습니다.
- 모니터링 및 분석. 팀이 버전 채택, 실패 스파이크 또는 롤백 트리거를 볼 수 없다면, 릴리스 경로가 돈을浪費하는지 알 수 없습니다.
실용적인 규칙: 릴리스가 앱을 code으로 변경하지 않는다면, code-형태의 오버헤드가 필요하지 않아야 합니다.
최고의 팀은 각 레버를 독립적으로 최적화하지 않습니다. 그들은 연결합니다. 더 작은 패킷은 대역폭을 줄입니다. 더 좋은 목표는 사고 범위를 줄입니다. 더 빠른 감지는 지원 부하를 줄입니다. 그 연결은 단일 도구 선택보다 더 중요합니다.
아래의 인포그래픽은 제품 매니저에게 릴리스 엔지니어링 강의를 듣고 싶지 않은 경우에 구조를 가장 간단하게 설명하는 방법입니다.
다섯 가지 조절 장치의 목표는 모두 동일합니다. 각 릴리스를 더 저렴하게 만들고, 배송을 더 저렴하게 하며, 유효성을 더 저렴하게 하며, 복구를 더 저렴하게 하세요.
실제로 모바일 릴리스 비용을 드러내는 KPI
빌드 수와 배포 빈도는 릴리스 작업이 저렴하거나 비싼지 알려주지 않습니다. 단지 팀이 바쁘다는 것을 알려줍니다. 모바일 팀은 자주 릴리스를 배포할 수 있지만, 모든 릴리스가 너무 크거나, 잘못된 사용자에게 aimed되거나, 복원하기 어려운 경우 여전히 돈을浪費할 수 있습니다.
비용을 드러내는 메트릭은 릴리스당 비용, 업데이트 수용률, 롤백 빈도, 유저당 페이로드 크기및 다운타임 시간당 비용. 이 신호들은 릴리스 PIPELINE이 가벼워졌는지还是 단순히 더 빠르게 움직이는지 보여줍니다. 또한 클라우드 운영에 사용되는 더 광범위한 비용 관리 접근 방식과도 일치합니다. 사용량에 대한 raw 사용량 대신 비즈니스 가치와 비용을 연결하는 것에 대해 논의한 AWS 비용 효율성 보고서.
간단한 기준 설정 방법
첫 번째 앱, 첫 번째 채널, 첫 번째 릴리스 유형으로 시작하세요. 업데이트 시간, 사용자가 업데이트 시간을 얼마나 걸리는지, 롤백 횟수, 지원 팀이 버전별 문제를 얼마나 자주 보는지 측정하세요. 기준이 존재하면 새로운 릴리스 경로와 비교하여 측정하세요. 느슨한 느낌에 따라 측정하지 마세요.
좋은 기준은 재미없다. 팀이 기준을 1분 이내에 설명할 수 없다면, 그 기준은 행동을 이끌어내는 데 너무 복잡할 것이다.
숫자를 모으는 것이 어려운 것은 아니다. 올바른 사람에게 할당하는 것이 어려운 것이다. 재무팀은 어느 제품 라인이 비용을 책임지는지 알아야 하며, 모바일 리드 팀은 어느 릴리스 패턴이 비용을 책임지는지 알아야 하며, 제품 매니저는 어느 코호트를 먼저 타겟팅했는지 여부를 확인해야 한다.
릴리스 메트릭이 결정을 내리지 못한다면, 그것은 장식이다.
모바일 릴리스 KPI와 그들이 드러내는 것
| KPI | 측정하는 것 | 숙련된 팀의 목표 |
|---|---|---|
| 릴리스당 비용 | 전체 릴리스 노력 | 팀에서 잘 이해되고 안정적 |
| 업데이트 수용률 | 사용자가 최신 버전으로 얼마나 빨리 이동하는가 | 지원 기간이 짧아야 한다 |
| 롤백 빈도 | 릴리스가 뒤로 돌아가야 하는 빈도 | 낮고 철저히 모니터링 |
| 사용자당 다운로드되는 데이터 양 | 정기적인 수정 및 구성 변경과 같은 경우에는 작아야 한다 | 다운타임 시간당 비용 |
| __CAPGO_KEEP_0__ | 릴리스 실패 시 운영 및 지원 부담 | 일관되게 추적하고 소유주와 연결 |
팀이 너무 늦게 묻는 중요한 질문은 무엇인가? 이 릴리스가 작업을 절약하거나 만들었는가? 이 답변은 같은 주 내에 대시보드에 나타나야 하며, 분기 종료 검토 후에는 안 된다.
라이브 업데이트 사용하는 팀에게는 실시간 업데이트 메트릭이 Capacitor 앱에 적용된다 실시간 업데이트 메트릭은 앱의 채택 속도와 실패 시점을 KPI와 연결하여 비용 관리가 측정 가능한 수준으로 한다.
최대 절약을 위한 릴리스 전략 비교
한 줄의 복사본만 변경하는 릴리스도, 네이티브 퍼미션 변경과 같은 배달 비용을 지불해야 한다. 모바일 팀은 이 실수를 빌드 시간, 검토 오버헤드, 지원 부하, 피할 수 있는 롤백 작업으로 치르게 된다. 복사본 업데이트, 핫픽스, 정책 조정, 기능 출시 등은 다른 비용 항목에 속하기 때문에 하나의 경로를 강요하면 돈을浪費하고 일반적으로 추가적인 위험을 발생시키며 그만큼 이익을 얻지 못한다.
모바일 팀의 실용적인 비교는 릴리스 철학에 대한 추상적인 비교가 아니다. 그것은 앞에 있는 변경에 대한 비용을 절약하는 경로를 찾는 것과 같다. 이는 staged rollout 의사결정과 전체 릴리스 사이의 전략적 트레이드 오프와도 같다. . senior 모바일 팀에게는 단순한 질문 하나만 필요하다. 이 업데이트를 위해 어떤 경로가 바이트, 검토 노력, 인시던트 노출을 줄이는 것인가?중요한 전략적 트레이드 오프
실시간 업데이트 메트릭은 앱의 채택 속도와 실패 시점을 KPI와 연결하여 비용 관리가 측정 가능한 수준으로 한다.
| 릴리스 전략 | 최적의 선택 | 컨텍스트: Capgo Builder / 네이티브 클라우드 빌드 제품 페이지. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 메시지 키 `native_build_builder_compare_fit_feature` (네이티브 빌드 빌더 비교 적합성 기능) | 주요 비용 이점 |
|---|---|---|---|
| 주요 위험 | 전체 스토어 릴리스 | 주요 기능 작업, 규제 변경 | 명확한 프로세스, 광범위한 호환성 |
| 가장 느린 경로, 가장 높은 검토 오버헤드 | 실시간 업데이트와 전체 배ंडल | 빈번한 수정이 더 빠른 배포를 필요로 함 | 스토어 대기 시간을 피하는 일부 변경 사항 |
| Differential updates | 작은 또는 중간 크기의 변경 사항에 안정적인 앱 구조 | 변경된 부분만 전송, 다운로드浪費를 줄임 | disciplined 패키징이 필요 |
| 대상별 배포 | 베타 스트림, 지역 변경, 클라이언트별 업데이트 | 폭파 반경과 지원 비용을 제한 | 소유권이 불명확한 경우 분할 |
전체 스토어 릴리스는 도구에 속합니다. 변경 사항이 네이티브 권한, 플랫폼 동작, 또는 공식 스토어 검토를 통과해야 하는 경우, 느린 경로가 안전한 경로일 때가 많습니다. 자바스크립트, CSS, 복사본, 구성, 및 자산 수정과 같은 경우, 모든 것을 전체 릴리스를 통과시키면 작은 변경이 더 큰 운영 비용이 되게 됩니다.
가장 가벼운 안전한 경로를 기본으로 하세요
가장 저렴한 경로는 일반적으로 가장 적은 바이트를 이동하고 필요한 사용자만에게 변경을 증명하기 위해 도달하는 경로입니다. 다이내믹 업데이트는 앱 구조가 안정적이고 패키지의 일부만 변경된 경우 의미가 있습니다. 대상별 배포는 팀이 위험을 포함하기 전에 광범위한 배포 전에 의미가 있습니다. 전체 패키지는 기본값이 아닌 반응이 아닙니다.
잘못된 기본값은 모든 변경을 제품 출시처럼 다루는 릴리스 전략입니다.
팀 크기가 수식의 수를 바꾼다. 작은 팀은 더 적은 전달과 덜한 조정 오버헤드를 필요로 한다. 큰 팀은 다른 제품 라인에 대한 릴리스 비용을 강제로 강제하는 것을 막기 위해 경비를 설치해야 한다. 릴리스 빈도도 중요하다. 왜냐하면 정기적인 배송은 빠르게 비용이 많이 들게 되기 때문이다.
리더십이 모든 경우에 적합한 하나의 릴리스 메커니즘을 왜 사용하지 못하는지 보여주는 아래의 인포그래픽이 도움이 될 것이다.
Capgo은 시간이 지남에 따라 비용 절감을 증대시키는 전략이다.
Capgo은 릴리스 pipe 내부의 waste를 공격하는 것이 아니라, 단지 최종 배포 단계만을 공격하는 것이 아니다. code의 변경 사항만을 업데이트하여 전송하는 방식으로, 불필요한 전송을 줄이고 변경 사항이 사용자 기기까지의 경로를 단축시킨다. 이는 위의 payload와 수용 KPI와 직접적으로 일치한다. 왜냐하면 작은 업데이트는 쉽게 배포할 수 있고, 테스트도 쉽고, 사용자에게도 쉽게 받을 수 있기 때문이다.
글로벌 에지 전송层도 실제로 매우 실용적인 방식으로 중요하다. 업데이트 파일이 사용자에게 더 가까운 곳에서 제공될 때, 팀은 지연 시간을 줄이고 중앙화된 경로에서 모든 기기를 pull하는 것을 피할 수 있다. 릴리스 워크플로우에서 이러한 분산 효율성은 추상적인 인프라 폴리시가 아니라, 기다리는 시간을 줄이고, 다운로드가 실패하는 것을 줄이고, 배달 경로가 문제를 일으켰는지 여부를 확인하는 시간을 줄이는 것이다. Capgo의 Capacitor 앱에 대한 Capacitor의 가벼운 배포 방법 그것은 그 모델에 잘 맞습니다.
Guardrails은 비용 제어기입니다.
채널 보호대와 자동 롤백 보호 기능은 단순히 안전 기능만이 아닙니다. 그들은 비용 제어기입니다. 생산 환경에 잘못된 릴리즈가 도달하면 지원 부하, 엔지니어링 중단, 사고 검토 작업이 비용을 초과할 수 있습니다. 비용이 저렴한 선택은 일반적으로 릴리즈를 일찍 중단하고 좁은 대상으로 제한하고 충분한 장치 수준의 증거를 수집하여 빠르게 결정하는 것입니다.
그것은 장치 수준에서 로그, 수용, 실패 신호를 볼 수 있게 되면 수사 시간이 추측에서 증거로 바뀌는 것입니다. 보상은 단순히 빠른 디버깅만이 아닙니다. 그것은 전쟁 방실에 참여하는 사람 수를 줄이고 동일한 실패를 재현하는 시도를 반복하는 것을 줄입니다.
운영 규칙: 릴리즈가 설명하기 어려울 때 이미 비용이 이미 발생했습니다.
이제 그 제어기를 함께 사용하세요. 차등 업데이트 는 패킷 폐기량을 줄입니다. 에지 전달은 분산 저항을 줄입니다. 보호대는 폭파 반경을 줄입니다. 롤백 보호는 사고 비용을 줄입니다. 단독으로는 모바일 비용 최적화 문제를 해결하지 못하지만 함께하면 효과가 누적됩니다.
90일 비용 최적화 로드맵을 구축하세요
90일 간의 기간은 현재 상태를 측정하고 명백한 낭비를 제거하고 비용이 반弹하지 않도록 습관을 설정하는 데 충분한 시간입니다. 또한 이 기간은 리더십이 일년 동안의 모호한 계획이 아닌 일과로 유지할 수 있는 기간입니다.
다음 로드맵은 클라우드 비용 최적화 원칙과 같은 논리를 따릅니다. 기준점을 설정하고 지속적으로 최적화하고 정기적인 일정에 따라 검토하는 대신 예상치 못한 상황을 기다리지 말고. 모바일 팀도 같은 discipline을 필요로 하지만, 릴리스 운영에 적용합니다.
1일부터 30일까지 명백한浪費를 측정하고 제거하십시오
모바일 스택이나 모니터링 층이 메모리 기반 프로파일링을 지원한다면 그 기능도 켜두세요. 더 나은 작업 부하 시각화는 추천 품질과 자원 계획을 개선할 수 있습니다. 그만큼 팀은 추측하지 않고 작업을 진행할 수 있습니다.
블UNT한 감사는 여기서 도움이 됩니다. oversized bundle, 반복적인 패키징 작업, nobody가 그들을 도전하지 않았기 때문에 존재하는 release step, risk를 줄이지 않고 cost를 추가하는 update path를 찾으세요.
31일부터 60일까지는 프로세스를 개선합니다.
다음으로 PIPELINE을 조정하세요. 불필요한 빌드 단계를 제거하고, 완전한 검증이 필요한 릴리스의 범위를 좁히고, 명백한 일상적인 변경 사항을 가벼운 배포 경로로 옮기세요. 목표는 모든 릴리스가 비용이 들지 않도록 하는 것이 아닙니다. 목표는 실제로 비용이 들 수 있는 경로를 변경이 필요로 하는 변경 사항에만 예약하는 것입니다.
이 또한 소유권을 조정하는 시기입니다. 비용 누출은 누군가가 더 비싼 릴리스 메커니즘을 선호하는 결정의 책임을 지지 않는 경우, 또는 엔지니어링, QA, 제품 팀이 나중에 누군가가 청소할 것이라고 가정하는 경우에 다시 나타납니다.
61일부터 90일까지 자동화 및 규제
마지막 단계에서 목표는 일관성입니다. 정기적인 비용 검토 점검을 설정하고, 더 광범위한 롤아웃을 승인하는 사람을 정의하고, 릴리스 패턴이 개선되고 있는지 여부를 판단할 수 있는 예측 정확도가 충분한지 확인하세요. AWS 비용 효율성 보고서 또한 비용을 성능과 신뢰도와 함께 유지하고, 디자인이 비용당 가치가 개선되는지 여부를 확인하는 것이 가치가 있습니다.
Snowflake의 비용 최적화 지침은 같은 아이디어를 다른 각도에서 설명합니다. 비용을 성능과 신뢰도와 함께 유지하고, 디자인이 비용당 가치가 개선되는지 여부를 측정하세요. Snowflake 비용 최적화 지침.
로드맵이 성공적으로 작동하고 있는지 확인하는 가장 rõ ràng한 증거는 간단합니다. 새로운 릴리스가 작아야 하며, 롤백이 드물어야 하며, 누군가가 비용이 어디에 들었는지 설명해야 하는 영웅적인 노력을 필요로 하지 않아야 합니다.
실제 비용 최적화
작업팀이 작은 Capacitor 팀으로 구성되어 있으며, 주간에 작은 UI 및 복사본 수정을 배포합니다. 루틴 변경을 다이내믹 업데이트로 전환한 후, 팀은 작은 편집에 대한 풀 배ंडल 페널티를 지불하지 않으며, 반복적인 패키징 및 검증으로부터 발생하는 릴리즈 오버헤드를 줄일 수 있습니다. KPI shift은 쉽게 볼 수 있으며, 페이로드 크기는 줄어들고, '새로운 빌드, 동일한 앱'과 관련된 지원 문제가 줄어들며, 팀은 풀 리워크가 필요하지 않은 릴리즈를 준비하는 데 소요되는 시간이 줄어듭니다.
여러 클라이언트 앱을 관리하는 대행사에서는 다른 경로를 선택합니다. 대상화된 롤아웃을 사용하여 하나의 클라이언트의 릴리즈가 전체 포트폴리오에 대한 광범위한 폭파 반경을 생성하지 않도록 합니다. 이는 오류의 비용을 줄이고, 지원을 라우팅하기가 더 쉬워지고, 버전별 문제를 분리하여 모든 앱을 단일 버킷으로 다루지 않도록 합니다.
규제된 기업 팀에서는 롤백 보호를 심각하게 취급합니다. 나쁜 릴리즈를 중단하거나 역전하는 능력을 지원 및 규제 제어로 다루기보다는 편의 기능으로 다루지 않습니다. 이는 나쁜 업데이트가 인시던트 리뷰, 고객 상향, 추가 서명 작업을 유발할 수 있는 환경에서 올바른 자세입니다.
세 가지 모두에서 공통적인 실패 모드는 동일합니다. 비용 최적화가 청소 작업으로 다루어지기보다는 운영 모델로 다루어지지 않으면, 저축이 반복되며, 소유권이 흐트러지고, 릴리즈 폐기물이 새로운 이름으로 돌아옵니다.
If your team is trying to cut release waste without slowing product delivery, Capgo gives you a practical path forward with differential updates, channel controls, rollback protection, and device-level observability for Capacitor and Electron apps. Visit Capgo __CAPGO_KEEP_0__
