Nếu doanh nghiệp cần một app iPhone mà nhân viên hoặc khách hàng mở mỗi ngày, cần Face ID, thông báo đẩy, camera, định vị hay chạy nền, thì app đó nên viết bằng Swift. Swift là ngôn ngữ Apple phát triển cho chính nền tảng của họ; mọi khả năng mới của iPhone xuất hiện trong Swift trước, công cụ dựng app (Xcode) được thiết kế quanh nó, và app viết bằng Swift là loại app Apple duyệt quen tay nhất. Đổi lại, doanh nghiệp phải chấp nhận một mã nguồn riêng cho iPhone, một người biết Swift, và một chiếc Mac để dựng bản phát hành.
Bài này không so ngôn ngữ theo kiểu cú pháp nào đẹp hơn. Người mua phần mềm cần biết lựa chọn đó kéo theo những khoản gì trong ba năm tới: thời gian ra mắt, số lần bị App Store từ chối, thông báo có tới tay người dùng hay không, và tuyển ai để bảo trì. Minh hoạ lấy từ app iOS của ALODEV AIO, phần mềm vận hành nội bộ mà chính ALODEV dùng hằng ngày.
Người dùng iPhone ở Việt Nam không phải thiểu số
Một lập luận hay gặp khi muốn cắt chi phí là "phần lớn người Việt dùng Android, làm iPhone sau". Số liệu không ủng hộ lập luận đó. Theo Statcounter, tháng 8/2026 iOS chiếm 42,64% lượt xem trang từ điện thoại tại Việt Nam, Android 57,33%. Với nhân viên văn phòng, quản lý và khách hàng ở thành phố lớn, tỷ lệ iPhone thường còn cao hơn mức trung bình toàn quốc.
Hệ quả là app iPhone cần được làm tử tế như bản chính. Nếu bản iPhone chậm, hay văng hoặc thông báo không tới, gần một nửa người dùng sẽ gặp trải nghiệm đó. Vì vậy câu hỏi về công nghệ cho iPhone đáng được trả lời riêng, không gộp chung vào quyết định chọn công cụ cho Android.
Swift là đường Apple mở trước
Apple giới thiệu Swift trên trang dành cho nhà phát triển như ngôn ngữ lập trình cho mọi nền tảng Apple. Trong thực tế điều đó có nghĩa là: khi iOS mới ra mắt với một tính năng mới (widget kiểu mới, cách xin quyền mới, thay đổi về thông báo), tài liệu và ví dụ mẫu viết bằng Swift có ngay hôm đó. Các nền tảng đa nền tảng như Flutter hay React Native phải chờ cộng đồng hoặc nhóm phát triển của họ viết lớp nối, thường tính bằng tuần hoặc tháng.
Với doanh nghiệp, độ trễ đó có giá thật. Mỗi mùa thu Apple phát hành iOS mới, và một số thay đổi buộc app phải cập nhật để giữ hành vi cũ. App viết bằng Swift thường chỉ cần đội của mình sửa. App đa nền tảng có thêm một bên thứ ba trong chuỗi: phải chờ thư viện cập nhật, rồi mới tới lượt mình.
App iOS của ALODEV AIO: SwiftUI, không thư viện bên thứ ba
App iOS ALODEV AIO viết bằng SwiftUI, chạy từ iOS 17, và theo README của kho mã, không dùng một thư viện bên thứ ba nào. Đếm ngày 25/09/2026: 204 tệp Swift, 55.066 dòng, phục vụ năm vai trò từ nhân viên tới chủ doanh nghiệp. Quyết định không dùng thư viện ngoài có một hệ quả rất thực tế: khi có iOS mới, không có dòng mã nào của người khác cần chờ.
Khoá Face ID là ví dụ dễ thấy. Phần kiểm tra máy có Face ID, Touch ID hay chỉ có mật mã, rồi yêu cầu xác thực trước khi mở lại phiên đăng nhập, nằm gọn trong một tệp 43 dòng dùng thư viện LocalAuthentication có sẵn của Apple. Không cần cài thêm gói nào, không cần lớp nối nào giữa hai ngôn ngữ.
Thông báo đẩy là ví dụ thứ hai, và là chỗ chúng tôi đã trả giá. App iOS nhận thông báo qua dịch vụ APNs của Apple: app xin quyền, nhận một mã thiết bị, gửi mã đó lên máy chủ. Trước đây, lỗi ở bước gửi mã lên máy chủ bị nuốt im lặng. Ngày 01/09/2026, khi đo trên hệ thống thật, 10 trên 12 người không có mã thiết bị dùng được, và không ai phát hiện trong nhiều tuần. Sửa lại, app ghi lý do lần hỏng gần nhất và đếm số lần hỏng liên tiếp. Viết bằng Swift giúp đọc được toàn bộ chuỗi đó trong mã của chính mình, từ lúc xin quyền tới lúc máy chủ nhận mã, không phải đoán xem thư viện trung gian đã làm gì.
Những hệ quả kinh doanh của việc chọn Swift
| Tiêu chí | Swift (native) | Flutter / React Native | Bọc web (WebView) |
|---|---|---|---|
| Tính năng mới của iOS | Dùng được ngay khi Apple phát hành | Chờ thư viện hoặc tự viết lớp nối | Chỉ những gì Safari hỗ trợ |
| Face ID, camera, chạy nền | Gọi thẳng thư viện Apple | Qua plugin, chất lượng tuỳ plugin | Hạn chế, nhiều thứ không làm được |
| Thông báo đẩy | APNs trực tiếp, đọc được toàn bộ luồng | APNs qua plugin | Phải thêm plugin, dễ quên |
| Rủi ro bị App Store từ chối vì "chỉ là website" | Thấp | Thấp | Cao (mục 4.2) |
| Mã nguồn phải duy trì | Riêng cho iPhone | Một bộ chung, cộng phần riêng từng nền tảng | Dùng lại web |
| Người bảo trì | Cần người biết Swift | Cần người biết Dart hoặc JavaScript | Người làm web |
| Máy dựng bản phát hành | Bắt buộc có Mac | Vẫn cần Mac cho bản iOS | Vẫn cần Mac cho bản iOS |
Duyệt App Store nhanh và ít bất ngờ
Apple cho biết trung bình 90% bản gửi lên được duyệt trong chưa tới 24 giờ. Thời gian duyệt không phụ thuộc ngôn ngữ, nhưng lý do bị trả về thì có. Bản hướng dẫn duyệt của Apple, mục 4.2, yêu cầu app phải có tính năng, nội dung và giao diện vượt lên trên một website đóng gói lại. App Swift dùng thành phần giao diện của hệ điều hành, có Face ID, thông báo, widget nên gần như không vướng mục này. Mỗi lần bị trả về là thêm vài ngày trễ cho kế hoạch ra mắt và một vòng sửa không có trong báo giá.
Thông báo đẩy tới được người dùng
Với app nội bộ như chấm công, giao việc, duyệt đơn, thông báo đẩy là lý do chính để có app. Swift dùng APNs trực tiếp nên mọi trạng thái đều quan sát được: người dùng đã cho phép chưa, mã thiết bị đã gửi lên chưa, lần gửi gần nhất hỏng vì sao. Khi thông báo không tới, đội phát triển đi được tới tận nguyên nhân thay vì dừng ở câu "plugin báo thành công".
Tuyển người khó hơn, và nên tính trước
Đây là điểm trừ thật của Swift. Trong khảo sát lập trình viên Stack Overflow 2025, 5,4% người trả lời dùng Swift, trong khi JavaScript là 66%. Nhóm người biết Swift nhỏ hơn nhiều so với nhóm làm web. Doanh nghiệp tự nuôi đội nên tính trước rằng tìm người thay thế sẽ lâu hơn; doanh nghiệp thuê ngoài nên yêu cầu mã nguồn có tài liệu, có kiểm thử tự động, và quyền sở hữu tài khoản Apple nằm ở phía mình.
Tài khoản Apple phải thuộc pháp nhân công ty ngay từ đầu
Chuyện này không riêng gì Swift nhưng hay bị bỏ qua nhất. App iOS đầu tiên của ALODEV được đăng ký dưới tài khoản Apple cá nhân. Khi chuyển sang tài khoản của công ty, app phải mang mã định danh mới, và với iOS đó là một app khác hẳn: nhân viên phải gỡ bản cũ rồi cài bản mới, không cập nhật đè được. Nếu đăng ký bằng tài khoản công ty ngay từ đầu, bước này không tồn tại.
Khi nào KHÔNG nên viết app iOS bằng Swift
- App chỉ là vài màn nhập liệu và danh sách, dùng vài lần mỗi tuần, không cần thông báo đẩy. Một trang web chạy tốt trên điện thoại rẻ hơn và cập nhật tức thì cho mọi người.
- Ngân sách chỉ đủ nuôi một đội cho cả iPhone lẫn Android, và app không cần tính năng sâu của hệ điều hành. Flutter hoặc React Native cho một mã nguồn chung là lựa chọn hợp lý hơn.
- Nghiệp vụ còn đang thay đổi hằng tuần. Mỗi thay đổi trên app phải qua một vòng dựng, gửi duyệt và chờ người dùng cập nhật. Nên chạy ổn trên web trước, chốt quy trình rồi mới làm app.
- Đội hiện tại toàn người làm web và không có kế hoạch tuyển người biết Swift. Một app Swift không ai bảo trì còn tệ hơn một app đa nền tảng được chăm sóc đều.
- Không có Mac và không muốn thuê dịch vụ dựng trên Mac. Mọi bản iOS, dù viết bằng gì, cuối cùng vẫn phải dựng bằng Xcode trên macOS.
Câu hỏi thường gặp
Swift và Objective-C khác nhau thế nào, app mới có cần Objective-C không?
Không cần. Objective-C là ngôn ngữ cũ của Apple, vẫn chạy được nhưng Apple viết tài liệu và ví dụ mới bằng Swift. App mới nên viết Swift, chỉ đọc Objective-C khi phải bảo trì mã cũ.
SwiftUI hay UIKit?
Với app doanh nghiệp mới chạy từ iOS 17 trở lên, SwiftUI là lựa chọn hợp lý: viết giao diện nhanh hơn và ít mã hơn. UIKit vẫn cần khi phải hỗ trợ iOS rất cũ hoặc có màn hình tuỳ biến sâu mà SwiftUI chưa làm tốt.
Viết app iOS bằng Swift có bắt buộc phải có máy Mac không?
Có, ít nhất để dựng và ký bản phát hành. Xcode chỉ chạy trên macOS, và điều này đúng với cả app Flutter hay React Native khi xuất bản cho iPhone.
App Swift có chạy được trên Android không?
Không theo cách dùng thông thường. Chọn Swift cho iPhone nghĩa là Android cần một app riêng, thường viết bằng Kotlin, hoặc một bản web. Bài tiếp theo trong series bàn về cái giá của việc duy trì hai mã nguồn.
Bao lâu thì Apple duyệt xong một bản app?
Theo Apple, trung bình 90% bản gửi lên được duyệt trong chưa tới 24 giờ. Nên chừa thêm vài ngày trong kế hoạch ra mắt cho trường hợp bị trả về và phải sửa.
