크로스플랫폼 모바일 — 후보 비교

같은 앱을 iOS · Android · 웹에 한 코드베이스로 만들고 싶다는 요구는 오래됐습니다. 그 답으로 등장한 도구들은 시기마다 다른 방식을 택했습니다. 웹뷰 위에 얹는 쪽, 자바스크립트 브릿지로 네이티브 위젯을 부르는 쪽, 자체 캔버스에 직접 그리는 쪽. 이 글은 PhoneGap 부터 Tauri Mobile 까지의 흐름과 각 후보의 트레이드오프.

1. 흐름

도구	첫 등장	모델
PhoneGap	2009 (Nitobi)	WebView + 네이티브 플러그인
Apache Cordova	2011 (PhoneGap 의 ASF 기증)	WebView + 플러그인
Ionic	2013	Cordova / Capacitor + Angular / React / Vue UI
React Native	2015 (Meta)	JS 브릿지 + 네이티브 위젯
NativeScript	2014	JS + 네이티브 직접 접근
Xamarin	2011 (Microsoft 인수 2016)	C# + Mono. 2024 년 EoL
Flutter	2017 (Google)	Dart + 자체 캔버스 (Skia → Impeller)
Capacitor	2019 (Ionic)	WebView 후속, 플러그인 모델 정리
Expo	2015 → React Native 위 워크플로	매니지드 + EAS 빌드
.NET MAUI	2022 (Xamarin 후속)	C# + 플랫폼 핸들러
Kotlin Multiplatform	2018 alpha · 2023 안정	Kotlin 코드 공유, UI 는 Compose Multiplatform 또는 네이티브
Tauri Mobile	2024 alpha	WebView + Rust 코어. 데스크탑 Tauri 의 모바일 확장

2. 세 모델

WebView 에 얹기 — 브라우저 엔진을 앱 안에 띄우고 그 위에 웹 앱을 그림. iOS WKWebView · Android WebView 가 무대.

• Cordova / Capacitor — 웹 앱 + 네이티브 플러그인 브릿지.
• Ionic — Capacitor + UI 키트.
• Tauri Mobile — WebView + Rust 코어로 OS 호출.

장점 — 웹 기술 (HTML · CSS · JS) 을 그대로. 번들이 비교적 작음. 동일 코드를 데스크탑 · 웹과 공유 쉬움. 한계 — 네이티브 위젯의 미세한 모양 · 동작과 차이. 무거운 애니메이션 · 복잡한 제스처에서 지연 가능. iOS 의 WebView 정책 · Push Notification 한정.

자바스크립트 브릿지 + 네이티브 위젯 — JS 런타임에서 작성된 코드가 네이티브 UI 위젯을 조립.

• React Native — JS → 네이티브 컴포넌트. 새 아키텍처 (Fabric · TurboModules · JSI) 가 브릿지 비용을 줄임.
• NativeScript — JS 가 네이티브 API 를 직접 호출.

장점 — 네이티브 UI 의 모양 · 동작. React 생태계 (RN). 한계 — 플랫폼별 차이가 있는 부분은 결국 네이티브 코드 분기. 빌드 환경 (Xcode · Android SDK) 가 여전히 필요. 라이브러리 호환성.

자체 캔버스에 직접 렌더 — 플랫폼 위젯을 쓰지 않고 자체 그래픽 엔진으로 모든 픽셀을 그림.

• Flutter — Skia → Impeller 로 직접 렌더. Material · Cupertino 위젯도 내부에서 그림.

장점 — 픽셀 단위 일관성. 60 / 120 fps 애니메이션이 자연스러움. 핫 리로드의 부드러움. 한계 — 플랫폼이 새 위젯을 도입하면 따라가야 함. 접근성 · 플랫폼 통합 (시스템 공유 시트) 은 별도 구현 필요. 번들 크기가 다른 모델보다 큼.

3. 매트릭스

도구	언어	렌더링	장점	한계
React Native	JS / TS	네이티브 위젯	React 생태계 · UI 익숙	네이티브 모듈 호환 이슈
Flutter	Dart	자체 캔버스	일관성 · 성능	큰 번들 · Dart 학습
Capacitor / Ionic	JS / TS	WebView	웹 코드 공유	WebView 한계
Expo	JS / TS	RN 위	빌드 · 배포 자동화	매니지드의 제약 (EAS 로 완화)
Tauri Mobile	JS / TS + Rust	WebView	작은 번들 · Rust 안전성	모바일은 알파 단계
Kotlin Multiplatform	Kotlin	네이티브 또는 Compose	코드 공유 + 네이티브 UI 가능	UI 까지 공유는 추가 도구 필요
.NET MAUI	C#	네이티브 핸들러	C# 생태계 · Visual Studio	작은 커뮤니티
네이티브 (Swift · Kotlin)	Swift · Kotlin	네이티브	최고 통합 · 접근성	두 코드베이스

4. 결정 요인

어떤 사용자에게 어떤 경험인가:

• 두 OS 의 미세한 모양 차이가 사업 가치인가 (네이티브 또는 RN).
• 일관된 픽셀이 중요한가 (Flutter).
• 웹과 코드를 공유하고 싶은가 (WebView 계열).

팀의 기술 스택:

• React 팀 — RN.
• Vue · Angular — Capacitor + Ionic.
• C# — MAUI.
• Kotlin / Java — KMP 또는 네이티브.
• Rust 친화 — Tauri Mobile (단, 알파 단계).

빌드 · 배포 — 매니지드 (Expo EAS · Codemagic · Bitrise) 가 빌드 환경 운영 부담을 줄임. 네이티브 Xcode / Android Studio 직접 운영은 자유도 높지만 인프라 부담.

라이브러리 가용성 — 결제 (IAP) · 푸시 · 카메라 · 블루투스 같은 핵심 모듈의 라이브러리 성숙도 점검.

접근성 · 국제화 — 자체 캔버스 도구는 OS 의 접근성 트리에 별도 매핑이 필요. 일반적으로 네이티브 위젯이 강함.

5. 운영 측면

iOS 빌드의 macOS 의무 — iOS 앱을 만들려면 Xcode 가 필요하고, macOS 에서만 동작. Windows · Linux 개발자는:

• macOS 가상 머신 또는 Mac mini 빌드 서버.
• 클라우드 빌드 서비스 (EAS · Codemagic · Bitrise · GitHub Actions macOS runner).

Android 빌드는 Windows · Mac · Linux 모두 가능.

코드 사이닝:

• iOS — Apple Developer 계정 + 인증서 + 프로비저닝 프로파일.
• Android — keystore + Play App Signing.

자세한 자리는 03-android-build-apk.

OTA (Over-The-Air) 업데이트 — 자바스크립트 코드만 바꿔 사용자 단말에 업데이트를 푸시하는 모델. App Store · Play Store 의 정책 안에서 허용 범위:

• Expo Updates / EAS Update.
• CodePush (Microsoft, 2024 년 종료 선언 → 마이그레이션 필요).
• expo-updates · self-hosted.

플랫폼 정책상 비즈니스 로직은 변경 가능하지만 앱의 본질적 기능 변경은 스토어 리뷰 대상.

6. 자주 걸리는 자리

결제 · 구독 — iOS App Store 와 Google Play 의 IAP 수수료 정책이 사업 모델을 좌우.

앱 스토어 리뷰 — 첫 제출 시 거절 사유는 개인정보 처리방침 · 테스트 계정 · 기능 명료성.

권한 모델 — iOS 와 Android 의 권한 시점 · 문구가 다름. 사용자 거부 후 재요청 흐름 다름.

백그라운드 처리 — 두 OS 모두 절전 정책이 강해 정기 작업 · 로케이션이 의도대로 안 동작하는 경우가 흔함.

푸시 알림 — iOS 의 백그라운드 데이터 메시지 신뢰성 한계.

버전 분화 — iOS 는 빠른 채택, Android 는 OS 버전 다양성. minSdk 결정의 영향.

OS 업데이트의 호환성 깨짐 — 매년 Apple · Google 이 새 SDK 를 발표하며 일부 라이브러리가 깨짐. 라이브러리 유지보수 활동성 점검.

로컬화 · 법규 — GDPR · 개인정보보호법 · 어린이 데이터 정책 (COPPA). 글로벌 출시 시 사전 검토.

하고픈 말

크로스플랫폼 도구는 시기마다 답이 다름. WebView · JS 브릿지 · 자체 캔버스 셋의 트레이드오프를 환경에 맞춰 고르는 결정이 핵심. 팀의 기술 스택 + 빌드 인프라 + 라이브러리 가용성이 실제 결정의 무게추. 네이티브가 절대적 답인 시대는 아니지만 미세한 차이가 사업 가치인 자리는 여전히 네이티브.

Next

• flutter-basics
• android-build-apk

React Native 공식 · Flutter 공식 · Capacitor 공식 · Tauri 공식 · Kotlin Multiplatform · .NET MAUI 공식 · Apple Developer App Store Review · Google Play 정책 센터 를 참고합니다.