Dịch vụ thiết kế app di động iOS và Android

Câu hỏi đầu tiên ALODEV đặt ra không phải làm app bằng gì, mà người dùng sẽ mở nó bằng gì. Một app tốn chi phí làm, chi phí duyệt trên kho ứng dụng và chi phí duy trì hai nền tảng. Nếu người dùng thực tế vẫn mở trình duyệt, khoản đó không sinh ra giá trị.

Số đo từ chính phần mềm vận hành nội bộ ALODEV AIO minh hoạ điều này. Ngày 05/09/2026, đếm 403 lượt chấm công trong 30 ngày: 367 lượt, tức 91%, đến từ trình duyệt; hai app iPhone và Android cộng lại chỉ 15 lượt. Nhân viên làm việc trên máy tính và chấm công ngay tại đó. Kết luận rút ra là ưu tiên bản web cho nhóm này, và dùng app cho những việc điện thoại làm tốt hơn: thông báo đẩy, Face ID, chấm công khi ra ngoài.

App đáng làm khi có ít nhất hai trong ba điều sau: người dùng mở nó nhiều lần mỗi ngày; thông báo đẩy là lõi của nghiệp vụ (có đơn mới, có việc cần duyệt, có lịch hẹn sắp tới); app cần phần cứng như camera, định vị, Face ID, quét mã hoặc chạy nền. Dưới mức đó, một website chạy tốt trên điện thoại, có thể thêm vào màn hình chính và nhận thông báo web, thường là bước đầu hợp lý hơn. ALODEV nói điều này ngay trong buổi làm rõ yêu cầu, kể cả khi nó làm dự án nhỏ lại.

Có bốn cách phổ biến để có một app trên điện thoại. Mỗi cách đổi một thứ lấy một thứ khác; bảng dưới đây nhìn từ phía chủ doanh nghiệp, không từ phía lập trình viên.

Khi nào chọn native

ALODEV chọn native cho chính phần mềm của mình: app iPhone của ALODEV AIO viết bằng SwiftUI, chạy từ iOS 17, không dùng thư viện bên thứ ba nào; app Android viết lại bằng Kotlin và Jetpack Compose. Lý do là app được nhân viên mở mỗi ngày, cần Face ID và thông báo đẩy chạy chắc chắn. Ví dụ, toàn bộ phần khoá Face ID và Touch ID nằm trong một tệp 43 dòng chỉ dùng thư viện của Apple.

Cái giá của native, đo bằng số

Native không miễn phí. Đếm ngày 25/09/2026, hai app native của ALODEV AIO cộng lại 89.193 dòng mã cho cùng một bộ nghiệp vụ. Ngày 11/09/2026, bản đối chiếu từng màn giữa app iPhone và app Android ra 25 dòng khác biệt: không ai cố ý làm lệch, mỗi app được sửa theo yêu cầu vào những thời điểm khác nhau. Cùng một lỗi giờ chấm công lệch 7 tiếng phải sửa hai lần trong một buổi chiều, ở hai kho mã.

Vì vậy với doanh nghiệp làm app lần đầu và cần có mặt trên cả hai nền tảng, ALODEV thường đề xuất Flutter hoặc React Native: một mã nguồn, một lần sửa, một lần kiểm thử. Giữa hai nền tảng này, đội đã làm web bằng React nên chọn React Native để dùng lại kiến thức và một phần logic; cần giao diện giống hệt nhau trên hai hệ điều hành thì Flutter hợp hơn.

Bọc web thành app: nhanh nhưng dễ đắt

ALODEV từng đi con đường này cho app Android đầu tiên: một vỏ Capacitor nạp thẳng cổng web nhân viên từ máy chủ. Có app trong một buổi sáng, nhưng chính tài liệu của Capacitor ghi tuỳ chọn nạp từ máy chủ là không dành cho bản phát hành, thông báo đẩy vẫn phải làm riêng, và Apple có mục 4.2 trong hướng dẫn duyệt yêu cầu app phải vượt lên trên một website đóng gói lại. Vỏ đó sau này được thay bằng app Kotlin native. Bọc web vẫn hợp cho công cụ nội bộ ngắn hạn, phân phối ngoài kho ứng dụng.

Phần phát hành thường bị xem nhẹ trong báo giá, nhưng là nơi phát sinh nhiều ngày trễ nhất. Dưới đây là các bước ALODEV làm cho một app, kèm những gì đã học từ app của chính mình.

1. Tài khoản đứng tên doanh nghiệp ngay từ đầu

App iPhone đầ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ô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. Vì vậy ALODEV mở tài khoản Apple Developer và Google Play Console cho chính doanh nghiệp, kèm mã D-U-N-S khi Apple yêu cầu với tài khoản tổ chức. Bước này có thể mất vài tuần nên làm song song với thiết kế.

2. Bản thử nội bộ trước khi gửi duyệt

Với iPhone, bản thử phát cho nhóm người dùng nội bộ qua TestFlight. Ở app ALODEV AIO, việc dựng, ký và đẩy lên TestFlight chạy bằng một lệnh tự động (fastlane): số bản dựng tự tăng theo bản mới nhất trên TestFlight, ghi chú "cần thử gì" đi kèm từng bản. Bản iOS luôn phải dựng trên máy Mac vì Xcode chỉ chạy trên macOS, điều này đúng với cả app Flutter hay React Native. Với Android, Google Play có các kênh thử nội bộ, thử kín và thử mở trước khi phát hành chính thức; theo chính sách hiện hành của Google, tài khoản nhà phát triển cá nhân mới tạo phải chạy thử kín với người thử thật một thời gian trước khi được phát hành chính thức, thêm một lý do để đăng ký dưới tên tổ chức.

3. Hồ sơ trên kho ứng dụng

• Tên app, mô tả, từ khoá, ảnh chụp màn hình theo kích thước từng loại máy.
• Chính sách quyền riêng tư công khai trên website, khớp với dữ liệu app thực sự thu thập.
• Khai báo quyền riêng tư (App Privacy trên App Store, Data safety trên Google Play).
• Tài khoản dùng thử cho người duyệt nếu app cần đăng nhập, và hướng dẫn tới được tính năng chính.
• Câu giải thích cho từng quyền xin người dùng (camera, định vị, Face ID) đúng mục đích thật.

4. Duyệt và phát hành

Apple công bố phần lớn bản gửi lên được duyệt trong chưa tới 24 giờ, nhưng kế hoạch ra mắt nên chừa vài ngày cho trường hợp bị trả về. Lý do bị trả về hay gặp nhất không phải công nghệ mà là thiếu tài khoản dùng thử, mô tả quyền không rõ, hoặc app chỉ là website đóng gói. ALODEV rà các điểm này trước khi gửi.

5. Sau phát hành: thông báo đẩy phải được theo dõi

Thông báo đẩy hỏng thường hỏng im lặng. Ngày 01/09/2026, khi đo trên hệ thống thật, 10 trên 12 người dùng app ALODEV AIO không có mã thiết bị dùng được để nhận thông báo, vì lỗi gửi mã lên máy chủ bị bỏ qua không ghi lại. Sau khi sửa, app ghi lý do lần hỏng gần nhất và đếm số lần hỏng liên tiếp, máy chủ biết ai đang không nhận được thông báo. App ALODEV làm cho khách có sẵn phần theo dõi này.

Phần người dùng nhìn thấy trên điện thoại thường chỉ chiếm một phần của dự án. Báo giá app chỉ tính màn hình mà không tính phần còn lại là báo giá thiếu.

• App trên điện thoại: các màn hình, đăng nhập, thông báo đẩy, xử lý khi mất mạng.
• Máy chủ và API: nơi lưu dữ liệu, phân quyền, gửi thông báo, nối với phần mềm khác.
• Trang quản trị trên web: để nhân viên của doanh nghiệp quản lý nội dung, đơn hàng, người dùng.
• Tích hợp: thanh toán trong nước, bản đồ, đơn vị vận chuyển, phần mềm bán hàng hoặc kế toán đang dùng.
• Phát hành và hồ sơ trên hai kho ứng dụng, như mục trên.
• Đo lường: số người dùng hoạt động, luồng bị bỏ dở, lỗi văng app.

Doanh nghiệp đã có hệ thống web hoặc phần mềm quản lý thì app nên dùng chung máy chủ và dữ liệu đó. ALODEV AIO là ví dụ: web Next.js, app iPhone và app Android cùng gọi một máy chủ viết bằng Go, nên dữ liệu không bao giờ lệch giữa ba nơi, và càng nhiều logic nghiệp vụ nằm ở máy chủ thì hai app càng ít phải sửa.

App di động cần bảo trì đều đặn hơn website, vì nó phụ thuộc vào lịch của Apple và Google. Mỗi năm có phiên bản iOS và Android mới; kho ứng dụng định kỳ nâng yêu cầu tối thiểu về phiên bản SDK và quyền riêng tư, app không cập nhật có thể bị ẩn khỏi kết quả tìm kiếm hoặc không nhận bản mới.

• Kiểm app trên bản hệ điều hành mới ngay khi có bản thử, sửa trước ngày phát hành chính thức.
• Cập nhật thư viện và phiên bản SDK theo yêu cầu của kho ứng dụng.
• Theo dõi lỗi văng app và tỷ lệ nhận thông báo đẩy.
• Gia hạn chứng chỉ ký và tài khoản nhà phát triển hằng năm.

Cam kết bảo hành của ALODEV áp dụng cho app như mọi dự án: bảo hành trọn đời, sự cố nghiêm trọng phản hồi dưới 1 giờ. Phần cập nhật theo phiên bản hệ điều hành mới và thay đổi tính năng được thoả thuận riêng trong hợp đồng bảo trì.