네이티브 앱 패키징 아키텍처
1. 네이티브 컨테이너 + 단일 웹뷰
- 모바일 웹 채널을 운영하고 있고 빠르게 앱을 출시하기를 원할 경우 유용
- 최소한의 네이티브 개발은 필요
- 앱스토어(IOS) 규약 위반 가능성이 존재하므로 네이티브 기능 탑재 필수
ex.) 푸시, 카메라, 네이티브 인증(페이스 타임, 지문 인식 등)
2. 네이티브 + 멀티 웹뷰
- 웹뷰간 데이터 교환 방법 초기에 설계 필요
- 앱에 저장소를 만들고 웹뷰에게 인터페이스를 제공
3. 네이티브 + React Native
- 변화가 많은 화면은 RN으로 그외 화면은 네이티브로 개발
- 웹뷰 개발 시 존재할 수 있는 사용성 관련 이슈를 방지
- 역량 있는 네이티브 개발자 필요
네비게이션 룰
- 웹 페이지는 각각의 URL이 존재하지만 네이티브에서는 그렇지 않다
- Depth가 깊은 화면에 직접 접근할 수 있는 방법을 초기에 설계해야 함(Deep Link)
버전 관리
- 스토어에 배포된 버전의 앱은 사용자가 업데이트 하지 않는 이상 수정 불가
- 네이티브 이슈 발생으로 모든 사용자의 앱 버전을 강제로 업데이트 하기에는 어려움이 있다
공개 / 비공개 웹뷰 분리
- URL이 노출될 경우 보안상 문제가 생길 위험이 있는지 고려하여 웹뷰를 분리
개발 환경 구축
- 웹뷰 vs 브라우저, 시뮬레이터 vs 실기기의 차이점이 존재함을 인지
- 개발 단계에서 개발자가 경험할 수 있는 환경을 미리 준비
- 개발자간 쉽게 방법을 공유할 수 있도록 문서화하고 변경사항을 업데이트
런타임 오류 수집
- 특정 기기에서 발생하는 오류일 경우 개발자가 발견하기 어려움
- 고객 입장에서 개발팀이 원하는 수준의 리포팅을 하는 것은 현실적으로 불가능
캐싱 활용
- 모바일 특성상 네트워크 상태가 불안정한 경우에도 동일한 사용자 경험을 제공
- 프리젠테이션 컴포넌트는 독립적으로 운영
- 웹뷰의 생명주기를 알 수 있는 인터페이스 설계
ex.) 웹뷰가 캐싱된 데이터로 렌더할지 데이터 페칭이 필요한지 여부를 네이티브에서 제공
- 아키텍처를 변경해야 할 여지가 있으므로 충분한 가치가 있는 작업인지 신중히 고려