- Published on
모바일 개발 2026 완벽 가이드 — Swift 6 · SwiftUI 6 · Kotlin Multiplatform · Jetpack Compose · Flutter 4 · React Native 0.78 · Expo SDK 53 심층 분석
- Authors

- Name
- Youngju Kim
- @fjvbn20031
"한쪽엔 Apple Intelligence를 도입하느라 App Intents부터 다시 짜는 iOS 팀이 있고, 다른 쪽엔 Compose Multiplatform으로 iOS·Android 코드를 80% 공유하기 시작한 Kotlin 팀이 있다. 2026년 모바일은 '한 가지 답'이 사라진 시기다." — Stack Overflow Developer Survey, 2025
모바일 개발은 2020년 SwiftUI 1.0과 Jetpack Compose 1.0이 발표된 뒤 6년 만에 완전히 다른 풍경이 되었습니다. 두 진영 모두 선언형 UI로 옮겨갔고, Kotlin Multiplatform은 2024년 11월 정식 안정화 이후 Compose Multiplatform 1.7까지 오면서 "iOS·Android·Desktop·Web을 한 코드로"가 현실이 되었습니다. 한편 Flutter는 4.x에서 Impeller 렌더러를 전면 적용했고, React Native 0.78은 New Architecture(Fabric + TurboModules + Hermes)를 기본값으로 끌어올렸습니다.
2026년 5월 현재, 모바일 개발은 다섯 진영으로 분화되었습니다 — 네이티브 우선(Swift 6 + Kotlin), 크로스플랫폼 네이티브(KMP + Compose Multiplatform), 자체 렌더러(Flutter), JS 브릿지(React Native + Expo), 웹 컨테이너(Capacitor + Ionic + Tauri Mobile). 그리고 그 위에 Apple Intelligence·Health Connect·DMA 마켓플레이스 같은 OS·정책 레벨 변화가 겹쳐 있습니다. 이 글에서는 Swift 6 + SwiftUI 6, Kotlin Multiplatform 2, Jetpack Compose, Flutter 4, React Native 0.78, Expo SDK 53, Capacitor 6, .NET MAUI, Tauri Mobile 2, 그리고 Fastlane·EAS·RevenueCat·Firebase까지 한 번에 정리합니다.
1. 2026년 모바일 개발 지도 — 다섯 진영으로 분화한 생태계
2026년의 모바일 프레임워크는 크게 다섯 카테고리로 나눌 수 있습니다.
| 카테고리 | 대표 스택 | 핵심 특징 |
|---|---|---|
| 네이티브 우선 | Swift 6 + SwiftUI 6, Kotlin + Jetpack Compose | OS 신기능 즉시 사용, 최고의 성능과 UX |
| 크로스 네이티브 | Kotlin Multiplatform 2 + Compose Multiplatform 1.7 | 비즈니스 로직·UI 공유, 네이티브 빌드 산출물 |
| 자체 렌더러 | Flutter 4 (Impeller) | 한 코드 한 픽셀, OS 컴포넌트와 무관한 UI |
| JS 브릿지 | React Native 0.78 + Expo SDK 53 | 웹 인재 재활용, OTA 업데이트, Fabric/TurboModules |
| 웹 컨테이너 | Capacitor 6 + Ionic, Tauri Mobile 2, .NET MAUI | 웹 자산을 패키징, PWA 친화 |
핵심 통찰은 "플랫폼 선택은 더 이상 성능이 아니라 채용·코드 공유·OS 신기능 접근성" 이라는 것입니다. Flutter도 Impeller 이후 60fps를 안정적으로 뽑고, React Native도 New Architecture에서 네이티브 못지않은 응답성을 보입니다. 그래서 선택 기준은 "팀에 어떤 인재가 있는가, 얼마나 빨리 OS 신기능을 따라가야 하는가, 코드 공유 비율을 얼마나 끌어올리고 싶은가" 같은 조직적 질문으로 옮겨갔습니다.
2. Swift 6 + Xcode 16 — Approachable Concurrency의 시대
Swift 6.0(2024.9)과 Xcode 16(2024.9)은 Swift Concurrency를 "선택"에서 "기본"으로 끌어올렸습니다. 2026년 5월 현재 Swift 6.2까지 릴리스됐고, 핵심 변화는 세 가지입니다.
첫째, Strict Concurrency Checking이 기본 활성화됐습니다. Sendable 위반과 actor 격리 위반이 컴파일 에러로 잡힙니다. 둘째, Approachable Concurrency(Swift 6.2의 새 모드)는 단일 스레드 환경을 기본으로 두고, 명시적으로 async를 도입하게 유도합니다. UIKit·SwiftUI 기반 앱은 MainActor 격리가 자동으로 적용되므로 동시성 입문 난이도가 크게 낮아졌습니다. 셋째, typed throws(throws(MyError))가 안정화되어 에러 타입을 명시할 수 있습니다.
// Swift 6 — Approachable Concurrency + Observation
import SwiftUI
import Observation
@Observable
final class UserStore {
var users: [User] = []
var isLoading = false
func load() async throws(NetworkError) {
isLoading = true
defer { isLoading = false }
let url = URL(string: "https://api.example.com/users")!
let (data, _) = try await URLSession.shared.data(from: url)
users = try JSONDecoder().decode([User].self, from: data)
}
}
struct UsersView: View {
@State private var store = UserStore()
var body: some View {
List(store.users) { user in
Text(user.name)
}
.task {
try? await store.load()
}
}
}
@Observable 매크로는 기존 ObservableObject + @Published를 대체하며, SwiftUI가 자동으로 의존하는 프로퍼티만 추적해 불필요한 리렌더를 줄입니다. 2026년에는 신규 SwiftUI 코드는 거의 모두 @Observable로 작성됩니다.
3. SwiftUI 6 + UIKit — 선언형 일원화의 마침표
SwiftUI 6(iOS 18, 2024)과 SwiftUI 6.x(iOS 19 베타, 2025)는 그간 부족하다고 지적받던 영역을 대부분 메웠습니다. ScrollView API가 정교해졌고(.scrollPosition, .scrollTargetBehavior), MeshGradient·PaletteSelectionEffect 같은 시각 효과가 추가됐고, 텍스트 입력 필드의 한·일 IME 처리가 안정화됐습니다.
UIKit과의 상호운용도 더 매끄러워졌습니다. UIHostingController, UIViewRepresentable은 그대로지만, TipKit·App Intents·WidgetKit·ActivityKit처럼 시스템 통합이 필요한 영역은 모두 SwiftUI 우선으로 설계되었습니다. 2026년 새 iOS 앱은 UIKit으로 시작하는 사례가 거의 사라졌고, 기존 UIKit 앱도 신규 화면은 SwiftUI로 작성하는 흐름이 일반적입니다.
iPad·visionOS도 같은 SwiftUI 코드 위에서 동작하므로, "iOS·iPadOS·visionOS·macOS·watchOS·tvOS"의 코드 공유가 실제로 가능해졌습니다. Apple의 자체 발표에 따르면 SwiftUI 사용 비율은 2025년 신규 앱 기준 75%를 넘어섰습니다.
4. SwiftData + Core ML + Vision — 데이터와 ML의 표준화
SwiftData(iOS 17, 2023~)는 Core Data의 후속 프레임워크로, @Model 매크로로 영속화 모델을 선언합니다. 2026년에는 SwiftData 2(iOS 19)에서 CloudKit 동기화·History Tracking·Composite Indexes·Lightweight Migration이 안정화됐습니다.
Core ML은 Apple Intelligence와 통합되어 온디바이스 LLM(Foundation Models framework)을 노출합니다. iOS 18.1+ 디바이스에서 LanguageModelSession을 통해 약 3B 파라미터의 온디바이스 모델을 호출할 수 있고, Private Cloud Compute로 더 큰 모델로 위임이 가능합니다. Vision 프레임워크는 이미지·텍스트·바코드·신체·손 인식을 제공하고, Translation framework(iOS 17.4+)는 18개 언어쌍 오프라인 번역을 제공합니다.
// SwiftData + Apple Intelligence — 온디바이스 요약 생성
import SwiftData
import FoundationModels
@Model
final class Note {
var title: String
var body: String
var summary: String?
var createdAt: Date
init(title: String, body: String) {
self.title = title
self.body = body
self.createdAt = .now
}
}
@MainActor
func generateSummary(for note: Note) async throws {
let session = LanguageModelSession()
let response = try await session.respond(
to: "Summarize in 2 sentences:\n\(note.body)"
)
note.summary = response.content
}
5. Kotlin Multiplatform 2 — 정식 안정화의 충격
Kotlin Multiplatform(과거 KMM)은 2024년 11월 Kotlin 2.0과 함께 정식 안정화(GA)됐습니다. 2026년 5월 현재 Kotlin 2.1.x가 표준이며, K2 컴파일러가 기본입니다. KMP의 핵심 가치는 "비즈니스 로직(네트워크·DB·도메인)을 Kotlin으로 작성해 iOS·Android·Desktop·Web에 공유하되, UI는 각 플랫폼 네이티브로 유지"입니다.
iOS 산출물은 Objective-C/Swift framework로 만들어져 Xcode에서 그대로 임포트할 수 있고, Android에서는 일반 Kotlin 모듈로 동작합니다. JetBrains는 Compose Multiplatform 1.7(2025)에서 iOS 타깃을 정식 안정화했고, 이제 UI까지 공유하는 옵션이 생겼습니다.
// commonMain — iOS와 Android가 공유하는 비즈니스 로직
import io.ktor.client.*
import io.ktor.client.call.*
import io.ktor.client.plugins.contentnegotiation.*
import io.ktor.serialization.kotlinx.json.*
import kotlinx.serialization.Serializable
@Serializable
data class User(val id: Long, val email: String, val name: String)
class UserRepository {
private val client = HttpClient {
install(ContentNegotiation) { json() }
}
suspend fun fetchUsers(): List<User> =
client.get("https://api.example.com/users").body()
}
Coupang, Toss, Karrot, Baemin, Kakao는 모두 2024~2025년 사이 KMP 도입을 공개했고, 2026년에는 신규 앱의 사실상 표준 아키텍처가 됐습니다.
6. Compose Multiplatform 1.7 — UI까지 공유하는 옵션
Compose Multiplatform(JetBrains)은 Android의 Jetpack Compose 런타임을 Kotlin/Native(iOS), JS/Wasm(Web), JVM(Desktop)으로 포팅한 것입니다. 1.7(2025.5)에서 iOS 안정화·접근성·텍스트 입력·내비게이션·리소스 관리가 모두 production-ready 레벨로 올라왔습니다.
장점: iOS·Android UI 코드 공유율이 90%를 넘기는 사례가 흔합니다. 단점: iOS에서는 SwiftUI 컴포넌트와 자연스럽게 섞이지 않아 "한 화면이 통째로 Compose"가 되거나 "한 화면이 통째로 SwiftUI"가 되는 경향이 있습니다. 2026년 5월 현재 Kakao, NHN, JetBrains 자체 Toolbox 앱, Wakanda 같은 프로덕트가 Compose Multiplatform iOS를 프로덕션에 쓰고 있습니다.
// Compose Multiplatform 1.7 — iOS와 Android에 공유되는 UI
import androidx.compose.foundation.layout.*
import androidx.compose.material3.*
import androidx.compose.runtime.*
@Composable
fun UsersScreen(repo: UserRepository) {
var users by remember { mutableStateOf<List<User>>(emptyList()) }
LaunchedEffect(Unit) { users = repo.fetchUsers() }
Scaffold(topBar = { CenterAlignedTopAppBar(title = { Text("Users") }) }) { padding ->
Column(modifier = Modifier.padding(padding)) {
users.forEach { user ->
ListItem(headlineContent = { Text(user.name) })
}
}
}
}
7. Jetpack Compose 1.8 — Strong Skipping과 예측 가능한 뒤로가기
Android Jetpack Compose는 2024년 1.7, 2025년 1.8을 거치며 핵심 성능 이슈를 해소했습니다. Strong Skipping Mode는 안정성을 알 수 없는 파라미터까지 자동으로 건너뛰게 만들어, @Stable 어노테이션 없이도 리컴포지션이 줄어듭니다. Predictive Back(Android 14+)은 사용자가 뒤로가기 제스처를 시작했을 때 다음 화면을 미리 렌더해, iOS의 인터랙티브 dismiss와 비슷한 경험을 만듭니다.
Material 3 Expressive(2025 Google I/O)는 색상·모션·타이포그래피를 더 표현적으로 확장한 디자인 시스템입니다. ColorScheme이 풍부해지고, MotionScheme이 추가됐으며, 새 컴포넌트(FloatingToolbar, Carousel, LoadingIndicator)가 들어왔습니다.
// Jetpack Compose 1.8 + Material 3 Expressive
@Composable
fun UsersScreen(viewModel: UsersViewModel = hiltViewModel()) {
val uiState by viewModel.uiState.collectAsStateWithLifecycle()
Scaffold(
topBar = { CenterAlignedTopAppBar(title = { Text("Users") }) }
) { padding ->
when (val state = uiState) {
is UiState.Loading -> LoadingIndicator(Modifier.padding(padding))
is UiState.Success -> LazyColumn(contentPadding = padding) {
items(state.users, key = { it.id }) { user ->
ListItem(
headlineContent = { Text(user.name) },
supportingContent = { Text(user.email) }
)
}
}
is UiState.Error -> ErrorView(state.message, onRetry = viewModel::retry)
}
}
}
Baseline Profiles와 Macrobenchmark 통합으로 첫 화면 렌더 시간(LCP)을 25~40% 줄일 수 있고, 신규 Android 앱은 사실상 Compose로 시작합니다.
8. Flutter 4 — Impeller 전면 적용
Flutter 4.0(2025)은 Impeller 렌더러를 iOS·Android·Desktop 모두에 기본으로 만든 첫 메이저 릴리스입니다. 기존 Skia 기반에서 일어나던 셰이더 컴파일 jank가 사라지고, Vulkan/Metal을 직접 활용해 60·90·120fps를 안정적으로 뽑습니다. Dart 3.5+의 패턴 매칭과 records, class modifiers가 표준 코드 스타일로 자리잡았습니다.
Flutter의 장점은 변하지 않았습니다 — 자체 렌더러로 인해 iOS·Android·Web·Desktop·Embedded에서 픽셀 단위 동일성. 단점은 OS 네이티브 룩앤필을 흉내내야 한다는 점이고, Cupertino 위젯 셋이 매년 업데이트되지만 100% 일치는 어렵습니다.
// Flutter 4 + Riverpod 2 — 비동기 상태 관리
import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
final usersProvider = FutureProvider<List<User>>((ref) async {
final repo = ref.read(userRepoProvider);
return repo.fetchUsers();
});
class UsersScreen extends ConsumerWidget {
const UsersScreen({super.key});
Widget build(BuildContext context, WidgetRef ref) {
final users = ref.watch(usersProvider);
return Scaffold(
appBar: AppBar(title: const Text('Users')),
body: users.when(
data: (list) => ListView.builder(
itemCount: list.length,
itemBuilder: (_, i) => ListTile(title: Text(list[i].name)),
),
loading: () => const Center(child: CircularProgressIndicator()),
error: (e, _) => Center(child: Text('Error: $e')),
),
);
}
}
Google·Alibaba·BMW·ByteDance·eBay가 Flutter를 프로덕션에 쓰며, 한국에서는 우아한형제들 일부 앱, 일본에서는 ZOZO·CyberAgent가 도입했습니다.
9. React Native 0.78 — New Architecture가 기본값
React Native 0.78(2025)은 New Architecture(Fabric + TurboModules + Hermes) 를 기본 활성화한 첫 릴리스입니다. JSI(JavaScript Interface) 기반의 동기 호출, Concurrent Renderer 호환, JSC 대신 Hermes 기본화로 시작 시간이 30~40% 줄어들었습니다.
2026년 5월 현재 React Native 0.79까지 릴리스됐고, Meta는 자사 앱(Facebook·Instagram·Threads) 대부분의 화면을 RN으로 운영하고 있습니다. Microsoft Office·Discord·Shopify·Tesla·Coinbase가 대표적 도입 사례입니다.
// React Native 0.78 — 함수형 컴포넌트와 TurboModule
import { useEffect, useState } from 'react'
import { FlatList, Text, View, StyleSheet } from 'react-native'
type User = { id: number; name: string; email: string }
export default function UsersScreen() {
const [users, setUsers] = useState<User[]>([])
const [loading, setLoading] = useState(true)
useEffect(() => {
fetch('https://api.example.com/users')
.then((r) => r.json())
.then((data) => setUsers(data))
.finally(() => setLoading(false))
}, [])
if (loading) return <Text>Loading...</Text>
return (
<FlatList
data={users}
keyExtractor={(u) => String(u.id)}
renderItem={({ item }) => (
<View style={styles.row}>
<Text style={styles.name}>{item.name}</Text>
<Text>{item.email}</Text>
</View>
)}
/>
)
}
const styles = StyleSheet.create({
row: { padding: 16, borderBottomWidth: 1, borderBottomColor: '#eee' },
name: { fontWeight: 'bold', fontSize: 16 },
})
단점도 명확합니다. 네이티브 모듈을 직접 작성해야 할 때 New Architecture로 마이그레이션해야 하고, 일부 서드파티 라이브러리는 아직 New Arch 대응이 늦습니다.
10. Expo SDK 53 — React Native의 사실상 표준 도구체인
Expo는 React Native의 빌드·배포·API 어려움을 해결한 도구체인입니다. 2026년에는 SDK 53(2025.5)이 표준이며, Expo Router 5(파일 기반 라우팅, Next.js와 유사), EAS Build(클라우드 빌드), EAS Update(OTA), EAS Submit(스토어 자동 제출), Expo DOM Components(웹뷰 임베딩) 같은 기능이 핵심입니다.
Microsoft의 App Center 일몰(2025.3)로 OTA 업데이트는 사실상 EAS Update + CodePush 후속 또는 자체 구축으로 갈렸고, 대부분의 RN 팀이 EAS Update를 선택했습니다.
11. Capacitor 6 + Ionic — 웹 컨테이너의 현실적인 선택
Capacitor(Ionic 팀, 2018~)는 Cordova의 후속으로 등장한 웹 컨테이너입니다. 2026년 5월 기준 Capacitor 6이 표준이며, iOS 기본 WKWebView, Android 기본 WebView(또는 GeckoView 옵션) 위에 네이티브 플러그인 시스템을 얹습니다. Vue·React·Angular 같은 웹 프레임워크 코드를 그대로 모바일 패키지로 만들 수 있고, PWA로도 같은 코드를 배포할 수 있습니다.
성능은 네이티브에 미치지 못하지만 사내 앱·콘텐츠 앱·관리자 앱에서는 충분합니다. Burger King, Southwest Airlines, Sworkit가 대표적 도입 사례입니다.
12. Tauri Mobile 2 + .NET MAUI + NativeScript — 변두리지만 살아있는 선택지
Tauri Mobile 2(2024)는 Rust로 만들어진 데스크톱 프레임워크 Tauri의 모바일 확장입니다. WebView 기반이지만 Rust 백엔드로 무거운 작업을 위임할 수 있어, 보안·소형 바이너리를 중시하는 팀이 채택합니다.
.NET MAUI(.NET 9, 2024.11)는 Xamarin.Forms의 후속으로 Microsoft가 밀고 있는 크로스플랫폼 UI 프레임워크입니다. .NET 9에서 안정성이 크게 개선됐고, Blazor Hybrid를 함께 쓸 수 있어 .NET 풀스택 팀에게 매력적입니다.
NativeScript 8은 JavaScript/TypeScript로 진짜 네이티브 UI를 호출하는 프레임워크입니다. 시장 점유율은 작지만 Vue·Angular 통합이 좋습니다.
13. 네이티브 vs 크로스플랫폼 — 의사결정 매트릭스
| 기준 | 네이티브(Swift+Kotlin) | KMP+CMP | Flutter | RN+Expo | Capacitor |
|---|---|---|---|---|---|
| 성능·반응성 | 최고 | 최고 | 매우 좋음 | 좋음 | 보통 |
| OS 신기능 접근성 | 즉시 | 1~3개월 | 6~12개월 | 3~6개월 | 가변 |
| 코드 공유율 | 0% | 60~90% | 95%+ | 90%+ | 95%+ |
| 학습 곡선 | 높음(2개 언어) | 중상 | 중(Dart) | 낮음(JS/TS) | 낮음 |
| 채용 풀 | 작음 | 중 | 중 | 큼 | 큼 |
| 빌드 시간 | 보통 | 김 | 짧음 | 짧음 | 매우 짧음 |
| 앱 크기 | 작음 | 중 | 큼 | 중 | 작음 |
| 디자인 일관성 | OS별 다름 | OS별 다름 | 같음 | 가변 | 같음 |
결국 답은 "규모가 큰 앱이면 네이티브 또는 KMP, MVP/B2B 내부 앱이면 Flutter/RN/Capacitor"로 수렴합니다.
14. iOS 전용 — Apple Intelligence와 App Intents의 부상
Apple Intelligence(iOS 18.1+, 2024.10)는 iOS 앱이 시스템 LLM·이미지 생성·요약과 통합되는 새 진입점을 만듭니다. App Intents는 Siri·Spotlight·Shortcuts·홈 화면 위젯에서 앱 기능을 호출하게 해주고, 2025년부터는 Apple Intelligence가 자동으로 사용자 의도와 매칭합니다.
TipKit(iOS 17+)은 앱 안에서 기능 안내 툴팁을 만드는 표준 API입니다. ActivityKit은 Live Activities·Dynamic Island를 통한 실시간 상태 표시를, WidgetKit은 홈/잠금/Lock Screen 위젯을, RoomPlan은 LiDAR 기반 실내 3D 스캔을 제공합니다.
15. Android 전용 — Health Connect와 Credential Manager
Health Connect(2023, Android 14+ 기본)는 Google Fit과 Samsung Health 데이터를 통합하는 단일 API입니다. Credential Manager는 비밀번호·passkey·연합 인증을 한 다이얼로그로 통합하고, 2025년부터 Android 14+에서 사실상 표준 로그인 UX가 됐습니다.
Privacy Sandbox on Android(2025 정식)는 모바일 광고 ID(AAID) 대체 기술이고, App Bundle + Baseline Profiles + Macrobenchmark 조합은 첫 화면 렌더 시간을 25~40% 줄여줍니다. Predictive Back(Android 14+)은 사용자 경험을 매끄럽게 만듭니다.
16. 앱 스토어 변화 — DMA와 대체 마켓플레이스
2024년 3월 발효된 EU 디지털 시장법(DMA) 으로 iOS는 EU 사용자에 한해 대체 앱 마켓플레이스를 허용하기 시작했습니다. Setapp Mobile(MacPaw), AltStore PAL, Epic Games Store가 대표적이고, 개발자는 Core Technology Fee(CTF) 대신 새 사업 조건(2024.5 갱신)을 선택할 수 있습니다.
미국에서도 Epic v. Apple 판결로 외부 결제 링크 허용이 일부 진척됐고, 2025년에는 외부 결제 비율이 늘면서 In-App Purchase 의존도가 다소 약해졌습니다. Android는 EU에서 Google Play 외 사이드로드를 명시적으로 허용했고, Samsung Galaxy Store · Huawei AppGallery · OneStore(한국 통신3사)도 여전히 일정 점유를 유지합니다.
17. 인앱 결제 — Apple IAP · Google Play Billing · RevenueCat · Adapty
iOS의 In-App Purchase(StoreKit 2) 와 Android의 Google Play Billing 7.x가 표준입니다. 둘 다 구독·자동 갱신·offer code·family sharing을 지원하지만 API가 다르고, 영수증 검증·환불·grace period 처리도 복잡합니다.
이걸 추상화하는 SaaS가 RevenueCat·Adapty입니다. SDK 한 줄로 양 플랫폼 결제·영수증 검증·서버 백오피스·분석을 통합해주고, 2026년에는 신규 앱의 80%가 둘 중 하나를 쓰는 분위기입니다. RevenueCat은 2024년 Series C(60M), Adapty는 2023년 Series A(15M)로 성장 가도를 달리고 있습니다.
18. 분석·CRM — Firebase · Amplitude · Mixpanel · AppsFlyer · Branch
Firebase Analytics + Crashlytics가 압도적 표준이지만, 정밀 분석은 Amplitude·Mixpanel, 어트리뷰션은 AppsFlyer·Adjust·Branch가 각자 자리를 잡았습니다. SKAdNetwork 4(iOS 16.1+)·Privacy Sandbox 시대에 어트리뷰션 정확도는 떨어졌지만, 컨버전 윈도우·컴파스 메트릭으로 보완합니다.
Microsoft App Center는 2025년 3월 일몰됐고, 그 자리를 Firebase + Sentry + Bugsnag이 메웠습니다. Sentry는 React Native·Flutter·Native iOS·Android 모두에 SDK를 제공하고, 소스맵·심볼리케이션·세션 리플레이를 통합합니다.
19. 모바일 CI/CD — Fastlane · Bitrise · Codemagic · EAS · Xcode Cloud · GitHub Actions
Fastlane(2014~)은 여전히 사실상 표준으로, 빌드·서명·스토어 업로드 자동화의 단일 진입점입니다. 그 위에 클라우드 빌드 서비스가 얹힙니다.
# Fastlane 표준 패턴 — Fastfile
default_platform(:ios)
platform :ios do
desc "Push a beta build to TestFlight"
lane :beta do
increment_build_number(xcodeproj: "MyApp.xcodeproj")
build_app(scheme: "MyApp")
upload_to_testflight(skip_waiting_for_build_processing: true)
end
desc "Release a build to the App Store"
lane :release do
capture_screenshots
build_app(scheme: "MyApp")
upload_to_app_store(submit_for_review: true)
end
end
# fastlane beta 로 실행
Bitrise는 워크플로우 기반 클라우드 CI로 모바일 전용, Codemagic은 Flutter에 강하고, EAS Build/Submit은 React Native/Expo의 표준, Xcode Cloud는 Apple 공식이지만 가격이 비싸고, GitHub Actions는 self-hosted runner와 함께 가성비가 좋습니다.
20. 모바일 보안 — App Attest · Play Integrity · ProGuard/R8
App Attest(iOS 14+)는 디바이스 무결성 토큰을 발급해 서버에서 검증할 수 있게 하고, Play Integrity API는 같은 역할을 Android에서 합니다. 2025년부터 양 플랫폼 모두 게임·결제·금융 앱에서 사실상 필수가 됐습니다.
코드 난독화는 Android의 R8(ProGuard 후속)이 표준이고, iOS는 SwiftShield·자체 빌드 스크립트가 일반적입니다. 통신 보안은 certificate pinning(TrustKit, OkHttp CertificatePinner)이 권장됩니다.
21. 디자인 시스템 — Material 3 Expressive · Apple Liquid Glass · Tailwind for Native
Material 3 Expressive(2025)는 Material Design의 표현성을 끌어올린 업데이트입니다. Apple HIG는 2024년 iOS 18에서 컨트롤 센터·홈 화면 위젯 가이드를 갱신했고, 2025년 발표된 Liquid Glass(개념)는 시각 효과의 다음 방향성을 제시합니다.
크로스플랫폼에서는 Tailwind CSS의 영향을 받은 NativeWind(React Native), Tailwind for Compose, shadcn/ui for React Native 같은 라이브러리가 빠르게 성장 중입니다. 디자인 시스템 도구로는 Figma + Tokens Studio가 사실상 표준이고, Storybook for React Native와 Lookbook for Flutter가 컴포넌트 갤러리로 쓰입니다.
22. 한국 모바일 씬 — KMP의 본진
한국 모바일은 2024~2025년 사이 일제히 Kotlin Multiplatform + Compose Multiplatform 도입을 공개했습니다. Coupang은 자사 컨퍼런스에서 KMP 기반 공통 모듈을 발표했고, Toss는 결제·인증·송금 로직을 KMP로 공유합니다. 당근(Karrot) 은 채팅·피드 일부를 KMP로 옮겼고, 배달의민족은 KMP 도입 후기를 블로그로 공개했습니다. Kakao는 KakaoTalk·KakaoBank·KakaoMap에서 KMP를 단계적으로 적용 중이고, NHN은 게임·결제 SDK를 KMP로 통합합니다.
iOS는 여전히 Swift + SwiftUI, Android는 Kotlin + Compose가 표준이지만, 그 사이 공유 레이어로 KMP가 자리잡았다는 점이 가장 큰 변화입니다.
23. 일본 모바일 씬 — Mercari의 Flutter, LINE의 Compose
LINE Yahoo(2023년 합병)는 메신저는 네이티브, 야후 재팬은 점진적 RN/Flutter 전환을 진행 중이고, Compose Multiplatform 검토도 공개했습니다. Mercari는 2019년부터 Flutter 도입을 이어왔고 2025년 메인 앱 일부 흐름을 Flutter로 운영합니다. ZOZO는 Flutter 채택을 공식화했고, freee · Money Forward · SmartHR은 핵심 모바일 앱을 Kotlin + Compose로 운영합니다. Sansan(명함관리)·CARTA(광고)는 Compose Multiplatform iOS PoC를 공개했습니다.
일본은 네이티브 우선 문화가 강하지만, 신규 스타트업은 RN/Expo로 시작하는 비율이 빠르게 늘었습니다.
24. 의사결정 트리 — 어떤 스택을 고를 것인가
- iOS·Android 모두 필요, 팀 전원 모바일 네이티브 — Swift + Kotlin 네이티브
- iOS·Android 모두 필요, 비즈니스 로직 공유 — KMP, UI는 SwiftUI + Compose
- iOS·Android·Desktop·Web 모두 필요, Kotlin 팀 — KMP + Compose Multiplatform
- 한 코드 한 픽셀, 디자인 통일 우선, 팀이 Dart 학습 가능 — Flutter 4
- 웹 팀 인재 활용, 빠른 출시·OTA 필요 — React Native + Expo
- 사내 앱·콘텐츠 앱, PWA 자산 재활용 — Capacitor + Ionic
- .NET 풀스택, Blazor 자산 보유 — .NET MAUI
- Rust 강세, 보안·소형 바이너리 우선 — Tauri Mobile 2
25. 마이그레이션 가이드 — 네이티브 ↔ 크로스플랫폼
UIKit/View → SwiftUI/Compose 전환은 화면 단위로 점진적으로 진행하는 것이 정석입니다. iOS는 UIHostingController, Android는 ComposeView로 기존 화면 안에 신규 UI를 삽입할 수 있습니다. 네이티브 → KMP 마이그레이션은 도메인·네트워크·DB 같은 "UI에서 멀리 있는" 레이어부터 옮기고, ViewModel은 마지막에 옮기는 순서가 안전합니다.
RN/Flutter → 네이티브 전환은 비용이 크므로, 보통 "성능이 중요한 화면만" 네이티브로 빼는 hybrid 전략을 씁니다. RN의 경우 react-native-navigation이나 자체 NativeStackNavigator로 네이티브 화면을 끼워넣을 수 있고, Flutter는 add-to-app 모드로 기존 네이티브 앱에 일부 화면만 Flutter로 작성할 수 있습니다.
26. 마무리 — 2026년 모바일은 다중 진영의 공존
2026년 모바일 개발에는 더 이상 단일 정답이 없습니다. 네이티브 진영은 OS 신기능 접근성과 최고의 UX를, KMP는 비즈니스 로직 공유와 네이티브 UI의 균형을, Flutter는 픽셀 단위 일관성을, React Native는 웹 인재 재활용과 OTA 업데이트를, Capacitor는 PWA 자산 재활용을 각자 다른 자리에서 제공합니다.
그리고 그 위에 Apple Intelligence·Health Connect·DMA 마켓플레이스·Privacy Sandbox 같은 OS·정책 레벨 변화가 겹쳐 있어, 2026년의 모바일 개발자는 "프레임워크 선택보다 시스템 통합 능력"이 더 중요해졌습니다. 어떤 스택을 고르든 한 가지는 분명합니다 — 선언형 UI와 비동기 상태 관리, 그리고 시스템 LLM과의 통합이 앞으로 5년의 표준이 될 것입니다.
References
- developer.apple.com/documentation/swiftui
- developer.apple.com/xcode
- developer.apple.com/documentation/foundationmodels
- developer.apple.com/documentation/swiftdata
- swift.org
- developer.android.com/jetpack/compose
- developer.android.com/health-and-fitness/guides/health-connect
- kotlinlang.org/lp/multiplatform
- github.com/JetBrains/compose-multiplatform
- flutter.dev
- reactnative.dev
- docs.expo.dev
- capacitorjs.com
- v2.tauri.app
- dotnet.microsoft.com/maui
- fastlane.tools
- bitrise.io
- codemagic.io
- revenuecat.com
- adapty.io
- firebase.google.com