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.

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.

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.

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.

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ế.

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.

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.

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.

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.

Cam kết bảo hành của ALODEV áp dụng cho app như mọi dự án: bảo hành theo hợp đồng, thời gian phản hồi sự cố theo gói bảo trì trong hợp đồng. 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ì.