Copy English

Why

The premise in the question is right: writing once and running everywhere is the mainstream answer in 2026, not a minority one. React Native and Flutter carry a large share of new consumer apps, Kotlin Multiplatform occupies the conservative middle by sharing logic while leaving UI native, and Expo removed most of the build-tooling tax that used to be the strongest argument against the approach. Choosing native-only for a small team is now a decision that needs a reason, which is a reversal from a few years ago.

The second half of the question is the interesting one, and the honest answer is that the study load does not fall proportionally. A cross-platform framework shares the layer that was already the cheapest to learn: laying out views, holding state, calling an API, navigating between screens. What it does not share is everything the operating system and the app stores own. Permission models differ and change with each OS release. Background execution is not a difference in API but a difference in philosophy, and the two platforms disagree at a design level about what an app may do when it is not on screen. Push has different delivery guarantees on each side. Secure storage is Keychain with the Secure Enclave on one platform and Keystore with StrongBox on the other, and they are not the same guarantee. Store review and payment rules are not code at all.

Which produces the rule this card exists for: you can share the code you write, and you cannot share the code you must obey. The shared half is authored by you and is therefore the half you could always have refactored. The unshared half is policy — OS policy and store policy — and no framework abstracts a rule that a reviewer enforces by reading your app.

For this project specifically the asymmetry is at its worst. A wallet or a settlement client touches key storage, biometric binding, background delivery of settlement events, deep links returning from a browser flow, and the store rules around crypto and payments. Every item on that list is in the unshared column. A content app might share ninety percent of its work; an app whose whole job is the secure element shares the chrome around it. That is not an argument against cross-platform — it is an argument for choosing based on the ratio rather than on the language.

And it answers the complaint about volume directly, because the volume is not what it looks like. The reading list is a function of the surface you touch, not of the number of platforms you ship to. Adding a second platform to an app that only draws screens and calls an API adds very little. Adding a second platform to an app that holds keys adds a second secure-storage model, a second biometric prompt semantics, and a second review process — regardless of how much code is shared. Bound the study by listing the surface first, which is the same instruction as one-page-not-the-curriculum: pull the page you are stuck on, not the next one in order.

How it works

What gets shared, and what never does

The top of the table is the part a framework compresses, and it is the part that was already the cheapest to learn. The bottom of the table is the part that generates the study load, and it is unaffected by the choice.

The self-test, before choosing anything

List the features you will actually ship and mark which half of the table each one lands in. The ratio decides:

This is the same move as choosing-a-chain-is-a-lease in a different domain — the question that looks technical is really about which parts you do not control.

An ordering for the study, since the volume is the actual complaint

1. One platform's permission and lifecycle model, properly. The other platform maps onto it, so the second one costs a fraction of the first. Learning half of each costs more than learning one and then translating.
2. Secure storage and biometrics on both. This is the part that does not map, so it has to be learned twice, and for this project it is the part that matters.
3. The framework last. It is a tool, it is the fastest of the three to learn, and it changes fastest — learning it first means learning it again.

The trade the industry actually settled on

Two stable answers exist rather than one, and they correspond to the two halves of the table. Share everything, including UI is the fast option and is right when the bottom of the table is thin. Share the logic and keep the UI native is the conservative option and is right when platform behaviour is load-bearing. Both are mainstream, which is why the question "is one codebase the trend" has a yes answer that does not settle anything — the trend is real and the decision is still per-app.

Where it lands in Jayverse

• Wallet: budget key storage and biometrics twice, not once. If jayverse-wallet ever ships a mobile companion, treat Keychain/Secure Enclave and Keystore/StrongBox as two separate implementations to write and test, not one cross-platform abstraction.
• Rabbit: table the feature list before picking a mobile framework. Session-key mandate execution and settlement push notifications sit in the unshared column, so list Rabbit's actual mobile features and mark each shared-by-framework or per-platform before choosing React Native, Flutter or KMP.
• Devnet: no action until a mobile client exists. Treat the self-test table as the gate — nothing in Jayverse's current stack changes until a service commits to shipping mobile.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

공유되는 것은 내가 쓴 코드이고, 지켜야 하는 코드는 공유되지 않는다

코드 하나로 모든 플랫폼은 이제 기본값이고, 맞는 기본값입니다. 다만 공유되는 것은 원래 쉬웠던 층입니다 — 권한, 백그라운드 실행, 푸시, 보안 저장소, 생체인증, 스토어 심사는 플랫폼별로 남고, 돈을 다루는 것이라면 거기가 중요한 부분입니다. 공부량은 플랫폼 수가 아니라 건드리는 표면이 정합니다.

아직 범위 미정이고, 1단계는 프로젝트가 아니라 표 하나입니다. 이 프로젝트가 실제로 모바일에 내보낼 기능을 적습니다 — 서명, 키 저장, 생체 잠금 해제, 정산 이벤트 푸시, 브라우저 흐름에서 돌아오는 딥링크 — 그리고 각각을 프레임워크가 공유해 주는 것 / 플랫폼별로 남는 것으로 표시합니다. 그 비율이 곧 크로스플랫폼이 여기서 얼마나 사주는가에 대한 답입니다. 그다음에야 공부 순서: 한 플랫폼의 권한·수명주기 모델을 먼저 깊게(다른 쪽이 그 위에 대응되므로), 양쪽의 보안 저장소·생체인증을 그다음(이건 대응되지 않으므로), 프레임워크를 마지막(도구이고 셋 중 가장 빨리 배웁니다). 프레임워크 사정은 빨리 바뀌므로 React Native New Architecture·Flutter·Kotlin Multiplatform·Expo 의 현재 상태는 요약이 아니라 원문에서 확인하십시오. 이 카드도 요약입니다.

왜

질문의 전제는 맞습니다: 2026년 기준 한 번 쓰고 어디서나 돌리는 방식은 소수파가 아니라 주류입니다. React Native 와 Flutter 가 신규 소비자 앱의 큰 몫을 차지하고, Kotlin Multiplatform 은 로직만 공유하고 UI 는 네이티브로 남기는 보수적 중간을 차지하며, Expo 는 이 접근에 반대하는 가장 강한 논거였던 빌드 툴링 부담을 대부분 없앴습니다. 작은 팀이 네이티브 전용을 고르는 것은 이제 이유가 필요한 결정이고, 이건 몇 년 전과 뒤집힌 상황입니다.

질문의 뒷부분이 흥미롭고, 정직한 답은 공부량이 비례해서 줄지는 않는다는 것입니다. 크로스플랫폼 프레임워크가 공유해 주는 층은 원래 배우기 가장 싼 층입니다 — 뷰 배치, 상태 보관, API 호출, 화면 이동. 공유하지 못하는 것은 운영체제와 앱 스토어가 소유한 전부입니다. 권한 모델은 다르고 OS 릴리스마다 바뀝니다. 백그라운드 실행은 API 차이가 아니라 철학의 차이이고, 두 플랫폼은 앱이 화면 밖에 있을 때 무엇을 해도 되는지에 대해 설계 수준에서 의견이 다릅니다. 푸시는 양쪽의 전달 보장이 다릅니다. 보안 저장소는 한쪽이 Keychain + Secure Enclave, 다른 쪽이 Keystore + StrongBox 이고 같은 보장이 아닙니다. 스토어 심사와 결제 규정은 아예 코드가 아닙니다.

그래서 이 카드가 존재하는 규칙이 나옵니다 — 내가 쓴 코드는 공유되고, 지켜야 하는 코드는 공유되지 않는다. 공유되는 절반은 내가 작성한 것이니 애초에 내가 리팩터링할 수 있었던 절반입니다. 공유되지 않는 절반은 정책입니다 — OS 정책과 스토어 정책 — 그리고 심사자가 앱을 읽어서 집행하는 규칙을 추상화해 주는 프레임워크는 없습니다.

이 프로젝트에서는 그 비대칭이 최악입니다. 지갑이나 정산 클라이언트는 키 저장, 생체 바인딩, 정산 이벤트의 백그라운드 전달, 브라우저 흐름에서 돌아오는 딥링크, 그리고 크립토·결제에 대한 스토어 규정을 건드립니다. 그 목록의 모든 항목이 공유 안 되는 칸에 있습니다. 콘텐츠 앱은 일의 90%를 공유할 수 있지만, 일 자체가 시큐어 엘리먼트인 앱은 그 둘레의 껍데기만 공유합니다. 이건 크로스플랫폼을 쓰지 말라는 논거가 아니라, 언어가 아니라 비율로 고르라는 논거입니다.

그리고 이건 "양이 많다"는 불만에 직접 답합니다. 그 양이 보이는 것과 다르기 때문입니다. 공부 목록은 출시 플랫폼 수가 아니라 건드리는 표면의 함수입니다. 화면만 그리고 API 만 부르는 앱에 두 번째 플랫폼을 더하는 것은 거의 아무것도 더하지 않습니다. 키를 쥐는 앱에 두 번째 플랫폼을 더하는 것은 두 번째 보안 저장소 모델, 두 번째 생체 프롬프트 의미론, 두 번째 심사 과정을 더합니다 — 코드가 얼마나 공유되는지와 무관하게. 표면을 먼저 적어서 공부 범위를 묶으십시오. one-page-not-the-curriculum 과 같은 지시입니다 — 순서상 다음 페이지가 아니라 막힌 페이지를 꺼내라.

동작 방식

공유되는 것과 끝내 안 되는 것

표의 위쪽이 프레임워크가 압축해 주는 부분이고, 원래 배우기 가장 쌌던 부분입니다. 공부량을 만드는 것은 표의 아래쪽이고, 그건 이 선택에 영향받지 않습니다.

고르기 전에 하는 자가진단

실제로 출시할 기능을 적고 각각이 표의 어느 절반에 떨어지는지 표시합니다. 비율이 결정합니다:

choosing-a-chain-is-a-lease 를 다른 도메인으로 옮긴 것과 같은 수입니다 — 기술 질문처럼 보이는 것이 실은 내가 통제하지 못하는 부분에 대한 질문입니다.

공부 순서 — 정작 불만이 "양"이므로

1. 한 플랫폼의 권한·수명주기 모델을 제대로. 다른 플랫폼이 그 위에 대응되므로 두 번째는 첫 번째의 일부 비용만 듭니다. 양쪽을 절반씩 배우면 하나를 배우고 번역하는 것보다 비쌉니다.
2. 양쪽의 보안 저장소·생체인증. 이건 대응되지 않으므로 두 번 배워야 하고, 이 프로젝트에서는 중요한 바로 그 부분입니다.
3. 프레임워크는 마지막. 도구이고, 셋 중 가장 빨리 배우며, 가장 빨리 바뀝니다 — 먼저 배우면 다시 배우게 됩니다.

업계가 실제로 정착한 트레이드

답이 하나가 아니라 둘이고, 표의 두 절반에 대응합니다. UI 까지 전부 공유는 빠른 선택이고 표 아래쪽이 얇을 때 맞습니다. 로직만 공유하고 UI 는 네이티브는 보수적 선택이고 플랫폼 동작이 하중을 받을 때 맞습니다. 둘 다 주류이고, 그래서 "코드 하나가 유행인가"라는 질문의 예 라는 답은 아무것도 결정해 주지 않습니다 — 유행은 진짜이고, 결정은 여전히 앱마다입니다.

Jayverse에서의 위치

• Wallet: 키 저장과 생체인증은 한 번이 아니라 두 번 예산을 잡는다. jayverse-wallet이 모바일 동반 앱을 낸다면 Keychain/Secure Enclave와 Keystore/StrongBox를 하나의 크로스플랫폼 추상화가 아니라 각각 작성하고 테스트해야 할 별도 구현으로 다룬다.
• Rabbit: 모바일 프레임워크를 고르기 전에 기능 목록부터 표로 만든다. 세션 키 위임 실행과 정산 푸시 알림은 공유되지 않는 칸에 속하므로, React Native, Flutter, KMP를 고르기 전에 Rabbit의 실제 모바일 기능을 나열하고 각각 프레임워크로 공유되는지 플랫폼별인지 표시한다.
• Devnet: 모바일 클라이언트가 생기기 전까지는 조치 없음. 자가 점검 표를 관문으로 삼는다 — Jayverse의 현재 스택은 어떤 서비스가 모바일 출시를 확정하기 전까지 바뀌지 않는다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑