한 번 작성하고 모든 곳에 배포: 언제 네이티브로 전환해야 할까요?

WODE(Write Once, Deploy Everywhere) 는 지난 10년 동안 여러 개발 프레임워크의 약속이었습니다. 이 프레임워크의 목표는 여러 기본 애플리케이션을 작성하는 어려움을 줄이는 것입니다. 어떤 경로를 택할지 결정하는 것은 높은 시작 비용, 개발 팀에 미치는 영향, 되돌릴 수 있는 잠재적 가능성으로 인해 프로젝트 관리자가 내려야 하는 가장 중요한 결정 중 하나입니다.

Ionic과 같은 하이브리드 솔루션은 웹 기술을 활용하여 여러 플랫폼에서 응용 프로그램을 렌더링하지만 종종 최종 제품은 기본 모양과 느낌에 대한 사용자의 기대에 미치지 못합니다.

그러나 최근에는 네이티브 코드로 컴파일되는 프레임워크(예: React Native, Xamarin 등)로 인해 "네이티브"라는 용어조차 모호해졌습니다.

이 기사에서는 다양한 모바일 개발 경로의 장단점을 분석하고 팀 구성, 비용 및 사용자 경험과 비교하여 제품 관리자가 정보에 입각한 결정을 내릴 수 있도록 합니다.

한 번 작성, 모든 곳에 배포

Write Once, Deploy Everywhere 의 개념은 개발 팀이 단일 개발 스택을 사용하여 애플리케이션을 한 번 작성하고 애플리케이션이 배포될 플랫폼의 개요를 유지하면서도 배포 기능을 유지하는 능력을 나타냅니다. 원하는 모든 플랫폼(예: Android, iOS, Windows 등)에 대한 애플리케이션. 이상적으로는 유지보수성, 성능 또는 사용자 경험(UX)을 희생하지 않고 수행됩니다.

모바일 애플리케이션 개발의 대안적이고 역사적인 방법에는 각 플랫폼에 대해 별도의 애플리케이션을 작성하는 간단한 프로세스가 포함되며, 이는 물론 자체적으로 시간과 자원의 잠재적인 높은 비용을 수반합니다.

일반적으로 개발 경로를 선택할 때 고려해야 할 요소는 다음과 같습니다.

• 프로젝트의 나이
• 개발팀 구성 및 규모
• 원하는 배포 플랫폼
• 시장 출시에 필요한 일정
• 필요한 경우 다른 경로로 변경할 수 있는 대역폭

불행히도 이러한 요소를 각각의 사용 가능한 경로에 적용하고 해당 주제에 대한 수많은 사용 가능한 의견을 살펴보는 것은 매우 어려울 수 있습니다. 게다가 이 프로세스는 종종 프로젝트 관리자에게 애플리케이션의 요구 사항을 충족하기 위해 어떤 경로가 가장 좋은지 불확실한 느낌을 줍니다.

높은 수준에서 다양한 모바일 개발 경로는 기본 또는 WODE, 즉 기본 또는 기타의 두 가지 범주로 나눌 수 있습니다. 간단히 말해서, 하나는 기본 애플리케이션을 작성하거나 작성하지 않습니다. WODE 범주는 두 그룹으로 더 나뉩니다.

• 하이브리드 프레임워크 - 웹 기술을 활용하여 여러 플랫폼에서 애플리케이션을 렌더링하는 프레임워크입니다.
• 비 하이브리드 프레임워크 - 하이브리드 프레임워크가 하는 것처럼 애플리케이션 내부의 웹 보기를 렌더링하는 대신 기본 UI 구성 요소(예: 버튼, 텍스트 필드, 레이아웃 관리자)를 사용하는 프레임워크입니다.

WODE 프레임워크의 대부분은 하이브리드 입니다. 그러나 WODE 프레임워크의 이점을 계속 제공하면서 하이브리드 프레임워크의 성능과 UX 제한을 모두 개선하기 위해 현재 추세는 비 하이브리드 입니다. 이러한 추세로 인해 React Native, Xamarin, Appcelerator와 같은 프레임워크가 인기를 얻고 있습니다.

이러한 각 경로(네이티브, 하이브리드 및 비하이브리드)는 서로 다른 강점과 약점을 가지고 있으며 결과적으로 가장 적합한 사용 사례가 다릅니다. 이 기사의 나머지 부분에서는 팀 구성, 프로젝트 비용 및 UX와 같은 경쟁 우선 순위를 고려할 때 각 모바일 개발 경로의 장단점을 분석합니다. 몇 가지 특수한 사용 사례를 제외하고 기본 응용 프로그램을 작성하면 약간 더 높은 비용으로 사용자 경험을 극대화할 수 있습니다.

일반적으로 " 당신이 지불한 만큼 얻습니다 "라는 격언이 적용되므로 비용이 고객의 경험보다 더 중요하다면 네이티브가 올바른 선택이 아닐 수 있습니다. 그러나 일단 UX가 중요해지면 네이티브 애플리케이션이 분명한 선택이 됩니다. WODE 기반 애플리케이션은 UX를 개선하기 위해 시간이나 네이티브 전문 지식의 형태로 상당한 비용이 발생하여 네이티브가 아닌 것을 선택하는 목적을 무색하게 하기 때문입니다. 먼저 개발 경로.

또한, 그 비용을 지불하더라도 WODE 기반 최종 제품은 기본 제품과 비교할 때 항상 열등한 UX를 제공합니다. 결과적으로 대부분의 개발 팀과 대부분의 프로젝트에서 네이티브가 거의 항상 올바른 선택입니다.

네이티브 애플리케이션

기본 애플리케이션은 해당 플랫폼의 핵심 언어로 작성됩니다. 예를 들어 Android 애플리케이션은 Java로 작성되고 iOS 애플리케이션은 Obj-C 또는 Swift로 작성됩니다. 이를 위해서는 개발 엔지니어가 언어는 물론 타사 패키지 통합, 레이아웃 관리, 운영 체제(OS) 상호 작용 등과 같은 플랫폼별 뉘앙스를 이해해야 합니다.

장점

고도로 사용자 정의할 수 있습니다 . 각 응용 프로그램은 기본 구성 요소를 사용하여 작성되었기 때문에 사용자 지정에 대한 유일한 제한은 기본 프레임워크에 대한 인터페이스이며 때로는 그렇지 않은 경우도 있습니다. 대부분의 네이티브 개발 엔지니어가 증명하듯이 제한된 인터페이스에도 불구하고 주어진 작업을 수행하는 방법이 종종 있습니다.

이 아이디어에 대한 간단한 증거는 특정 플랫폼에 대한 지원 커뮤니티를 검색하여 찾을 수 있습니다. 기본 프레임워크의 한계에도 불구하고 "예약을 벗어난" 작업을 수행하는 방법에 대한 수많은 예를 찾을 수 있습니다.

이러한 단순해 보이는 작업의 구체적인 iOS 예는 모든 외부 UI 요소(예: 탭 표시줄, 탐색 표시줄 등) 위에 전체 화면 오버레이를 표시하는 것일 수 있습니다. 그림 1 에서 볼 수 있듯이 이는 일반적으로 현재 표시되고 있는 일반 UI 레이어입니다. 따라서 전체 화면 오버레이를 가지려면 뷰 스택의 탭 표시줄 위의 숨겨진 레이어에 추가해야 합니다. 이러한 종류의 사용자 지정은 일반적으로 기본 응용 프로그램에서만 가능합니다.

최고 성능 . 예상대로 기본 애플리케이션은 성능에 대한 벤치마크를 설정합니다. 대부분의 다른 프레임워크 유형은 하나 이상의 중간 계층을 추가하기 때문에 본질적으로 기본 애플리케이션보다 느리게 실행됩니다.

가장 유지 보수가 용이 합니다. 운영 체제는 지속적으로 변경됩니다. 기간. 업데이트할 때 주요 변경 사항이 있는지 여부에 따라 최신 OS로 업그레이드하는 사용자 기반의 일부를 잃지 않도록 애플리케이션을 적시에 업데이트해야 합니다. 분명히 변경 사항이 사용자에게 제공되고 응용 프로그램이 업데이트되는 시간이 짧을수록 더 좋습니다. 이 시간은 이 새로운 OS를 지원하기 위해 업데이트해야 하는 종속성이 없을 때 최소화되며, 네이티브 애플리케이션에서 작업하는 경우입니다.

단점

추가 리소스 . 여러 플랫폼용 애플리케이션을 작성할 때 개발 팀은 일반적으로 지원되는 각 플랫폼에 대해 한 명 이상의 모바일 소프트웨어 엔지니어로 구성됩니다. 물론 이것은 본질적으로 개발 팀의 규모와 비용을 증가시킵니다. 또한 엔지니어 팀은 균질한 기술 기반이 아니라 다양한 기술을 보유해야 합니다. 이는 지원 및 협업과 관련하여 팀을 분열시킬 가능성이 있습니다.

느린 개발 주기 . 네이티브 앱은 원하는 플랫폼마다 별도의 애플리케이션을 작성해야 하기 때문에 개발 주기가 더 느려질 가능성이 있습니다. 극단적인 경우는 각 애플리케이션이 기본적으로 시리즈로 작성되기 때문에 팀에 한 명의 모바일 개발 엔지니어가 있는 경우입니다.

낮은 성능 . 장점이자 단점인 성능이 이상하게 보일 수 있습니다. 한편으로 네이티브 애플리케이션은 개발자에게 미세 조정된 고성능 애플리케이션을 만들 수 있는 충분한 공간을 제공합니다. 그러나 다른 한편으로는 개발자에게 스스로 목을 매기에 충분한 밧줄도 제공합니다. 그들이 무엇을 하고 있는지 모른다면 결국에는 기껏해야 수준 이하의 응용 프로그램으로 끝날 것입니다.

참고: 일반적으로 이는 모든 프레임워크 경로(네이티브, 하이브리드 및 비하이브리드)에 적용됩니다. 응용 프로그램을 개발하는 엔지니어가 시도하는 작업에 대한 기술이 충분하지 않은 경우 결과 응용 프로그램은 설계 요구 사항을 충족하지 못하거나 사용자가 잘 받아들이지 못할 수 있습니다.

하이브리드 애플리케이션

하이브리드 애플리케이션은 일반적으로 사용자 인터페이스를 디자인하기 위해 HTML/CSS/LESS를 사용하여 작성됩니다. MVC 디자인 패턴의 "V"입니다. 그런 다음 "C" 또는 컨트롤러는 일반적으로 JavaScript로 작성됩니다. 이상적으로는 AngularJS와 같은 JavaScript MVC 프레임워크를 사용합니다. AngularJS와 같은 프레임워크를 사용하면 일반적으로 jQuery만 사용하는 것보다 클래스와 책임을 더 잘 분리할 수 있습니다.

이러한 유형의 하이브리드 프레임워크 스택의 예로는 AngularJS가 지원하는 Ionic 뷰 레이어가 있습니다. 이 레이어는 궁극적으로 PhoneGap 및 Cordova를 사용하여 원하는 플랫폼의 웹 뷰에서 변환 및 렌더링됩니다. 분명히, 이러한 유형의 WODE 프레임워크는 복잡성을 추가하는 대가를 치르게 됩니다.

또한 JavaScript를 사용하면 고유한 디자인 기반 제한과 언어 기반 문제가 발생합니다. 이 기사의 목표는 한 언어의 장점이나 결함에 대해 토론하는 것이 아닙니다. 그러나 프로젝트 관리자로서 모바일 기술 스택에서 JavaScript를 사용하기로 한 선택을 가볍게 해서는 안 됩니다. 다음은 가능하면 JavaScript를 피해야 하는 이유에 대한 잘 작성된 기사의 몇 가지 예일 뿐입니다.

• 자바스크립트 문제
  
• 내가 React Native 개발자가 아닌 이유

장점

최소한의 개발팀 . 하이브리드 프레임워크를 사용하면 소규모 개발 팀, 특히 주요 지식 기반이 웹 개발인 개발 팀이 여러 플랫폼에서 간단한 애플리케이션을 빠르게 생성할 수 있습니다. 이를 통해 프로젝트 관리자는 팀을 작게 유지할 수 있을 뿐만 아니라 팀이 여러 플랫폼에 대한 기본 언어와 프레임워크를 배울 필요가 없습니다.

더 빠른 개발 주기 . 소규모 팀 외에도 하이브리드 프레임워크는 웹 기술을 사용하여 단일 보기 계층만 설계하면 되므로 여러 플랫폼에 배포할 때 더 빠른 개발 주기를 제공합니다.

단점

잠재적으로 열악한 UX . 하나의 뷰 레이어만 작성해야 하는 단점은 하나의 뷰 레이어가 남는다는 것입니다. UI 디자인에 대한 획일적인 접근 방식은 모든 플랫폼의 사용자에게 편안하고 친숙한 모양과 느낌을 애플리케이션에 제공하지 못하기 때문에 UX가 좋지 않을 수 있습니다. 또한 하이브리드 애플리케이션은 본질적으로 UI 내에 내장된 웹뷰이기 때문에 사용자에게 네이티브 애플리케이션과 상호 작용하는 대신 실제로 웹 페이지를 보고 있다는 인상을 줄 수 있습니다. 이 경험은 거의 항상 사용자 만족도와 궁극적으로 유지에 부정적인 영향을 미칩니다.

사용자 정의 비용이 많이 듭니다 . 플랫폼별로 맞춤형 UI를 설계하여 UX를 개선하면 생성 비용이 많이 들고 시간이 지남에 따라 유지 관리하기 어려운 복잡하고 고유한 UI 프레임워크가 생성됩니다. 또한 애플리케이션을 눈에 띄게 만드는 데 도움이 되는 UI 요소(예: 애니메이션, 사용자 정의 보기 등)를 만들기 위해서는 높은 수준의 UI 디자인을 낮은 수준의 프레임워크에서 볼 수 있는 것으로 변환하기 위해 사용자 지정된 브리지 구성 요소를 만들어야 합니다. , Cordova와 같은 이해합니다. 일반적으로 하이브리드 애플리케이션의 UX를 사용자 정의하고 개선할수록 빠르고 저렴한 디자인 주기의 이점이 줄어듭니다.

낮은 성능 . 하이브리드 응용 프로그램은 웹 보기 내에서 응용 프로그램의 보기를 렌더링하므로 OS 프레임워크(예: 네트워킹, Bluetooth, 장치 내 연락처 등)를 처리할 때 구현 실수를 할 가능성이 커서 성능이 크게 저하됩니다. 모든 것이 webview를 통해 표시되기 때문에 성능과 관련하여 세심한 주의를 기울이더라도 하이브리드 응용 프로그램의 최대 성능은 항상 기본 대응 제품보다 약간 낮습니다.

사소한 플러그인 관리 . 디자인 팀이 몇 주 동안 다듬는 데 소비한 사용자 지정 기능을 기억하고 개발 팀에서 Cordova와 함께 작업할 수 있도록 필요한 브리지 구성 요소를 만드는 동안 몇 주가 더 걸렸습니다. 글쎄요, 팀이 달성하려는 것을 지원하는 Cordova 플러그인이 없으면 작동하지 않습니다. 이것은 두 가지 중 하나를 의미합니다. 팀이 자체적으로 만들거나 작업을 수행하는 적절한 타사 플러그인을 찾아야 합니다. 불행히도 옵션 2는 존재하지 않는 경우가 많습니다. 결과적으로 사용자 지정 플러그인을 만드는 데 추가 개발 시간이 필요하고 시간이 지남에 따라 애플리케이션에 필요한 Cordova 플러그인의 증가하는 라이브러리를 관리하기 위한 빌드 지원 노력이 필요합니다. 물론 Cordova 업데이트가 발생하면 이러한 플러그인도 업데이트해야 할 가능성이 높습니다.

OS 지원 지연 . 앞서 언급한 캐스케이딩 브리지 구성 요소/Cordova 플러그인 문제는 OS가 핵심 기능을 변경할 때 더욱 악화됩니다. Cordova, PhoneGap 및 Ionic이 변경 사항을 지원하도록 업데이트되면 사용자 지정 플러그인 및 브리지 구성 요소도 업데이트해야 할 수 있습니다. 이 작업에 필요한 규모에 관계없이 응용 프로그램이 새 OS로 업데이트한 최종 사용자를 지원하지 않는 추가 시간이 발생합니다. 물론 이것은 Apple이나 Google에서 이전 버전과 호환되지 않는 획기적인 변경을 수행하는 최악의 시나리오이며 절대 일어나지 않습니다... 맞나요? 일반적으로 개발자가 제어할 수 없고 먼저 ​​업데이트해야 하는 중간 프레임워크는 프로세스를 지연시키는 역할만 합니다. 마지막으로, 중간 프레임워크에 의존하는 것은 이러한 프레임워크의 타이밍을 알 수 없기 때문에 프로젝트 관리자가 계획을 세우는 데 골칫거리가 될 수 있습니다.

비 하이브리드 애플리케이션

비-하이브리드 애플리케이션은 비-네이티브 플랫폼 언어로 설계된 UI 레이어인 하이브리드 애플리케이션처럼 생명을 시작합니다. React Native는 .NET 루트로 인해 C#을 기반으로 하는 JavaScript 또는 Xamarin에서 지원하는 HTML/CSS를 사용합니다.

그러나 그것이 유사성이 끝나는 곳입니다. 하이브리드가 아닌 응용 프로그램은 기본 코드로 컴파일되고 webview를 통해 렌더링하는 대신 플랫폼 기본 구성 요소를 사용하여 응용 프로그램을 렌더링합니다. 그 결과 적어도 표면적으로는 두 세계의 장점을 모두 갖춘 WODE 프레임워크가 탄생했습니다.

이전에 논의한 바와 같이 JavaScript 사용을 선택하는 것은 가볍게 내려진 결정이 되어서는 안 되며 JavaScript 사용에 관심이 없거나 배우기를 원하지 않는 개발 팀에게는 거래 차단기가 될 수 있습니다.

장점

하이브리드보다 높은 성능 . 예상할 수 있듯이 비 하이브리드는 내장된 웹 보기에 의존하는 대신 기본 UI 구성 요소(버튼, 보기, 레이아웃 관리자 등)를 사용하여 응용 프로그램을 렌더링할 수 있는 기능으로 인해 하이브리드 응용 프로그램보다 본질적으로 성능이 높습니다. 물론 개발자는 여전히 놀랍거나 끔찍하게 작동하는 애플리케이션을 자유롭게 작성할 수 있습니다. 비 하이브리드 애플리케이션의 이점은 단순히 유사한 하이브리드 애플리케이션과 비교할 때 더 높은 성능 기준을 갖는다는 것입니다.

최소한의 개발팀 . 하이브리드 프레임워크와 유사하게 하이브리드가 아닌 경우 소규모 개발 팀, 특히 주요 지식 기반이 웹 개발인 팀이 여러 플랫폼에서 간단한 애플리케이션을 신속하게 생성할 수 있습니다. 이를 통해 프로젝트 관리자는 팀을 소규모로 유지하고 팀이 여러 플랫폼에 대한 기본 언어 및 프레임워크를 학습하지 못하도록 할 수 있습니다.

더 빠른 개발 주기 . 소규모 팀 외에도 비 하이브리드 프레임워크는 단일 보기 계층만 설계하면 되므로 여러 플랫폼에 배포할 때 더 빠른 개발 주기를 제공합니다.

더 빠른 반복(React) . React 프레임워크는 애플리케이션의 변경 사항을 실시간으로 렌더링할 수 있는 강력한 기능을 제공합니다. 재컴파일, 재구축 등이 필요하지 않습니다. 결과적으로 React 에뮬레이터는 각 구현의 기간을 획기적으로 줄이는 매우 강력한 개발 도구입니다. 주기.

단점

사용자 정의 비용이 많이 듭니다 . 하이브리드 애플리케이션과 마찬가지로 비 하이브리드 애플리케이션이 각 플랫폼에 대한 맞춤형 UI를 설계하여 UX를 개선해야 하는 경우 생성 비용이 많이 들고 시간이 지남에 따라 유지 관리하기 어려울 수 있는 복잡하고 고유한 UI 구성 요소가 생성됩니다. 이것은 또한 프레임워크의 기본 요소 지원의 격차를 보완하기 위해 사용자 정의된 브리지 구성 요소를 작성하는 것을 의미합니다. 하이브리드와 마찬가지로 이 비용은 빠르고 저렴한 설계 주기의 이점을 감소시키지만 하이브리드 애플리케이션과 달리 브리지 구성 요소는 원하는 각 플랫폼 에 대해 모국어로 작성됩니다. 즉, 하이브리드가 아닌 애플리케이션이 주로 웹 개발자로 구성된 팀에 대한 유연한 대안이 되는 대신, 하이브리드가 아닌 경로를 선택하는 팀은 프레임워크의 특정 언어(예: JSX 또는 C#)뿐만 아니라 또한 각 플랫폼(Java, Obj-C 또는 Swift)의 모국어입니다.

타사 종속성 . 이 제한은 두 가지 다른 형태를 취합니다. React Native의 경우, 약 650개의 수많은 종속성의 형태를 취합니다. 그 결과 특정 시점에 이러한 종속성 중 하나 이상이 최신 상태가 아닐 가능성이 매우 높습니다. 이는 또한 OS 수준이 크게 변경되는 경우 해당 종속성 대부분 또는 전체를 업데이트해야 할 가능성이 높다는 것을 의미합니다. 잠재적 인 절약 은혜는 Facebook이 React를 사용하므로 구석에 300lb 고릴라가 있다는 것입니다.

Xamarin의 경우 타사 종속성 문제는 애초에 이들을 통합하기가 극히 어렵다는 점입니다. Xamarin은 이 문제를 알고 있으며 Sharpie라는 유틸리티 도구를 제공합니다. 이 도구의 목적은 일부 통합을 돕는 것이지만 불행히도 Sharpie는 종종 잘못된 리소스를 컴파일하고 연결하려고 시도하므로 개발자는 성공적으로 완료하기 위해 저수준 컴파일 매개변수를 수동으로 수정하는 힘들고 시간 소모적인 작업을 수행해야 합니다. 통합.

OS 지원 지연 . 하이브리드가 아닌 응용 프로그램은 하이브리드 응용 프로그램과 동일한 문제로 어려움을 겪습니다. 개발자가 제어할 수 없고 먼저 ​​업데이트해야 하는 모든 중간 프레임워크는 최신 사용자를 지원하기 위해 응용 프로그램을 업데이트하는 프로세스를 지연시키는 역할을 합니다. 게다가, 앞서 언급했듯이, 중간 프레임워크에 의존하는 것은 이러한 프레임워크의 시기를 알 수 없기 때문에 프로젝트 관리자가 계획을 세우는 데 골칫거리가 될 수 있습니다.

장기 지원(React Native) . 이 문제는 React Native에만 해당되며 현재까지 Facebook이 프레임워크에 대한 장기 지원 계획을 약속하지 않았다는 이상한 사실과 관련이 있습니다. 회사가 모바일 앱에 자체 프레임워크를 사용하기 때문에 이는 위험이 낮다고 말할 수 있지만 프로젝트 관리자가 Facebook이 주제에 대해 언급을 거부한 이유를 고려해 볼 가치가 있습니다.

올바른 접근 방식 선택

비용이 주요 고려 사항이 아닌 경우 그림 2 는 애플리케이션 요구 사항에 대해 개발 팀 구성을 활용할 때 기본 애플리케이션을 작성하는 것이 거의 항상 최선의 선택임을 보여줍니다. 원하는 플랫폼의 수보다 개발 엔지니어가 적을 때 조금 더 흥미로워집니다. 이 경우 팀이 매우 빡빡한 릴리스 일정에 있는 경우 React를 사용하는 것이 올바른 선택입니다. 그렇지 않으면 네이티브로 가는 것이 여전히 최선의 선택입니다.

팀이 주로 웹 개발 팀이고 맞춤형 UX가 필요한 경우 일부 팀원이 모자를 바꾸거나 일부 팀원을 추가하여 애플리케이션을 기본으로 만드는 것이 좋습니다. 응용 프로그램에 많은 응용 프로그램이 필요로 하는 사용자 지정 요소가 필요한 경우 실제로 실행 가능하고 유지 관리 가능한 프레임워크 옵션이 없습니다.

하지만 커스텀 UX가 필요하지 않다면 출시 일정에 따라 Ionic이나 React로 가는 것이 나을 수도 있습니다. 팀이 JSX를 배울 시간이 없다면 Ionic이 올바른 선택입니다. 그렇지 않으면 이미 많은 타사 종속성이 필요하고 더 추가해도 개발 주기에 영향을 미치지 않으므로 React를 선택하는 것이 좋습니다.

일단 프로젝트 비용이 주요 관심사가 되면 첫 번째 단계는 예상 비용에 대한 프로젝트 계획을 실행할 적절한 팀을 배치하는 것이기 때문에 일반적으로 기존 팀 구성의 우선순위가 낮아집니다. 그림 3 에서 볼 수 있듯이 네이티브 애플리케이션은 WODE 애플리케이션보다 시작 비용이 높지만 잠재적인 UX도 더 높습니다. 게다가 WODE 애플리케이션은 프로젝트에 얼마나 많은 돈과 자원이 투입되는지에 관계없이 항상 UX가 제한됩니다.

이 기사가 다양한 모바일 개발 경로의 장단점에 대해 설명하고 애플리케이션 요구 사항과 프로젝트 비용 모두에 대해 팀 구성을 평가하는 데 도움이 되었기를 바랍니다. 그것의 메시지는 WODE 프레임워크가 열등하고 결코 찾아내서는 안 된다는 것을 전달하는 것이 아니라, 오히려 네이티브로 가지 않는 유효한 사용 사례가 있더라도 그렇게 하는 것의 결과를 완전히 이해해야 한다는 것을 전달하는 것입니다.