웹뷰를 이용해 웹 서비스를 앱으로 빠르게 구현하기 | 인프콘2023

IT분야, 프로그래밍, 디자인, 업무스킬, 3D 모델링, 온라인 마케팅 등
전문 지식 분야를 무료 혹은 경제적으로 학습할 수 있는 인프런 입니다.

더 많은 학습을 원하시면 인프런으로 놀러오세요!

미래의 동료들과 함께 성장하는 곳, 인프런
🌱 인프런 바로가기 : https://www.inflearn.com​ 


인프런 inflearn

웹뷰는 **앱 내에 웹 콘텐츠를 포함시킬 수 있도록 내장된 브라우저**라고 생각하면 됩니다. iframe과 유사한 개념으로 이해할 수 있으며, 네이티브 앱 위에 웹 콘텐츠를 레이어처럼 얹어 보여주는 방식입니다. 웹 개발자가 직접 웹뷰를 제어할 수 있다는 장점이 있습니다.

🌉 웹뷰와 네이티브 앱 간의 소통: Bridge

웹뷰와 네이티브 앱은 **"bridge"라는 인터페이스를 통해 소통**합니다. 이 bridge는 OS 수준에서 웹 앱 또는 콘텐츠와 통신할 수 있게 해주는 도구입니다. 개발자는 JavaScript를 사용하여 네이티브 기능을 통합할 수 있으며, PostMessage와 같은 메커니즘을 활용하여 양방향 통신을 구현할 수 있습니다.

✅ 웹뷰의 장점: 독립성과 양방향 개발

웹뷰는 **웹 서비스와 완전히 격리된 환경에서 작동**합니다. 웹뷰 내에서 런타임 오류가 발생해도 앱 전체가 종료되지 않는다는 점이 큰 장점입니다. 또한, 웹 개발과 앱 개발을 동시에 진행할 수 있어 효율적인 개발이 가능합니다.

🤔 React Native vs Flutter: 어떤 것을 선택해야 할까요?

React Native와 Flutter는 앱 개발을 위한 대표적인 선택지입니다. **웹 서비스를 기반으로 React에 익숙하다면 React Native를, iOS/Android 개발자가 부족하다면 Flutter를 선택**하는 것이 현실적인 대안이 될 수 있습니다. 기술적인 완성도나 커뮤니티 규모보다는 현재 보유한 리소스와 개발 환경을 고려하는 것이 중요합니다.

⚙️ React Native에서 웹뷰 설정 및 통신

React Native WebView를 사용하면 웹과 앱 간의 통신을 쉽게 구현할 수 있습니다. **웹뷰는 bridge 역할을 하며, injected JavaScript를 통해 웹 페이지에 데이터를 전송하거나, postMessage를 사용하여 웹에서 앱으로 데이터를 보낼 수 있습니다.** React Native WebView 라이브러리를 설치하여 프로젝트에 웹뷰를 추가할 수 있습니다.

🗺️ 앱 내에서 라우팅 처리하기

웹과는 달리 앱에는 브라우저가 없으므로, 별도의 라우팅 시스템이 필요합니다. React Native Navigation을 사용하여 **protected route와 nested route를 구현**할 수 있습니다. Navigation Container로 컴포넌트를 감싸고, 스크린 컴포넌트를 정의하여 앱 내의 화면 전환을 관리합니다.

앱 개발 시에는 **정보 저장을 위해 반드시 라이브러리를 사용**해야 합니다. Local Storage를 사용하면 앱을 종료해도 데이터가 유지됩니다. 이는 사용자 로그인 정보나 앱 설정 등을 저장하는 데 유용합니다.

푸시 알림은 앱 개발의 중요한 부분입니다. X4 프레임워크에서 제공하는 라이브러리를 사용하면 푸시 알림을 쉽게 구현할 수 있습니다. **푸시 알림을 보내기 전에 사용자에게 권한을 요청하고, 사용자의 instance ID를 저장하여 푸시 토큰 데이터를 관리**해야 합니다.

앱을 출시하기 전에 **Google과 Apple의 스토어 등록 절차를 준비**해야 합니다. 특히 Apple은 피드백이 늦으므로 먼저 처리하는 것이 좋습니다. 앱의 퀄리티를 높이기 위해서는 스플래시 이미지 추가, native 개발을 통한 기능 확장 등을 고려할 수 있습니다.

앱을 확장하기 위해서는 **native 개발자의 역할이 중요**합니다. native 개발을 통해 bridge 인터페이스 확장, 파일 관리, 카메라 기능 추가 등 다양한 기능을 구현할 수 있습니다. 또한, 앱 배포 전에는 철저한 테스트와 버전 관리가 필수적입니다.

네, 안녕하세요. 저는 웹뷰를 이용해 웹 서비스를 앱으로 빠르게 구현하기 발표를 맡은 29cm 소인성이라고 합니다.

발표에 앞서 저를 간단하게 소개를 드리자면 저는 직업 군인을 만, 거의 근 6년을 또 진행을 했고요.

이제 SI 개발자에서 현재는 29cm 프론트 개발자로 있습니다.

뭐 저에 대한 소개 자체가 중요한 건 아니고 그냥 다들 반갑습니다.

자, 이 발표는 웹뷰의 테크니컬 다이브가 아니고 또 앱을 조금 더 유려하고 화려하게 만들고 만들고 제가 어떤 웹 서비스를 앱으로 장대하게 바꾸는 서사를 발표하는 게 아니에요.

그래서 그런 부분을 만약에 좀 기대를 하고 오셨다면 내려 놓으셨으면 좋겠고, 이 발표를 통해서 여러분들이 얻어 갔으면 하는 점은 이런 내용입니다.

웹뷰가 어떤 건지 알고 어떤 툴을 사용하고 또 어떤 키워드를 통해서 내가 도움을 받으면 바로바로 앱에 적용할 수 있겠다.

자, 그래서 바로 발표를 진행을 이어갈 건데요. 어, 제 발표는 QR 코드가 좀 나오니까 만약에 핸드폰에서 코드를 직접 보고 싶으신 분들은 QR 코드 스캔을 열어 놓으시면 좋을 거 같아요.

자, 저희가 앱을 고려하게 되는 기준은 뭘까요?

보통 어, 저희가 앱을 하게 되는 경우에는 기획자나 혹은 회사의 서비스가 좀 커져야 될 때 또 유저의 니즈를 좀 더 면밀히 파악하고 사업의 소환을 좀 올리고 싶을 때 결정을 하게 되는데요.

저희가 사실 앱부터 시작해야 되는 이유는 되게 명확합니다.

사용량을 모바일 장치가 엄청 압도적으로 차지하고 있기 때문이에요.

그래서 웹 앱과 모바일 앱에 대한 차이는 대체 뭘까요?

저희가 단순히 이 웹 서비스만 개발을 해서 브라우저로 모바일 장치를 이제 브라우저로 접속을 하게 되면 전부 다 반응형 디자인인데 더 좋은 거 아니냐라고 얘기할 수 있잖아요.

그래서 제가 생각하는 웹앱과 모바일 앱에 좀 되게 개략적인 비유를 하자면 요런 정도의 차이가 있을 것 같습니다.

모바일 화면도 이제 반응형으로 구현한 웹과 모바일 화면만 구현한 이제 모바일 앱 이렇게 되는데요.

뭐 여러 차이가 있겠죠. 저는 단점은 좀 제거를 했고 장점만 좀 적어 놨습니다.

이런 내용들만 알아도 사실 뭐 면접 때 질문하는 거리로는 되게 좋죠.

근데 이 중에서 저희가 앱을 선택하느냐, 웹을 선택하느냐는 대체 어떤 걸까요?

저희가 개인 프로젝트나 토이 프로젝트를 할 때가 중요한 게 아닙니다.

회사 차원에서 어떤 서비스를 만들어 갈 때 스타트라인을 끊게 되는 그 기점은 뭘까요, 보거든요.

첫 번째로 웹에서 가장 좋은 점은 저희가 다양한 플랫폼을 전부 다 아우를 수 있죠.

그래서 생산성이 되게 높습니다. 반면 모바일 기기는 생산성이 조금 낮을 수 있어요.

왜냐면 iOS 기기도 개발을 해야 되고 안드로이드 플랫폼도 개발을 해야 되죠.

대신 모바일 기기를 좀 더 면밀하게 기능을 더 확장해서 사용할 수 있다라는 점이 정말 강력하다고 꼽을 수 있습니다.

자, 그러면 이번에 발표 주제인 웹뷰에 대해서 얘기를 조금 해 볼게요.

웹뷰는 뭐 안드로이드에도 있고 iOS 있습니다. 이렇다는 얘기는 크로스 플랫폼 뭐 리액트 네이티브, 플러터 그 외에 언어들이 갖고 있는 유구한 특성이 아니라는 거예요.

이것은 네이티브 언어 자체가 지원하고 있는 그 추상화된 인터페이스 중 하나입니다.

그래서 웹뷰가 뭐예요? 여러분들 이렇게 여쭤볼 수 있을 것 같아요.

웹뷰는 이렇게 정리할 수 있을 것 같습니다. 저희가 앱에 웹 콘텐츠를 이렇게 넣을 수 있는 내장형 브라우저에 아이프레임을 한 번이라도 경험해 보셨거나 사용을 해 보셨던 분들이 계시다면 이 아이프레임 웹뷰가 비슷하구나 느끼실 수 있을 것 같아요.

저희가 일례로 많이 사용하는 구글 홈입니다.

이 구글 홈은 이렇게 뜯어 보면 이러한 형태로 구성이 되어 있어요.

상태 표시줄, 그리고 웹 화면이 그려지는데, 이것도 앱이죠. 구글 크롬도 사실 브라우저 자체라고 얘기하긴 어렵고, 앱에서 브라우저를 띄운 형태인 거죠.

웹 뷰도 똑같습니다. 이렇게 네이티브 앱 위에 올라가게 돼서 이 웹 뷰가 웹 컨텐츠를 그려 주게 되는 거죠.

이거를 저희가 도표를 조금 더 자세하게 보자면요, 이런 식으로 출력이 됩니다.

오른쪽이 웹 앱입니다. 왼쪽이 모바일 앱이에요.

이 차이는 되게 면밀하게 나타나는데, 브릿지라는 단어가 갑자기 생소하게 등장합니다.

둘 다 네이티브 플랫폼이나 OS 위에서 동작할 수 있고 어떤 웹 앱 혹은 웹 콘텐츠와 소통을 할 수 있는데, 그 사이에 존재하는 인터페이스가 있어요.

이 인터페이스는 네이티브 플랫폼이나 OS 혹은 웹 콘텐츠와 소통할 수 있게 만들어 주는 일종의 도구입니다.

저희가 신경 쓰지 않아도 되는 것들이죠.

저희는 이거를, 저희는 이렇게 이 브릿지를 통해서 기본 시스템 API 직접 호출할 수 있어요.

실제로 플로터는, 그러니까 플로터는 프레임워크는 언어가 다르죠.

근데 이 언어가 다름에도 네이티브 코드, 또 리액트 네이티브도 와, 스위프트 혹은 코틀린 언어를 호출할 수 있어요.

이 이유는 웹뷰에서 만들어 주는 것처럼 어떤 시스템 API가 호출할 수 있기 때문입니다.

웹뷰는 자바스크립트 언어를 통해서 네이티브 기능과 통합할 수 있다라는 게 가장 큰 장점이죠.

다시 한번 말하지만 이런 기능을 브릿지라고 합니다.

브릿지는, 어, 정확하게 조금 더 뭉뚱그려서 얘기를 해 놓을게요.

추상화된 인터페이스입니다. 여러분들이 브릿지라는 단어에 되게 집중할 필요가 없어요.

저희는 그냥 가져다 사용하면 됩니다. 세이나 플 코드들을 다 활용해서 컨트롤만 해도 되는 부분이기 때문에 직접 브릿지를 구현해야겠다라고 생각을 하신다면 아마 여러분들이 만들고 있는 앱이나 서비스는 이미 한 단계 더 진화하고 있을 거예요.

자, 그러면 저희가 이 브릿지에 대한 대표적인 녀석을 찾아봐야겠는데 많이 보셨을 거예요.

윈도우 객체가 제공하고 있는 포스트 메시지라는 겁니다.

이 포스트 메시지가 정확하게 실제로 무슨 행동을 한다가 아니라이 포스트 메시지를 통해서 윈도우 객체에 이벤트를 바인딩해 놓으면 포스트 메시지가 전달한 특정 메시지를 윈도우 객체에서 받을 수 있어요.

이 하나만 기억을 하셔도 저희가 다음 웹뷰를 손대면서 많은 기능들을 더 적용할 수 있는데 그래서 웹뷰가 뭐가 좋아요?

웹뷰는 한 번에 양방향 개발이 가능하니까 너무 좋죠.

웹만 개발해 놓으면 앱도 커버할 수 있고 다 여러 플랫폼도 신경 쓰지 않아도 되잖아요.

그런데 저희는 그게 중요한 게 아니잖아요.

웹뷰가 어떻게 해서 좋은 기술이냐, 가 좋은 기술인 이유는 아까 얘기했던 이 웹뷰는 영역과 웹앱에서 완전히 격리된 환경이 놓여 있다는 거예요.

추후에 GIF Pro 제가 코드를 보여 드릴 건데 만약에 웹뷰 내에서 런타임 에러가 발생해서 웹사이트가 꺼졌어요.

이런 경우에는 저희는 보통 코드의 오류가 전파된다고 표현을 많이 하는데 실제 서비스에서도 전파가 되게 되면 서버가 죽겠죠.

반대로 웹뷰는 서버가 죽어도 앱이 꺼지지 않습니다.

이게 가장 큰 독립적인 별개의 샌드박스를 구성한다는 것이고 그렇다는 얘기는 저희 개발자가 웹뷰를 직접 핸들링할 수 있다라는 가장 큰 장점이죠.

그렇다는 얘기는 웹에서 열리는 웹 콘텐츠라 할지라도 웹뷰에서 조금 더 독립적으로 기능하게 만들 수 있다라고 정의할 수 있겠습니다.

결국 웹뷰를 선택하게 되면 약간 네이티브 앱의 모든 기능들을 활용하는 것처럼 느껴질 수 있어요.

그 이유는 웹 서비스에서 구동하고 있는 코드가 웹뷰로 통신을 하면 이 웹뷰가 네이티브 앱과 소통할 것이기 때문이죠.

그래서 이러한 기능들을 여러분들이 조금 더 확장성 있게 구현할 수 있습니다.

그렇다면 여기까지 알아봤자아요. 저희가 앱을 어떻게 만들지 준비를 해야겠죠.

그 전에 저희가 결정을 해야 될 게 있습니다.

아, 정말 어려운 문제예요. 리액트 네이티브냐, 플러터냐. 정말 많이 싸워 왔죠.

사실 저는 이 발표를 준비하면서도 계속 자료 서칭을 했는데 어, 이렇게 비교할 수 있을 것 같아요.

자, 리액트 네이티브 왼쪽에 자르 보시면 됩니다.

아이, 행성이 한 시간에 7년이 흐르는데. 와, 그러면 갔다 오면 리액트 네이티브가 릴리즈 돼 있겠다.

아직까지도 메이저 버전이 안 올라갔어요.

0.777 이렇게 계속 올라가고 있는 상황이고요. 그러면서도 업데이트 패치는 계속 되고 있습니다.

플러터, 구글이 주도하고 있, 게다가 기존에 리액트 네이티브가 갖고 있던 코드 푸쉬라는 기능이 이번에 2주 전에 플러터에서 다 모든 플랫폼을 적용한다고 포를 공식 선호를 했습니다.

그럼 사실상 리액트 네이티브는 아 플러터로 이주할 수 있을 것 같아요.

아, 근데 이 발표 리액트 네이티브 잖아요.

스택 오버플로우입니다. 처음에는 리액트 네이티브가 압도적이었는데, 이때는 왜 압도적이었냐면 리액트가 너무 셌어요.

페이스북이 너무 강했습니다. 베타 전이었죠.

점점 올라오는 게 어, 2023년에는 메타가 리액트 네이티브를 포기했습니다.

그래서 리액트 네이티브는 이제 커뮤니티 팀으로 돌아가는데 플러터는 꾸준히 올라가고 있어요.

이런 걸 비교해야 됩니다. 벌써부터 지쳐요. 내가 이런 의사 결정을 해서 리더한테 얘기를 하고 그 리더들이 해대면, 너무 힘들어요.

뭐라는 거야, 진짜 대체 뭐라는 걸까?

그래서 저는 정리를 딱 해 드릴게요. 좀 극단적인 여러분들이 웹서비스 없이 앱을 만드는데 리소스가 없어요.

iOS 개발자도 뽑고 안드로이드 개발자도 뽑고 이런 리소스가 없으면 플로터를 하셔야 되고요.

웹 서비스가 있거나 리액트를 해보셨다면 리액트 네이티브를 하셔야 됩니다.

이거는 기술적 숙련도, 커뮤니티 완성도 다 중요하지 않아요.

현실적으로 가능한 수단입니다. 자, 여기 발표, 발표인데 지금 장소에 참여하고 계시는 분들, 리액트 많이 쓰셨죠?

자, 그래서 리액트 네이티브를 준비했습니다.

그래야지 여러분들이 한 번이라도 앱을 만들어 볼 수 있는 기회를 더 가질 수 있잖아요.

이제 다른 분들에게 죄송하지만 저는 그렇게 생각을 좀 했습니다.

자, 리액트 네이티브가 어떤 걸 제공하는지 그럼 좀 봐야겠죠. 아까 웹뷰가 일종의 브릿지 역할을 하면서 어떤 통신를 통해 웹과 앱에서 소통할 수 있다라고 얘기를 했는데 이, 이렇게 파어 문구를 보시면 리액터 네이티브에서 웹으로 보낼 때, 웹에서 앱으로 보낼 때 각각의 프로퍼티와 메소드를 통해서 호출을 하게 됩니다.

사실 이렇게 보면 좀 어렵잖아요.

위에 프로퍼티들을 이미 사전에 정의되어 있는 녀석들이 메서드들은 저희가 동적으로 자유롭게 할 수 있는 행위들이자 코드로 볼게요.

왼쪽은 리액트 네이티브 앱입니다. 이 빨간 줄이 쳐져 있는 곳을 보시면 인젝티드 자바스크립트로 돼 있어요.

이 코드는 웹뷰가 웹을 열 때 위에 있는 템플릿 문자열을 넣어서 전송할 수 있어요.

그렇기 때문에 오른쪽에 뜬 화면에서 헬로가 출력되는 것을 확인할 수 있죠.

오케이. 네, 죄송합니다. 자, 그다음에는 웹에서 앱으로 보내는 건데, 제가 HTML 파일도 보여 드려야 되니까 그냥 이렇게 템플릿으로 준비했어요.

29cm의 소인성 발표자가 웹뷰를 사용하여 웹 서비스를 앱으로 빠르게 구현하는 방법에 대해 소개.

앱 개발 결정 기준은 서비스 성장, 사용자 이해도 향상, 사업 성과 증진이며 모바일 기기 사용이 압도적이기 때문.

웹 앱은 다양한 플랫폼을 포괄하여 생산성이 높지만, 모바일 앱은 iOS와 Android 개발 필요로 생산성이 낮으나 기능 확장성이 높음.

WebView는 앱 내에 웹 콘텐츠를 통합할 수 있는 내장 브라우저로, 네이티브 언어에서 지원하는 추상화된 인터페이스 중 하나.

WebView는 네이티브 앱 위에 웹 콘텐츠를 렌더링하는 방식으로 작동하며, '브리지'라는 인터페이스를 통해 네이티브 플랫폼과 웹 콘텐츠 간의 통신이 가능.

브리지는 JavaScript 언어를 통해 네이티브 기능을 통합할 수 있게 해주며, Windows 객체의 PostMessage가 대표적인 예시.

웹뷰는 도메인과 웹 앱으로부터 완전히 분리된 환경에서 작동하며, 런타임 오류가 발생해도 앱 전체에 영향을 주지 않는 독립적인 샌드박스 환경을 제공.

웹뷰를 통해 웹 콘텐츠가 네이티브 앱의 기능을 활용하는 것처럼 느껴지게 할 수 있으며, 웹 서비스의 코드가 웹뷰를 통해 네이티브 앱과 상호 작용할 수 있도록 함.

앱 개발 시 React Native와 Flutter 중 선택해야 하는데, 웹 서비스가 없고 iOS/Android 개발자가 없다면 Flutter를, 웹 서비스가 있거나 React 경험이 있다면 React Native를 선택하는 것이 현실적인 선택.

React Native는 React의 강세로 초기에 우세했으나, Meta의 지원 중단 후 커뮤니티 중심으로 전환되었고, Flutter는 Google의 지속적인 지원으로 꾸준히 성장.

웹뷰는 브리지 역할을 하여 웹과 앱 간의 통신을 가능하게 하며, React Native에서 웹으로, 웹에서 앱으로 데이터를 보낼 때 각각의 속성과 메서드를 사용.

React Native에서 injected JavaScript를 사용하여 웹 페이지가 열릴 때 특정 코드를 실행하거나, 웹에서 postMessage를 통해 앱으로 데이터를 전송하는 방식으로 웹뷰를 제어 가능.

React Native는 Java Native와 같은 커스텀 설정이 없어 불편하지만, 간단한 워크플로우를 가짐.

X4를 사용하면 CLI를 통해 쉽게 프로젝트를 생성할 수 있으며, React Native WebView 라이브러리를 설치하여 웹뷰를 프로젝트에 추가할 수 있음.

웹뷰 앱 개발 시 노치 디자인, 스크롤 문제, 인터넷 연결 끊김 시 대처, 라우팅 처리, 도메인 디자인 등을 고려해야 함.

앱에서는 브라우저가 없으므로 라우팅 대신 네비게이션 시스템을 구현해야 하며, 이는 보호된 라우트와 중첩된 라우트로 분류할 수 있음.

React Native Navigation은 Navigation Container라는 최상위 컴포넌트 하위에 화면 컴포넌트를 정의하는 방식으로 구성됨.

React Native Stack, Drawer, Bottom Tab 네비게이션을 사용하여 앱의 화면을 구성하고, 웹뷰에서 오는 코드를 더 효율적으로 처리할 수 있음.

useNavigation, useRoute 훅을 사용하여 웹뷰 내에서 네비게이션과 라우트를 동일한 방식으로 처리할 수 있음.

Real World 앱 데모를 통해 최소한의 개발과 빠른 릴리스를 목표로 앱을 구현하고 디자인하는 방법을 설명.

웹과 앱에서 보이는 컴포넌트를 구분하고, 페이지 라우팅 설계, 사용자 로그인 정보 저장 및 인증 사용자 처리, 네이티브 기능 활용 방법을 결정해야 함.

웹뷰를 통해 접근하는지 여부를 확인하기 위해 사용자 에이전트, React Native 웹뷰 속성, 화면 크기 등을 활용하여 앱과 웹을 구분.

window.postMessage를 사용하여 웹뷰로 메시지를 보내고, React Native WebView에서 메시지 핸들러 이벤트를 통해 해당 데이터를 처리.

Jason 객체를 사용하여 스택 액션, 푸시, 네비게이트, 디스패치 등 네비게이션 관련 속성을 제어.

중첩된 네비게이션을 사용하여 화면을 구성하고, 앱을 닫아도 데이터가 유지되는 로컬 스토리지를 사용하여 정보를 저장.

푸시 알림은 개발 앱이 알림 서버로 알림을 보내거나 백엔드를 호출하여 알림 서버로 보내는 방식으로 작동하며, X4 프레임워크에서 제공하는 라이브러리를 사용하여 푸시 알림을 쉽게 구현할 수 있음.

로컬 알림과 푸시 알림의 차이점을 설명하고, 푸시 알림을 보내기 전에 권한을 확인하고 사용자 인스턴스 ID를 저장하여 푸시 토큰 데이터를 제어하는 방법을 설명.

시뮬레이터에서 푸시 알림을 테스트하고, 알림 도착 시 또는 수신된 알림을 탭할 때의 이벤트 분기를 처리하는 방법을 설명.

React Native 컴포넌트는 HTML처럼 작동하지 않으며, JavaScript 번들에 의해 네이티브 코드로 컴파일되므로 CSS 스타일링과 이벤트 처리에 차이가 있음.

eas build 명령어를 사용하여 앱을 빌드하고, Android 앱은 빠르게 Play 스토어에 업로드할 수 있지만, iOS 앱은 유료 번들이 필요함.

웹 코드에서 웹뷰를 확인하고 라우팅 이벤트를 가로채서 처리하는 코드를 포함하여 앱 화면을 디자인하고, 사용자 정보를 기반으로 화면을 표시하거나 숨기는 방식으로 앱을 구현.

Real World 앱을 간소화하여 인증 여부에 따라 다른 화면을 표시하고, 스플래시 이미지, 바텀 탭, 드로어, 프로필 작성, 게시글 작성, 좋아요 등의 기능을 구현.

앱 출시를 위해 Google과 Apple 개발자 계정을 준비하고, 앱 스토어에 필요한 정적 리소스를 준비해야 함.

Apple의 앱 심사 과정에서 앱으로 만들어야 하는 이유에 대한 피드백을 받을 수 있으며, 최소한 로컬 네이티브 알림 기능을 개발해야 함.

스플래시 이미지 추가, 노치 디자인, 색상 변경, 브리지 인터페이스 확장, 파일 관리, 카메라 및 음성 녹음 기능 추가 등을 통해 앱을 확장할 수 있음.

앱 배포 전 철저한 테스트를 수행하고, 사용자 이벤트를 수집하여 분석하며, 서비스 로그를 관리하고, 네트워크 불안정으로 인한 웹뷰 기반 앱의 문제를 점진적으로 네이티브 영역으로 가져와야 함.

앱 확장을 위해서는 네이티브 개발이 필수적이며, 네이티브 개발 없이는 언어와 장치에 대한 이해가 부족하여 진행할 수 없음.