Capacitor 및 Electron 팀을 위한 앱 사용자 경험 가이드

사용자가 앱을 첫 5분 동안 느끼는 불만족을 막기 위해 QA를 통과하고 스토어 리뷰를 통과한 후에도 플랫폼 앱을 배포할 수 있습니다. 로그인은 작동합니다. 네비게이션은 기술적으로 작동합니다. API은 데이터를 반환합니다. 그러나 리뷰에서는 앱이 느리고 불편하거나 불신스럽다고 말합니다.

그것은 앱 사용자 경험 lives.

Capacitor과 Electron 팀은 이러한 모든 문제를 겪고 있습니다. 기능 배포는 팀 내에서 가시적이지만 마찰은 팀 외부에서 나타납니다. WebView는 약간의 지연 후에 인터랙티브가 됩니다. 데스크톱 창은 이상한 상태로 복원됩니다. 양식 스피너는 작업이 진행 중인지 또는 멈췄는지 설명하지 않습니다. 업데이트는 한 번의 버그를 고치지만 사용자 베이스의 절반 이상이 오래된 번들을 사용하는 동안 며칠 동안 기다립니다. 이 모든 문제는 스프린트 데모에서 드라마틱하지 않습니다. 그러나 그것들은 사용자가 제품을 계속 사용하는지 여부를 정의합니다.

잘못된 UX는 더 이상 외관 문제가 아닙니다. Adjust는 사용자가 앱의 성능이 좋지 않다고 말한 90%가 사용자가 앱을 중단한 이유로 사용했다고 밝혔습니다. 모바일 앱의 사용자 경험에 대한 가이드에서 말했듯이, 엔지니어링 팀에 대한 대화는 바뀝니다. UX는 앱이 작동하는 후에 추가하는 층이 아닙니다. 성능, 신뢰성, 명확성, 사용자가 가치에 도달하는 속도에 따라서 작동합니다.

크로스 플랫폼 팀에게는 이게 위험과 기회를 모두 의미합니다. 위험은 iOS, Android, 데스크톱에서 동일한 마찰을 퍼뜨리는 한 코드베이스입니다. 기회는, 필요한 순간을 측정하고 안전하게 업데이트를 배포하는 경우, 한 번의 측정된 수정이 모든 곳에서 여행을 개선할 수 있기 때문입니다.

목차

• 소개
  • ‘작동하는’ 앱은 충분하지 않다.
  • 기술적으로 허용되는 UX의 숨겨진 비용
• Why this sits with engineering, not only design
  • 사용성은 경로가 명확해야 함
  • 성능과 신뢰성은 신뢰를 형성합니다
  • 가치가 사람들을 돌아오게 하는 이유
• 액션 가능한 지표를 사용하여 앱 사용자 경험을 측정하는 방법
  • 스케일을 측정하기 전에 마찰을 측정하십시오
  • 제품 및 엔지니어링을 위한 실제적인 지표 집합
• 플랫폼 간 앱 UX를 개선하기 위한 실제 전략
  • 느껴지는 속도를 먼저 고치십시오
  • 약한 네트워크와 불균형한 장치에 대한 디자인
  • 정확한 장소에서 상호 작용 패턴이 지루해야 함
• 계속적인 UX 개선에서 신뢰할 수 있는 업데이트의 역할
  • UX 수정이 실제로 사용자가 받을 때만 중요합니다
  • UX 워크플로우에서 롤아웃 제어를 사용하세요
• Putting It All Together Your First UX Improvement Cycle
  • 첫 번째 UX 개선 주기를 시작하기 위해 하나의 여행부터 시작하세요
  • 작은 주기를 실행하고 빠르게 학습하세요

소개 Why a ‘Working’ App Is Not Enough

작업을 완료하는 앱은 있습니다. 그러나 좋은 앱은 사용자가 작업을 완료하는 것을 방해하지 않고, 혼란스럽지 않으며, 두 번 생각하지 않도록 도와줍니다. 그것은 같은 것입니다.

많은 팀이 출시 후에 이것을 발견합니다. 내부 테스터들은 제품을 잘 알고 있기 때문에 흐름을 인내하고 맥락을 이해합니다. 그러나 실제 사용자는 그렇지 않습니다. 그들은 차갑게, 작은 화면에서, 회의 사이에, 약한 네트워크에서, 또는 랩탑 배터리가 거의 죽었을 때 도착합니다. 그들은 아키텍처가 아름답기만 해도 첫 번째 유용한 액션을 너무 오래 걸리거나 UI가 잠시 잠금 상태가 될 때는 관심이 없습니다.

기술적으로 충분히 좋은 UX의 숨겨진 비용

크로스 플랫폼 스택은 이 문제를 특정한 방식으로 증폭시킵니다. Capacitor 앱은 종종 모바일 네이티브 조건에서 적용되지 않는 웹 가정들을继承합니다. Electron 앱은 특히 팀이 데스크톱을 무제한 환경으로 간주하고 시작 작업, 배경 동기화, oversized front-end bundles를 쌓을 때 무거워집니다.

결과는 항상 충돌이 아닙니다. 종종 quieter:

• 의심 사용자가 다음 단계가 명확하지 않기 때문에 멈춥니다.
• 지연 시간: 버튼이 늦게 반응하여 사용자가 다시 클릭합니다.
• 신뢰도: 데이터가 오래된 것처럼 보인다. 사용자가 동기화가 성공했는지 의심합니다.
• 사용자 탈출: 온보딩이 완료되지만 사용자가 제품의 핵심 가치에 도달하지 못합니다.

실용적인 규칙: 사용자가 앱을 “클UNKY”라고 묘사할 때, 그들은 일반적으로 작은 엔지니어링 및 제품 결정의 연쇄를 보고하는 것이 아니라 단일 시각 디자인 문제를 보고하는 것입니다.

팀이 기능 로드맵에 익숙한 경우, UX feedback이 실패한 테스트 케이스보다 더 복잡하게 느껴질 수 있습니다. 그러나 UX를 시스템으로 다루면 여전히 관리할 수 있습니다. 첫 번째 세션의 행동, 오류 상태, 로딩 시간, 업데이트 수락, 작업 완료를 보는 대신 인터페이스가 “최신”하다고 묻지 않습니다.

이것이 엔지니어링에 있는 이유

다중 플랫폼 제품에서 UX 문제의 가장 큰 영향을 미치는 문제는 구현 세부 사항에서 오릅니다. 캐시 무효화가 데이터가 신뢰할 수 있는지 여부를 결정합니다. 번들 크기가 상호 작용 시간에 영향을 미칩니다. 상태 지속성이 사용자가 앱을 다시 열었을 때 방향감을 느끼는지 여부를 결정합니다. 업데이트 전달이 현장에서 마찰이 사라지는 속도에 영향을 미칩니다.

따라서 성숙한 팀은 제품, 디자인, QA, 엔지니어링 간의 공유 작업으로 앱 사용자 경험을 다룹니다. 디자이너는 흐름을 형성합니다. 제품은 결과를 우선합니다. 엔지니어는 실제 조건에서 경험의 속도, 안정성, 회복 가능성을 결정합니다.

If the app works only when everything goes right, users will still call it broken.

The Four Pillars of Modern App User Experience

The simplest way to keep UX from becoming vague is to split it into four pillars: 사용성, 성능, 신뢰성, 가치. If one is weak, users feel it even when the others are strong.

사용성은 사용자가 다음 단계를 알 수 있는지 여부입니다.

사용성은 사용자가 다음 단계를 알 수 있는지 여부와 오류를 복구할 수 있는지 여부를 나타냅니다. 이에는 네비게이션 레이블, 컨트롤 배치, 폼 동작, 빈 상태, 앱이 플랫폼 기대치를 존중하는지 여부가 포함됩니다.

In a Capacitor app, poor usability often shows up when teams copy a web interaction into mobile without adapting it. Hover assumptions don’t exist. Dense settings pages become exhausting. Tap targets feel cramped. A modal stack that seems fine on desktop becomes disorienting on a phone.

좋은 사용성은 화려하지 않습니다. 그것은 마찰의 부재입니다.

성능과 신뢰성이 신뢰를 형성합니다.

성능은 앱이 반응이 빠른지 여부를 나타냅니다. 신뢰성은 앱이 예측할 수 있는지 여부를 나타냅니다. 사용자는 그 두 개념을 구분하기 어렵습니다. 그들은 단지 앱에 신뢰를 느끼는지 여부를 알 뿐입니다.

A screen that appears instantly but fails during sync is still a bad experience. A stable app that takes too long to become interactive also loses people. This is why session-level analysis matters. In its article on UX score, Dynatrace describes a model that classifies each session as Satisfying, Frustrating, or Tolerable by combining performance analysis and error detection into one metric. That’s a useful mindset for developers because average page speed won’t tell you which journeys felt broken.

For Electron teams, this often means watching startup behavior, memory pressure, and renderer responsiveness. For Capacitor teams, it means paying attention to launch sequence, bridge calls, and whether network-dependent screens degrade gracefully.

Capgo

teams, it means paying attention to launch sequence, bridge calls, and whether network-dependent screens degrade gracefully.

A user doesn’t experience your architecture diagram. They experience one session at a time.

Value is the reason people come back

An app can be usable, fast, and stable but still underperform if it delays the moment when users get what they came for. Value is the outcome layer. Did the user complete the task, solve the problem, or reach the benefit that justified opening the app?

네 가지 기둥은 팀의 대화에 기반을 두고 있습니다. 'UX가 개선이 필요합니다'라고 말하는 대신, 온보딩 경로가 이해가 가지만 너무 느리거나, 기능이 가치가 있지만 약한 네트워크에서 불안정한 경우를 말할 수 있습니다. 그 정도에서 팀이 앱 사용자 경험을 개선할 수 있습니다.

앱 사용자 경험을 측정하는 방법: 실행 가능한 지표

UX 문제를 가장 빠르게 놓치게 하는 방법은 설치 횟수와 광범위한 참여 총계를 측정하지 않고 마찰을 측정하지 않는 것입니다. 다운로드는 사용자가 막혔는지, 지루해졌는지, 또는 가치에 도달하기 전에 떠났는지 알려주지 않습니다.

크로스 플랫폼 앱의 경우, 기술적 행동과 사용자 결과를 연결하는 지표가 가장 유용합니다. 사용자가 느끼는 불편함이 충돌, 멈춤, 혼란스러운 온보딩, 또는 업데이트 간격으로 인해 발생하는지 알고 싶습니다.

마찰을 측정하기 전에 규모를 측정하라

실제 사용 중의 고통을 드러내는 신호를 시작하세요. '중요한 모바일 앱 분석 지표'에 대한 안내서에서, UXCam은 충돌이 없는 사용자 비율목표로 100%를 설정하세요 __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ 99% 일일 이상, UI 멈춤 정의는 2 초 이상, 그리고 rage 탭 정의는 1 초에 4 초 이상 같은 요소에 대해. 같은 지침은 사용자가 첫 번째 세션에서 60 초 이내에 활성화 이벤트에 도달하는 사용자가 첫 번째 세션에서 더 높은 비율로 유지한다.

이러한 지표는 사용자가 느끼는 것과 직접 연결되기 때문에 특히 유용하다.

• Crash-free 사용자 비율 __CAPGO_KEEP_0__에서 불안정성이 광범위하거나 고립된지 여부를 알려줍니다.
• UI 멈춤 사용자가 앱이 더 이상 듣지 않는다고 생각하는 순간을 드러냅니다.
• rage 탭 응답이 명확하지 않지만 사용자에게 나타나는 컨트롤을 드러냅니다.
• 첫 번째 실제 이익에 도달하는 데 걸리는 시간 사용자가 첫 번째 실제 이익에 도달하는 속도에 대한 정보를 제공합니다.

인스트루먼테이션을 구현하는 팀에게는 __CAPGO_KEEP_0__ 앱에 성능 모니터링을 설정하고 첫 번째 세션 이벤트를 제품 및 엔지니어링 모두에게 표시하는 것이 실용적인 시작점입니다. 첫 번째 세션 이벤트를 제품 및 엔지니어링 모두에게 표시하기 위해 Capacitor 앱에 성능 모니터링을 설정하는 것이 실용적인 시작점입니다. 제품 및 엔지니어링을 위한 실용적인 지표 세트

__CAPGO_KEEP_0__ 앱에 성능 모니터링을 설정하고 첫 번째 세션 이벤트를 제품 및 엔지니어링 모두에게 표시하는 것이 실용적인 시작점입니다.

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

Cross-platform 제품의 경우, 기본적인 것들이 더 자주 승리합니다. 사용자가 느낄 수 있는 속도. 발생하는 일에 대한 설명이 되는 feedback. 네트워크가 좋지 않아도 살아남는 flow. 기기에서 실행 중인 convention을 존중하는 interface.

느낌 속도는 먼저 고쳐야 합니다.

느낌 속도는 엔지니어링이 앱을 다시 작성하지 않고도 UX에서 큰 이익을 얻을 수 있는 곳입니다. 사용자는 모든 바이트가 즉시 로드되지 않아도 됩니다. 앱이 준비가 되었고, 반응적이고, 사용자의 목표로 향하고 있는지에 대한 빠른 증거가 필요합니다.

그것은 일반적으로 다음과 같은 것을 의미합니다.

• 즉시 feedback을 보여주세요. 버튼은 탭한 즉시 상태를 변경해야 합니다. 작업이 시작되면 알려주세요.
• 스켈레톤을 신중하게 사용하세요. 스켈레톤은 최종 레이아웃이 예측 가능할 때만 효과적입니다. 스크린을 숨기는 불가피한 백엔드 지연을 숨기지 않는다면 도움이되지 않습니다.
• 비중요한 작업을 미루세요. 분석 초기화, 두 번째 요청, 그리고 낮은 우선순위 자산은 첫 번째 유용한 화면을 막지 않도록 해야 합니다.
• 자산의 무게를 줄이세요. Cross-platform 팀은 종종 oversized 이미지를, 글꼴, 및 front-end 의존성을 더 오래 동안 인식하지 못합니다.

나중에, 스테이크 홀더 또는 앱 스토어 리뷰어에게 변경 사항을 설명할 때 고품질의 제품 데모를 만들면 UX 개선 사항을 스크린샷으로는 종종 할 수 없는 방식으로 보이게 해줍니다.

더 깊은 시각적인_walkthrough는 팀이 실제로 “빠르면 충분하다”라는 것이 어떤 의미인지에 대해 일치할 수 있도록 도와줍니다.

weak 네트워크와 불균형한 장치에 대한 디자인

UX 조언의 많은 부분은 안정적인 연결성과 최신 하드웨어를 가정합니다. Real 사용자는 그 세계에 살지 않습니다. Prototypr의 piece에 대해 잊혀진 모바일 사용성 문제 poor 네트워크, expensive 데이터, 또는 no 네트워크와 같은 상황에서 앱이 어떻게 작동하는지에 대한 묵인된 질문을 호출합니다. 그게 특히 Capacitor 팀에게 중요합니다. broad 모바일 사용자에게 배포하는 것입니다.

실용적인 내결함성 패턴에는 포함됩니다.

• Cache the last useful state: If fresh data가 없다면, clear 상태와 함께 마지막으로 알려진 좋은 데이터를 보여줍니다.
• Queue user intent: offline 작업이 저장되고 나중에 sync 될 때 적절한 행동을 보존하십시오.
• sync 상태를 단순하게 설명하십시오. ‘로컬 저장’과 ‘sync 대기 중’은 사용자 불안을 줄이는 데 더 효과적입니다.
• 네트워크 트래픽을 줄이십시오. 가능한 경우 요청을 batch 처리하고 작은 액션 후 전체 화면 리로드 패턴을 피하십시오.

iOS, Android, 및 공유 웹层에서 더 잘 번역되는 UI 세부 사항을 검토하는 것은 __CAPGO_KEEP_0__ 앱에 가치가 있습니다. cross-platform UI and UX practices for Capacitor apps.

적절한 곳에서 상호 작용 패턴을 단조로 하십시오.

이것은 반대편입니다. 훌륭한 앱 사용자 경험은 항상 새로운 것에서 오지 않는다는 것입니다. 종종 제한에서 오는 것입니다.

네비게이션은 플랫폼에 맞춰야 합니다. 강력한 이유가 없다면. 뒤로 가기 동작은 예측 가능해야 합니다. 데스크톱 창은 깨끗하게 복원되어야 합니다. 확인 패턴은 위험한 액션에만 마찰을 줄여야 합니다. 일상적인 액션에는 그렇지 않아야 합니다.

]} Note that the translation is based on the provided source text and may not be perfect or suitable for all audiences. It's always a good idea to have a native speaker review the translation for accuracy and cultural relevance. Also, note that the placeholder __CAPGO_KEEP_0__ is copied exactly as written. It will be restored after translation. The translation is in the target language Korean. The protected tokens are not translated. The order of the translations is the same as the order of the input texts. The translations are in an array of strings. The JSON object has exactly one key named

Capacitor와 Electron을 사용하면 code를 쉽게 공유할 수 있습니다. 그러나 사용자 경험을 개선하는 데 있어 컨텍스트를 존중하는 것이 여전히 중요합니다. 사용자는 모바일과 데스크톱이 각각의 본연의 성격을 유지하는 것처럼 행동하는 것을 기대합니다. 그러나 그들은 중간 플랫폼의 조합으로 인해 혼합된 성격을 보이는 것이 아닙니다.

정확한 업데이트: 사용자 경험의 지속적인 개선에 중요한 역할

사용자 경험을 개선하는 것은 디자인 프로젝트가 끝나는 줄 알기 때문에 완료하는 프로젝트가 아닙니다. 그것은 릴리스의 규칙입니다. 사용자는 마찰을 측정하고 수정을 배포하고 관찰하고 반복합니다.

사용자 경험을 개선하는 데 있어 반복적인 업데이트가 중요한 이유

사용자 경험을 개선하는 데 있어 반복적인 업데이트가 중요한 이유

사용자 경험을 개선하는 데 있어 반복적인 업데이트가 중요한 이유

사용자 경험을 개선하는 데 있어 반복적인 업데이트가 중요한 이유 사용자 경험을 개선하는 데 있어 반복적인 업데이트가 중요한 이유 사용자 경험을 개선하는 데 있어 반복적인 업데이트가 중요한 이유 사용자 경험을 개선하는 데 있어 반복적인 업데이트가 중요한 이유 As성공의 주요 지표로 간주합니다. 그 프레임은 배송량에 대한 주의를 돌리기보다는 사용자 경험에 개선이 도달하는지 여부에 초점을 맞추게 합니다.

신뢰할 수 있는 업데이트가 그 일부입니다. 만약 사용자 중 절반만 최신 웹 번들을 사용한다면, 메트릭은 흐려집니다. 제품의 동작이 혼합되며, 지원 팀은 왜 일부 사용자가 해결된 이슈를 다시 만나는지 설명할 수 없습니다. 엔지니어 팀은 릴리스의 영향에 자신감을 잃습니다.

릴리스 제어를 UX 워크플로우의 일부로 사용하세요.

배포 메커니즘을 앱 사용자 경험 자체로 다루는 것이 더 나은 패턴입니다.

그것은 다음과 같은 것들을 포함합니다.

• 좁은 범위로 배포하세요: 내부 사용자, 베타 그룹, 또는 정의된 세그먼트에 UX 변경을 전송하세요. 그리고 넓은 릴리스 전에.
• 수용과 실패를 관찰하세요: 업데이트한 장치, 실패한 장치, 롤백한 장치에 대한 시각성을 필요로합니다.
• 릴리스 그룹을 동작과 연결하세요: 첫 번째 세션 활성화, 파이프라인 완료, 또는 좌절 신호를 이전과 이후에 비교하세요.
• 빠른 롤백 경로를 보존하세요. UX 실험은 여전히 프로덕션 변경 사항입니다. 새로운 흐름이 사용자들을 혼란스럽게 하면, 그것을 швидко 되돌려야 합니다.

Capacitor 생태계에서 작업하는 팀에게, Capacitor가 어떻게 작동하는지 설명하는 서비스가 필요합니다. Capacitor의 live 업데이트에 대한 설명 이 릴리스 루프를 운영하기가 더 쉬워질 수 있습니다. 그 중 하나는 __CAPGO_KEEP_0__ , 이라는 옵션입니다. Capgo는 웹 번들을 signed 상태로 대상 채널로 전달하고, Capgo와 Electron 앱에 대한 업데이트 적용, 롤백, 관찰 가능성 기능을 제공합니다. UX 변경 사항이 웹层에 존재하고, 완전한 스토어 사이클을 기다리지 않고 제어된 반복이 필요한 경우 유용합니다., which delivers signed web bundles to targeted channels for Capacitor and Electron apps, applies updates on next launch, and provides rollback and observability features. That’s useful when the UX change lives in the web layer and you need controlled iteration without waiting on a full store cycle.

강력한 관찰 가능성과 업데이트 신뢰성이 만난다. 최고의 UX 팀은 단순히 마찰을 식별하는 것이 아니라, 그 차이를 명확하게 측정할 수 있는 동안 그것을 제거합니다.

모든 것을 합치자. 첫 번째 UX 개선 주기

많은 팀은 UX 개선이 필요하지 않습니다. 그들은 단 하나의 단단한 주기를 증명할 수 있는 프로세스를 필요로 합니다.

사용자가 자주 방문하는 첫 번째 여행을 시작하세요. 첫 번째 런칭, 온보딩, 로그인, 검색, 체크아웃, 양식 완료, 또는 진행 중인 작업으로 돌아가는 것은 모두 좋은 후보입니다. 사용자가 가치에 도달할 수 있는지 여부에 직접적으로 영향을 미치는 것을 선택하세요.

하나의 여행을 시작하세요, 전체 앱이 아닌.

__CAPGO_KEEP_0__

A practical first pass looks like this:

1. 한 가지 결과 지표를 선택하세요: 첫 번째 의미 있는 액션에 도달하는 데 걸리는 시간은 많은 앱에 대해 강력한 후보입니다.
2. 해당 흐름 주변의 마찰 신호를 검토하세요: 추락, 멈춤, 반복적인 탭, 혼란스러운 루프, 그리고 포기하는 지점을 찾으세요.
3. 한 가지 좁은 개선 사항을 정의하세요: 시작 시간을 줄이거나, 한 화면을 명확히 하거나, 한 개의 차단 단계를 제거하거나, 한 개의 액션을 오프라인으로 처리하는 방법을 개선하세요.
4. 한정된 사용자 집단에 배포하세요: 폭파 반경을 작게 유지하여 안전하게 학습할 수 있도록 하세요.
5. 배포 후 행동을 비교하세요: 더 깨끗한 경로 완료와 더 적은 좌절 지표를 찾으세요.

이것은 discipline을 강요합니다. 팀은 UX에 대한 추상적인 토론을 멈추고 특정 구현이 특정 사용자 여행을 개선했는지 테스트하기 시작합니다.

빠른 학습을 위해 작은 사이클을 실행하세요

사이클을 너무 재미있게 만들지 마세요. 큰 리디자인으로 시작하지 마세요. 그러면 변수가 너무 많아져서 어떤 것이 도움이 되었는지 알기 어려울 것입니다.

대신 한 번에 하나의 경로를 개선하고 증거에 기반한 습관을 공유하세요. 제품은 어떤 지표가 중요하다는 것을 알고 있어야 합니다. 엔지니어는 성공을 표시하는 이벤트를 알고 있어야 합니다. 지원 팀은 어떤 것이 변경되었는지 알고 있어야 하며 업데이트가 일치하지 않는 것을 식별하는 방법을 알고 있어야 합니다. 새로운 워크플로우 또는 기능과 관련된 릴리즈 커뮤니케이션을 조정하고 있으면, 구조화된 새로운 제품 소개 플레이북 팀이 메시징, 롤아웃 예상, 내부 준비를 일치시키는데 도움이 될 수 있습니다.

좋은 앱 사용자 경험은 이러한 방식으로 emerges합니다. 단일 бли언트 리디자인에서 아니라, 많은 측정된 수정으로 의심을 제거하고 신뢰를 회복하고 사용자가 더 빠르게 가치 있는 것을 얻을 수 있도록 합니다.

Capacitor 또는 Electron 앱을 배포하고 있으며 UX를 프로덕션에서 안전하게 반복하고 싶다면 Capgo 을 평가하는 것이 좋습니다. 팀은 웹层 수정, 복사 변경, 구성 업데이트 및 자산을 빠르게 롤아웃하고 롤백 보호 및 릴리즈 시각화를 제공하여 지속적인 UX 개선이 더 쉽게 관리될 수 있도록 합니다.

App User Experience: Capacitor & Electron 팀을 위한 안내서

만약 __CAPGO_KEEP_0__ App User Experience: A Guide for Capacitor & Electron Teams native 플러그인 작업을 계획하기 위해, 그것을 연결하세요. Capgo 플러그인 디렉토리 Capgo 플러그인 디렉토리 내의 제품 워크플로우 Capacitor 플러그인들에 의해 Capgo Capacitor 플러그인들에 의해 Capgo의 구현 세부 사항 플러그인을 추가하거나 업데이트 플러그인을 추가하거나 업데이트 하는 구현 세부 사항 Ionic Enterprise 플러그인 대체 Ionic Enterprise 플러그인 대체의 제품 워크플로우 Capgo 네이티브 빌드 Capgo 네이티브 빌드의 제품 워크플로우