Native hay Cross-Platform không phải lựa chọn giữa “tốt nhưng đắt” và “rẻ nhưng chậm”. Đây là quyết định về phần nào cần tối ưu riêng cho iOS/Android, phần nào nên dùng chung và đội ngũ nào sẽ duy trì sản phẩm lâu dài.
Trả lời nhanh: chọn Native khi capability nền tảng, performance hoặc UI fidelity là hard requirement; chọn shared UI khi phần lớn journey giống nhau và team cần giảm trùng code; chọn shared logic/native UI khi business rule phức tạp nhưng giao diện vẫn cần native. Nếu rủi ro kỹ thuật chưa rõ, làm technical spike trước khi chốt framework.
3 mô hình cần so sánh
| Mô hình | Dùng chung | Giữ riêng | Phù hợp khi |
|---|---|---|---|
| Native riêng | Backend, API, design system, analytics spec | UI/client logic theo từng OS | Platform depth, performance, form factor khác biệt |
| Shared UI | Phần lớn UI + business logic | Platform config/native module | Journey tương đồng, time-to-market quan trọng |
| Shared logic + native UI | Domain logic, data model, networking | UI + platform integration | Logic chung phức tạp nhưng UI cần native |
Ví dụ công nghệ gồm Swift/SwiftUI và Kotlin/Jetpack Compose cho native; Flutter hoặc React Native cho shared UI; Kotlin Multiplatform cho shared logic. Tham khảo SwiftUI, Jetpack Compose, React Native platform-specific code, Flutter Architecture và Kotlin Multiplatform.
Tài liệu của chính các framework cho thấy “cross-platform” không đồng nghĩa với một codebase hoàn toàn không có phần riêng: React Native hỗ trợ tệp và component theo từng nền tảng; Flutter dùng platform channel hoặc FFI để gọi mã Kotlin, Swift hay thư viện native; Kotlin Multiplatform cho phép chọn mức chia sẻ từ một phần logic đến cả UI. Vì vậy, kiến trúc nên được mô tả bằng ranh giới phần dùng chung và phần native, không chỉ bằng tên framework.
So sánh Native và Cross-Platform theo quyết định kinh doanh
| Tiêu chí | Native | Shared UI Cross-Platform |
|---|---|---|
| Code reuse | Thấp hơn ở client | Cao hơn ở UI/logic |
| Platform capability | Tiếp cận trực tiếp hơn | Qua plugin/module/platform code khi cần |
| UI fidelity | Dễ tối ưu theo từng OS | Cần xử lý khác biệt khi platform diverge |
| Team | Cần năng lực iOS + Android | Một team chính nhưng vẫn cần native skill |
| Release | Có thể tách độc lập | Feature thường coupling cao hơn |
| QA | Test từng OS/device | Vẫn test từng OS/device + shared regression |
| Dependency | Phụ thuộc OS/SDK native | Thêm framework/plugin lifecycle |
| Migration | Không có framework bridge | Cần plan nếu framework/plugin thay đổi |
Capability matrix trước khi chọn framework
| Capability | Câu hỏi phải kiểm chứng | Evidence |
|---|---|---|
| Camera/media | Capture đơn giản hay realtime processing? | Prototype trên device mục tiêu |
| Bluetooth/NFC/IoT | SDK hỗ trợ framework nào? | Vendor SDK POC |
| Offline | Volume, encryption, conflict, sync? | Network simulation |
| Background | Task cần chạy bao lâu? | Platform lifecycle POC |
| Performance | Startup, frame, memory, battery budget? | Benchmark trên device matrix |
| Security | Local data, integrity, auth, SDK boundary? | Threat model + security test |
Một plugin tồn tại trên package registry chưa chứng minh nó đáp ứng version OS, edge case, license và support của dự án. Hard capability nên được kiểm chứng bằng technical spike.
Technical spike cần bàn giao những gì?
| Đầu ra | Nội dung phải có | Dùng để quyết định |
|---|---|---|
| Vertical slice | Một luồng nhỏ chạy xuyên UI, API, SDK hoặc phần cứng khó nhất trên thiết bị thật. | Framework có đi qua được rủi ro kỹ thuật lớn nhất không? |
| Device matrix | Phiên bản OS, thiết bị thấp/trung/cao, trạng thái mạng và quyền bị từ chối. | Kết quả có đại diện cho nhóm người dùng mục tiêu không? |
| Đo lường | Startup, độ ổn định khung hình, memory, battery, latency và crash theo ngưỡng do sản phẩm đặt trước. | Đạt, cần tối ưu hay loại phương án? |
| Dependency audit | Phiên bản, license, maintainer, native code, lịch sử phát hành và phương án thay thế. | Rủi ro phụ thuộc có chấp nhận được không? |
| Hồ sơ quyết định | Kết quả, giới hạn, phần chưa kiểm chứng, ước lượng phần native và khuyến nghị. | Tiếp tục, cô lập thành module native hoặc đổi kiến trúc. |
Spike không phải bản demo để chứng minh giao diện “chạy được”. Trước khi làm, cần khóa tiêu chí pass/fail và thời lượng thử nghiệm; sau đó lưu source, cấu hình build cùng kết quả đo để vendor khác có thể kiểm tra lại.
Performance và security: đừng dùng định kiến
Native không tự động nhanh hoặc an toàn hơn. Cross-platform cũng không mặc định đủ nhanh cho mọi use case. Cả hai cần benchmark và threat model theo flow thực tế.
| Lớp | Nên kiểm tra |
|---|---|
| Performance | Cold/warm start, frame stability, memory, battery, latency |
| Security | Server-side authorization, local storage, network, SDK, build pipeline |
| Reliability | Offline, retry, error recovery, crash |
| Accessibility | Screen reader, focus, dynamic type/input |
Đọc thêm bảo mật ứng dụng di động.
TCO: đừng chỉ so chi phí build
| Nhóm chi phí | Cần tính |
|---|---|
| Delivery | UI, business logic, native module, backend/admin |
| QA | OS/device, integration, accessibility, security |
| Release | CI/CD, signing, Store, rollout, hotfix |
| Dependency | Framework/plugin/SDK, license, migration |
| Operations | Crash monitoring, support, incident |
| Maintenance | OS, framework, SDK, security patch |
| Organization | Hiring, onboarding, coordination, knowledge |
| Exit | Module extraction, handover, migration |
Không có tỷ lệ tiết kiệm cố định cho cross-platform và cũng không có premium chung cho native. Nên so theo một khoảng vận hành thống nhất, chẳng hạn ba năm: TCO = discovery + build + QA + release + vận hành + bảo trì + sự cố + migration/exit + chi phí tổ chức. Phần dùng chung chỉ tạo giá trị nếu chi phí phối hợp, native bridge, regression và nâng cấp framework thấp hơn phần công sức tránh được.
Mỗi phương án ngân sách nên có ba kịch bản: dự kiến, xấu hơn dự kiến và phải thay dependency quan trọng. Khi scope đã đủ rõ, tham khảo chi phí viết app.
Decision tree chọn công nghệ
| Câu hỏi | Nếu Có | Nếu Không |
|---|---|---|
| Có hard capability/platform integration sâu? | Ưu tiên Native hoặc shared logic/native UI | Đi tiếp |
| Journey iOS/Android gần giống nhau? | Shared UI đáng đánh giá | Native hoặc UI riêng có thể hợp lý hơn |
| Business rule phức tạp cần dùng chung? | Shared logic đáng thử | Không cần ép code sharing |
| Plugin/SDK quan trọng chưa được kiểm chứng? | Làm spike trước | Đi tiếp |
| Team có năng lực maintain mô hình chọn? | Đánh giá TCO | Chưa nên khóa framework |
Câu hỏi cần hỏi vendor
- Phần nào được dùng chung và phần nào cần native code?
- Framework/plugin version và upgrade policy là gì?
- Ai trong team có năng lực native iOS/Android?
- Benchmark chạy trên thiết bị nào?
- Fallback nếu plugin hoặc framework gặp vấn đề là gì?
- Source, CI/CD, signing và native module được bàn giao ra sao?
Đối chiếu checklist hợp đồng công ty viết app.
Câu hỏi thường gặp
Native có luôn nhanh hơn Cross-Platform?
Không. Cần benchmark core journey trên thiết bị mục tiêu.
Cross-Platform có luôn rẻ hơn?
Không. Code sharing có thể giảm delivery cost nhưng plugin, QA, migration và maintenance có thể làm TCO tăng.
App fintech có bắt buộc Native?
Không mặc định. Cần đánh giá SDK, integrity, auth, local storage, performance và compliance trước.
Có thể kết hợp Native và Cross-Platform trong cùng một app không?
Có. Có thể nhúng một module Flutter vào app hiện có, viết phần riêng theo nền tảng trong React Native, hoặc chia sẻ business logic bằng Kotlin Multiplatform trong khi giữ UI native. Tuy nhiên, ranh giới module, ownership, build pipeline và chiến lược release phải được thiết kế rõ.
Kết luận
Native, shared UI và shared logic là ba điểm trên cùng một phổ kiến trúc. Hãy chọn phương án nhỏ nhất đáp ứng hard capability, có team duy trì và TCO chấp nhận được; sau đó kiểm chứng bằng spike thay vì tranh luận bằng tên framework.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.