모바일 개발 하이브리드

당신의 팀은 현재 iOS와 Android를 위한 앱을 출시해야 하는 상황일 수 있습니다. 그러나 두 개의 별개의 네이티브 팀을雇용하는 것은 비용이 많이 들 것입니다. 또는 이미 하이브리드 앱을 출시했으며, 실제 작업은 첫 번째 릴리즈 이후에 시작된다는 것을 발견했습니다.

That’s where most advice on mobile development hybrid falls short. It focuses on framework selection and ignores the harder questions: how the architecture behaves under load, where performance problems come from, how to test the bridge between web and native code, and how to ship post-launch fixes without turning every small change into a store-review event.

하이브리드 개발은 전략적으로 올바른 선택일 수 있지만, '웹 앱만.wrap'처럼 다루면 유지 보수陷阱이 될 수 있습니다. 일반적으로 아키텍처-discipline, UI 선택, 플러그인 관리, 업데이트 전략이 다릅니다.

목차

• 하이브리드 모바일 개발의 딜레마
• 하이브리드 앱이 어떻게 작동하는가
  • 네이티브 셸과 WebView
  • 능력은 브릿지에서 살아있다
• 프레임워크를 선택하는 방법: 하이브리드 생태계
  • WebView 기반 하이브리드 프레임워크
  • 네이티브 렌더링 대안
  • 실무에서 프레임워크를 필터링하는 방법
• 하이브리드가 강력한 적합성
  • 하이브리드 앱의 장단점
  • 팀이 불타는 곳에서
• 성능, 보안 및 테스트 최적화 방법
  • 실질적인 성능 작업
  • 하이브리드 아키텍처의 보안 규칙
  • 실제 현실을 반영하는 테스트 스택
• 빌드 외의 CI/CD 및 실시간 업데이트
  • 완벽한 하이브리드 배포 PIPELINE
  • 실시간 업데이트가 운영을 어떻게 바꾸는지
• 기업 전략을 위한 마이그레이션 및 확장
  • 마이그레이션의 의미
  • 통제를 잃지 않고 확장하는 방법

하이브리드 모바일 개발의 딜레마

대부분의 회사는 하이브리드 기술을 선택하는 이유가 트렌디한 이유가 아니라 비용, 속도, 인력 부족으로 인한 유지보수 비용 때문입니다. 제품 로드맵이 이미 꽉 차 있다면, 두 개의 구현 표면을 더하는 것은 제품 가치보다 조직의 부담을 더 증가시킬 수 있습니다.

이러한 이유로 하이브리드 모바일 개발이 제품 및 엔지니어링 리더의 관심을 받고 있습니다. 웹 기술을 사용하여 빌드하고 논리 재사용, 플랫폼 간에 공유 코드베이스에서 배포할 수 있는 방법을 제공합니다. 자바스크립트나 프론트엔드에 대한 깊은 지식이 있는 팀에게는 신뢰할 수 있는 모바일 존재로 빠른 경로를 제공합니다.

그러나 하이브리드는 무료로 사용할 수 있는 단축키가 아닙니다. 복잡성을 옮기는 대신 제거하지 않습니다. 중복된 UI와 비즈니스 논리를 절약하지만, WebView, 네이티브 플러그인, 성능 예산, 릴리스 PIPELINE, 모바일 특정 UX와 같은 아키텍처 결정에 부담을 가집니다. 이러한 상호 작용을 무시하는 팀은 일반적으로 잘못된 질문에 대해 논의하는 대신 앱의 실제 요구 사항이 모델에 맞는지 여부를 묻는 대신, 네이티브 versus 하이브리드에 대한 질문에 집중합니다.

유용한 시작점은 비즈니스 용어로 보다 광범위한 네이티브 versus 하이브리드 의사결정을 프레임하는 모바일 앱 개발 비교입니다. 공유 __CAPGO_KEEP_0__ 접근 방식에 대한 평가를 더 광범위하게 할 경우, 렌더링 모델이 다른 경우에도 하이브리드와 크로스 플랫폼 용어를 혼용하는 팀이 많기 때문에 이 크로스 플랫폼 모바일 앱 개발 가이드 that frames the broader native versus hybrid decision in business terms, not just technical preferences. If you’re evaluating shared-code approaches more broadly, this 비용, 속도, 인력 부족으로 인한 유지보수 비용 때문입니다. 웹 기술을 사용하여 빌드하고 논리 재사용, 플랫폼 간에 공유 코드베이스에서 배포할 수 있는 방법을 제공합니다. 자바스크립트나 프론트엔드에 대한 깊은 지식이 있는 팀에게는 신뢰할 수 있는 모바일 존재로 빠른 경로를 제공합니다.

실용적인 규칙: 공유 배포 속도가 절대 렌더링 성능보다 더 중요하고 사용자 경험에 영향을 주지 않는 플랫폼 추상화가 허용되는 경우에 하이브리드 앱을 선택하세요.

하이브리드 앱의 내부 작동 방식

하이브리드 앱은 웹 앱이 네이티브 앱 셸 내부에서 실행되는 것으로 이해하기 가장 쉬운 것입니다. 사용자는 앱 스토어나 플레이 스토어에서 다른 모바일 앱과 같이 설치하지만, 사용자가 보는 대부분은 네이티브 UI 컴포넌트 대신 임베디드 브라우저 기술로 렌더링됩니다.하이브리드 앱 아키텍처의 다섯 층을 나타내는 다이어그램.

위쪽에 있는 네이티브 셸

이는 플랫폼 특정 컨테이너로 앱을 패키징하고, 설치를 처리하고, 앱 라이프 사이클 이벤트에 참여하며, 운영 체제 기능에 대한 접근을 노출합니다. 그 안에 WebView가 있습니다.이 WebView는 웹 페이지를 렌더링하고 사용자와 상호 작용하는 데 사용됩니다.

그 아래에 있는 네이티브 UI 컴포넌트는 WebView의 렌더링 결과를 사용하여 사용자 인터페이스를 구성합니다. 웹뷰. iOS에서는 WKWebView, 안드로이드에서는 WebView를 사용합니다. 앱의 인터페이스는 HTML, CSS, JavaScript를 사용하여 그려지며, SwiftUI, UIKit, Jetpack Compose, 또는 classic Android views를 사용하지 않습니다.

그 아키텍처는 하이브리드 개발의 정의적 특징입니다. Ionic은 다음과 같이 설명합니다: 하이브리드 모바일 개발은 HTML5, CSS, JavaScript를 사용하여 HTML5, CSS, JavaScript 내부에 작성된 핵심 논리를 감싸고, WKWebView를 iOS에서, WebView를 안드로이드에서 사용하는 브라우저 엔진을 사용하여 인터페이스를 렌더링합니다. 이 모델은 복잡한 애니메이션과 고주파 처리를 위해 브라우저 런타임이 병목 현상을 일으킬 수 있습니다. 성능 지연과 애니메이션 지연을 유발할 수 있습니다. ( Ionic의 하이브리드 앱 개발 개요기능 구현에 대한 더 자세한 설명을 원하는 팀이 __CAPGO_KEEP_0__가 웹 __CAPGO_KEEP_0__이 장치 기능과 어떻게 통신하는지에 대한_walkthrough__를 참조하세요.).

__CAPGO_KEEP_1__와 웹 code를 연결하는 방법에 대한_walkthrough__ how Capacitor bridges web and native code 기술적인 동반자로 좋은 선택입니다.

시각적인 설명이 짧고 간결한 경우, 제품, 엔지니어링, 디자인 팀이 동일한 정신 모델을 공유할 수 있습니다.

능력의 다리입니다.

2차 비판적 층은 네이티브 브리지 또는 플러그인 층입니다. 이 층은 자바스크립트가 운영 체제에 네이티브 작업을 요청할 수 있도록 합니다. 카메라 접근, 위치 정보, 생체 인식, 파일 시스템 접근, 푸시 등록, 및 같은 장치 기능은 WebView만으로는 제공되지 않습니다. 이 기능들은 네이티브 API를 웹 층에 노출시켜주는 플러그인이 제공합니다.

실제로 사용자는 웹 UI의 버튼을 탭합니다. 자바스크립트는 네이티브 code로 호출을 보내고, 네이티브 code는 플랫폼 API와 통신하고, 결과를 자바스크립트 층으로 반환합니다. 이 반복적인 과정은 플러그인 품질이 중요하기 때문입니다. 다리 설계가 나쁘거나 instable하거나 유지 관리가 부족한 경우, 앱은 frontend code가 깨끗하더라도 느슨한 느낌을 줄 수 있습니다.

다리와 같은 제품 경계를 다루세요. 편의 층이 아닌. 버전을 신중히 관리하고, 계약을 문서화하고, 각 기능 팀이 네이티브 추상화를 독자적으로 만들지 않도록 하세요.

이것도 '웹사이트를 재사용하라'는 일반적인 방법이 실패하는 이유입니다. 모바일 사용자는 일반적인 웹 앱이 잘 처리하지 못하는 라이프 사이클 관리, 오프라인 동작, 네비게이션 패턴, 키보드 동작, 안전 영역 지원, 반응형 터치 인터랙션을 기대합니다. 하이브리드 앱은 웹 층이 모바일을 위해 설계된 경우에만 매끄럽게 느껴질 수 있습니다.

프레임워크 선택: 하이브리드 생태계

모바일 개발의 하이브리드(Hybrid) 이코시스템은 혼란스럽게 보인다. 사람들이 종종 실제 하이브리드 프레임워크를 크로스 플랫폼 네이티브 렌더링 프레임워크와 함께 묶는다. 그들은 관련된 비즈니스 문제를 해결하지만 UI를 동일한 방식으로 렌더링하지 않고 동일한 장소에서 실패하지 않는다.

웹뷰 기반 하이브리드 프레임워크

strict sense에서 mobile development hybrid을 의미한다면, core stack은 일반적으로 Capacitor.

Capacitor Cordova

__CAPGO_KEEP_0__ 페이지: Live updates product page. 역할: Section or page heading. Seen in: page live-update.astro. Capgo 제품/브랜드 및 개발자 용어를 정확하게 유지하십시오. 메시지 키 `live_update_platform_capacitor_title` (Live Update Platform Capacitor Title).

Cordova Cordova는 역사적으로도 그리고 유산 부지에 대해 중요합니다. 기업 앱이 Cordova 플러그인에 의존하거나 Cordova 시대에 상속된 빌드 가정에 의존하는 것을 발견할 수 있습니다. 그러나 새로운 팀에 대한 조언을 받는다면, 일반적으로 Cordova를 대상으로 하지 않고 대신 이주하는 것으로 프레임합니다.

자연스럽게 렌더링하는 대안

그런 다음 React Native 그리고 Flutter. 이들은 동일한 구매 대화에서 나타날 때 종종 중복 플랫폼 작업을 줄여줍니다. 그러나 WebView의 의미에서混合형이 아닙니다.

React Native는 네이티브 UI 추상화를 통해 렌더링합니다. Flutter는自己的 렌더링 모델을 사용합니다. 두 가지 모두 UI가 많은 제품에 강력한 동작 성능과 플랫폼 감각을 제공할 수 있지만, 두 가지 모두 자신의 생태계 제약, 플러그인 결정 및 플랫폼 특정 탈출구와 함께 오는 제약이 있습니다.

만약 스태커가 이러한 옵션을 비교한다면, 이 React Native의 is useful because it highlights the practical trade-offs teams run into after the initial excitement of code sharing wears off. For a more direct framing of a common enterprise decision, this comparison of React Native vs Capacitor 웹뷰 모델과 네이티브 렌더링 접근 방식의 차이점을 명확히 해줍니다.

실무에서 프레임워크를 선정하는 방법

나는 인기순서로 시작하지 않습니다. 나는 렌더링 요구 사항, 플러그인 위험, 팀 구성에 따라 시작합니다.

빠르게 선택을 좁히는 몇 가지 질문이 있습니다:

• 이 앱은 정말 어떤 종류의 앱인지? 워크플로우 앱, 카탈로그, field 서비스 도구, 예약 흐름 및 내부 운영 앱은 종종 하이브리드가 잘 맞습니다. 게임과 같은 인터페이스 또는 고도로 애니메이션된 소셜 제품은 일반적으로 네이티브 렌더링 프레임워크 또는 네이티브 code 방향으로 나를 밀어냅니다.
• 이미 어떤 재능이 있습니까? 강력한 웹 팀은 Capacitor 및 Ionic에서 더 빠르게 생산성을 높일 수 있습니다. 네이티브 모바일 깊이를 처음부터 구축해야 하는 팀보다.
• 네이티브 표면의 얼마나 많은 부분이 필요합니까? 로드맵이 커스텀 센서, 고급 미디어 PIPELINE, 배경 실행 또는 일반 OS 통합에 의존하는 경우, 플러그인 성숙도를 더 신중하게 평가해야 합니다.
• 이 앱은 얼마 동안 살아남을까요? 단기적인 MVP는 약간의 단점을 감수할 수 있지만, 유지보수 기간이 길고 규제가 있는 기업 앱은 더 깨끗한 관리, 업데이트 전략 및 플러그인 소유권이 필요합니다.

프레임워크 자체가 실제 위험은 드물지만, 약한 릴리스 규율, 불분명한 플러그인 소유권 및 데스크톱 웹에서 복사한 UI 결정이 일반적으로 하이브리드 프로그램을 침몰시킵니다.

하이브리드 앱 개발의 장단점

하이브리드 앱 개발은 공유 배포가 경제적으로 유리할 때 잘 작동하지만, 플랫폼에 특화된 성능 또는 매우 정교한 네이티브 인터랙션 패턴에 의존하는 앱의 가치가 있을 때는 어려울 수 있습니다.

하이브리드가 강력한 매치인 경우

많은 비즈니스 앱의 가장 큰 장점은 간단합니다: 한 코드베이스와 한 주요 기술 세트. 웹 지향 팀은 두 플랫폼 모두에 대해 빌드, 유지보수 및 반복적으로 개선할 수 있습니다. 각 기능을 두 개의 별개의 implementation으로 나누지 않습니다.

그것은 다음 제품에 잘 작동하는 경향이 있습니다:

• 운영 앱 모바일 앱 개발을 위한 전략적인 선택
• 내용이 많은 앱 폼, 대시보드, 목록, 계정 워크플로우가 주도하는 앱
• 상업 및 서비스 앱 신뢰성과 릴리즈 속도가 중요하지만 과장된 애니메이션 시스템보다
• 프로토 타입 및 MVP 워크플로우를 검증하는 것이 네이티브 충실도 최대화보다 중요할 때

전략적인 이점은 초기 속도만이 아닙니다. 그것은 또한 지속적인 일관성입니다. 공유된 비즈니스 로직, 통일된 디자인 시스템, 단일 릴리즈 트레인은 iOS와 Android 사이의 시간이 지남에 따라 드리프트를 줄입니다.

팀이 불타는 곳

하이브리드가 네이티브와 같은 모든 시나리오에서 동작하는 것으로 기대하는 것은 잘못된 생각입니다.

일반적인 실패 모드는 다음과 같습니다.

• 성능 기대치가 현실과 다릅니다. 브라우저 기반 렌더링의 한계를 드러내는 복잡한 제스처, 고주파 시각 업데이트 및 그래픽이 많은 화면입니다.
• 모바일을 위한 UI가 설계되지 않았습니다. 팀은 반응형 웹 앱을 쉘에 넣고 끝내라고 합니다. 사용자는 즉시 알아차립니다.
• 플러그인 의존성이 아키텍처적 부채가 됩니다. 지원되지 않는 한 플러그인이 OS 업데이트를 막거나 주요 기능 릴리스를 막을 수 있습니다.
• 디버깅은 층을 넘어갑니다. 일부 버그는 자바스크립트에서, 일부는 code에서, 일부는 그 사이의 브릿지에서 살고 있습니다.

하이브리드는 기본적으로 compromis가 아닙니다. 제품이 하나의 것을 필요로하고 아키텍처가 다른 것을 최적화할 때 compromis가 됩니다.

나는 일반적으로 이 지침을 기업 팀에게 제공합니다: 사용자가 업무를 완료하거나 정보를 소비하거나 비즈니스 워크플로를 이동하는 앱의 핵심 기능이면, 하이브리드는 종종 실용적인 선택입니다. 앱의 핵심 기능이 감동을 통해 운동, 실시간 강력한 상호 작용, 또는 고급 그래픽을 통해 이루어지면, 하이브리드는 일반적으로 중력의 중심이 아닙니다.

성능, 보안 및 테스트 최적화 방법

하이브리드 앱이 웹 기술을 사용하기 때문에 실패하지 않는다. 그들은 웹 습관을 모바일 런타임으로 옮겨서 표준을 변경하지 않고 실패한다. 프로덕션급 하이브리드 엔지니어링에는 성능, 보안 및 테스트에 대한 명시적인 규칙이 필요하다.

실질적인 성능 개선 작업

대부분의 하이브리드 성능 문제는 스스로에게 가해지는 문제입니다. 거대한 번들, oversized 이미지, 과도한 리렌더링, 그리고 길게 렌더링된 목록은 WebView를 느리게 만들 것입니다.

기본적인 것에 초점을 맞춰보세요:

• 한 번에 렌더링하는 UI를 줄여보세요. 길게 렌더링되는 피드, 카탈로그 화면, 이벤트 로그와 같은 경우에는 가상 스크롤링 또는 목록 윈도우화를 사용하세요.
• 더 작은 번들을 배포하세요. code을 라우트 또는 기능별로 나누고, 시작 시간을 가볍게 유지하세요.
• 이미지 및 자산을 최적화하세요. 대형 미디어 파일은 시작 시간과 스크롤링 속도를 저하합니다.
• 애니메이션 선택을 최적화하세요. 스크린이 복잡한 움직임에 의존하여 좋게 느껴지면, 저전력 장치에서 테스트하세요.
• 실제 하드웨어에서 프로파일링하세요. 모바일 장애는 기기에서 다른 방식으로 나타납니다.

이 작업을 위한 유용한 체크리스트가 이 앱 성능 최적화에 있습니다. 특히 '제작이 완료되면'에서 '제작이 완료된 기기에서 안정적'으로 바꾸려는 팀에게 특히 추천합니다.

하이브리드 아키텍처의 보안 규칙

하이브리드 앱은 웹과 네이티브 세계의 위험을 모두继承합니다. 따라서 수송, 저장 및 브리지 통신에 대한 제어가 필요합니다.

몇 가지 필수적인 점이 있습니다:

• 브리지 호출을 특권된 연산으로 다루세요. 입력을 검증하고 JavaScript에 너무 광범위한 네이티브 함수를 노출하지 마세요.
• Sensitive 데이터를 신중하게 저장하세요. 인증 또는 규제 데이터와 같은 자격 증명에 대한 브라우저 스타일의 저장 선택을 가정하지 마세요.
• 웹层를 보호하세요. 웹뷰 내에서 XSS 및 안전하지 않은 콘텐츠 삽입은 여전히 심각한 문제입니다.
• 플러그인 인벤토리를 단단하게 유지하세요. 모든 플러그인이 공격 표면과 유지 관리 부담을 확대합니다.

보안 검토는 앱을 계층적 시스템으로 보는 것이 아니라 웹 프론트엔드만 wrapper로 감싸는 것만으로는 충분하지 않습니다.

실제 현실을 반영하는 테스트 스택

순수 웹 테스트만으로는 충분하지 않습니다. 순수 장치 테스트는 너무 느립니다. 올바른 답은 계층적 전략입니다.

사업 논리와 UI 동작에 대한 단위 테스트부터 시작하세요. 주요 사용자 경로에 대한 브라우저 기반 끝-to-end 커버리지도 추가하세요. 그런 다음 네이티브 동작이 가장 중요하다고 여겨지는 장소에서 목표된 장치 테스트를 실행하세요. 예를 들어, 권한, 카메라 흐름, 푸시 설정, 깊이 링크 및 파일 처리와 같은 곳입니다.

마지막 범주는 많은 하이브리드 팀이 과소 투자하는 곳입니다. 브라우저에서 앱이 보이기 좋지만 실제 장치에서 작동하지 않는 경우가 많습니다. 이는 브리지 계약, 라이프 사이클 동작, 또는 권한 흐름이 예상과 다르게 동작하기 때문입니다.

빌드 CI/CD 및 라이브 업데이트 이외의 것

하이브리드 앱은 스토어 목록이 공개되면 완성되지 않습니다. 기업 팀의 경우, 런칭 후 운영 모델이 빌드 자체만큼 중요합니다. 릴리즈 규율, 롤백 전략 및 업데이트 속도는 관리 가능한 하이브리드 자산과 스트레스를 유발하는 자산을 구분하는 것입니다.

solid hybrid delivery pipeline이란 무엇인가?

A형 CI/CD 설정은 일반적으로 다음 단계를 포함합니다:

1. 웹 빌드 및 검증
   웹 앱을 컴파일하고 테스트를 실행하고 환경 설정을 확인한 후 네이티브 패키징에 도달하기 전에

2. 네이티브 동기화 및 플랫폼 빌드
   웹 자산을 네이티브 프로젝트에 동기화하고 iOS 및 Android signed 아티팩트를 빌드하고 플러그인 통합을 검증합니다.

3. 채널 기반 배포
   내부 테스트, QA, 베타 그룹 또는 스테이지드 프로덕션 대상으로 빌드를 푸시한 후 넓은 릴리스 전

4. 릴리스 후 관찰성
   앱 버전별로 지원 및 엔지니어링이 신속하게 대응할 수 있도록 크래시, 브리지 실패, 플러그인 회귀 및 앱 채택을 추적합니다.

이 PIPELINE은 중요합니다. 하이브리드 앱은 두 개의 릴리스 표면을 가지고 있습니다: 앱 바이너리와 그 안에 있는 웹 번들. 그들을 하나의 통합된 것으로 다루면 릴리스 프로세스가 느려지게 됩니다.

라이브 업데이트가 운영을 변경하는 이유

이것은 많은 하이브리드 가이드가 거의 다루지 않는 부분입니다. 그러나 모델을 올바르게 사용할 때 lifecycle의 가장 강력한 이점 중 하나입니다.

기업 모바일 팀 중 28%가 App Store와 Play Store 리뷰 주기 때문에 중요 JS/CSS/config 수정을 배포하는 데 지연이 발생한다고 보고하고 있다. 리뷰는 평균 3일에서 7일까지 소요된다.에 따르면 이 하이브리드 앱 개발 분석에 따르면. 같은 출처는 독립적인 업데이트기를 지원하는 하이브리드 지침이 종종 무시한다고 언급한다. 이는 분당 수준의 롤아웃과 자동 롤백 보호를 제공한다..

이 문제는 이론적이지 않다. 프로덕션 버그가 JavaScript, 스타일링, config, 복사, 또는 다른 웹 전달 자산에 존재한다면, 전체 스토어 리뷰를 기다리는 것은 종종 불필요한 마찰이다.

실시간 업데이트 시스템을 사용하면 팀이:

• 웹层 결함을 빠르게 패치할 수 있다. 전체 앱 바이너리를 재빌드하고 다시 제출하지 않고
• 롤아웃 채널을 대상으로 한다. 따라서 베타 사용자, 지역, 또는 고객 세그먼트가 변경 사항을 선택적으로 받을 수 있다.
• 안전하게 롤백할 수 있다. 업데이트가 regressions을 introduct한다면
• 자연적인 릴리즈를 유지하기 자연적인 검토가 필요로 하는 변경사항에 집중하기

이 카테고리에서 하나의 옵션은 Capacitor의 live updates가 어떻게 작동하는지. 실제로, 플랫폼들처럼 Capgo은 signed web bundles를 Capacitor 앱에 전달하여 팀들이 JavaScript, CSS, copy, config, 및 assets를 표준 앱 스토어 리뷰 사이클 외에 업데이트할 수 있도록 해주며 rollback controls를 유지할 수 있도록 해줍니다.

포스트-런치 업데이트 전략이 없는 하이브리드 앱은 아키텍처를 완성하지 않은 것입니다. 첫 번째 배송만 완성한 것입니다.

중요한 경계는 governance입니다. Live updates는 channels, approvals, signing, observability, 및 rollback paths와 같은 제어된 릴리즈 시스템으로 다루어져야 합니다. 그것들은 엔지니어링 discipline을 bypass하는 이유가 아닙니다. 그것들은 discipline을 더 빠르게 적용하는 방법입니다.

기업용 전략: 마이그레이션 및 확장

대형 조직은 일반적으로 하이브리드에 도달하기 위해 두 가지 방향으로 접근합니다. 그들은 EITHER native 및 web 노력을 통합하거나 이미 하이브리드 앱이 있고 plugins, duplicated UI patterns, 및 불일치한 릴리즈 관행을 만들지 않고 확장하고 싶을 때입니다.

마이그레이션의 의미

마이그레이션을 하기 위한 상황은 다음과 같습니다. 비즈니스 로직이 이미 heavily shared되어 있고, workflows가 form-driven 또는 content-centric이고, 회사에서 더 많은 배포 경로를 소유하고 싶은 팀이 있을 때입니다.

기존 네이티브 앱이 플랫폼 상호 작용, 미디어 PIPELINE, 또는 성능-sensitive 인터페이스에서 우세할 때 더 이상 의미가 없어진다. 이 경우에 나는 보통 선택적인 전략 대신 전체 재작성 대신에 선택적인 전략을 추천한다. 워크플로우-heavy 표면을 하이브리드 층으로 옮기고 성능-critical 모듈을 네이티브로 유지한다.

이 원칙은 반대 방향으로도 작동한다. 성공적인 하이브리드 앱은 영원히 PURELY 하이브리드가 아니어도 될 필요가 없다. 많은 성숙한 팀은 애플리케이션의 bulk를 공유된 웹 층에 유지하고 CLEAR payoff가 있는 특정 네이티브 모듈을 분리한다.

성장하기 위해 제어를 잃지 않는 방법

기업 규모의 확장은 주로 관리 문제이다.

몇 가지 패턴이 잘 작동한다.

• 플러그인 승인 프로세스를 정의한다. 각 팀이 네이티브 의존성을 자유롭게 추가하지 않도록 한다.
• 공유된 컴포넌트 시스템을 유지한다. 모바일 웹 층이 심각한 프론트엔드 플랫폼과 같은 디자인 дисцип린이 필요하다.
• Separate platform code ownership clearly. someone이 iOS 빌드 건강, Android 빌드 건강, 브리지 안정성을 책임져야 한다.
• 릴리즈 정책을 표준화한다. 스토어 릴리스를 통해 전송할지, 라이브 업데이트 전송을 qualify하는지, 롤백을 승인하는 사람을 결정하세요.
• 교체 가능성을 위해 설계하세요. 하나의 기능이 하이브리드 제약을 초과한다면, 그 슬라이스를 재현할 수 있어야 합니다. 그 슬라이스는 앱의 나머지 부분을 다시 작성하지 않고.

강력한 기업 하이브리드 프로그램은 모두 네이티브 code를 피하기 위해 노력하는 것이 아닙니다. 그들은 하이브리드를 의도적으로 사용하고, 경계를 깨끗하게 유지하고, 네이티브 투자를 네이티브가 이를 이익을 제공하는 부분에 예약하는 것입니다.

팀이 Capacitor를 사용하여 빌드하고, 런타임 후 수정을 위한 제어된 방법으로 배포할 필요가 있다면 Capgo __CAPGO_KEEP_0__