Checklist ứng dụng di động cho startup: 34 mục từ MVP đến khi được duyệt (2026)

Checklist ứng dụng di động cho startup: 34 mục từ MVP đến khi được duyệt (2026)

Điều khoản 5.1.1(v) trong App Store Review Guidelines của Apple đã giết chết nhiều ngày ra mắt của startup hơn bất kỳ bug nào chúng tôi từng ship. Một nút xóa tài khoản bị thiếu, nộp lên vào đêm trước demo day, và toàn bộ timeline trượt đi một tuần. Checklist ứng dụng di động cho startup này tồn tại vì sai lầm đó hoàn toàn có thể tránh được, và gần như không ai ghi lại số điều khoản đã gây ra nó.

Ý chính:

• Apple từ chối ứng dụng vì thiếu luồng xóa tài khoản và liên kết chính sách quyền riêng tư: Điều khoản 5.1.1 và 1.5 nêu đích danh cả hai.
• Google Play yêu cầu cả đường dẫn xóa tài khoản trong app lẫn một đường dẫn công khai trên web, với đợt thực thi bắt đầu sau hạn chót gia hạn ngày 31 tháng 5 năm 2024.
• Checklist nộp duyệt của iOS và Android khác nhau; coi chúng như một danh sách gộp chung là nguyên nhân số 1 gây trễ lịch ra mắt vào phút chót.

Trước khi bạn viết code

Trước khi bất kỳ màn hình nào được thiết kế, ba thứ cần phải chốt xong: MVP của bạn thực chất là gì, bạn có cần chính sách quyền riêng tư không (có đấy), và GDPR hay KVKK của Thổ Nhĩ Kỳ áp dụng cho người dùng của bạn không. Bỏ qua giai đoạn này chính là lý do các founder phải chạy đôn chạy đáo viết mấy trang pháp lý vào đúng tuần họ định nộp duyệt.

Nói một câu, MVP là phiên bản nhỏ nhất của sản phẩm dùng để kiểm chứng giả định cốt lõi của bạn với người dùng thật. Nó không phải phiên bản rút gọn của tầm nhìn đầy đủ. Nếu bạn vẫn chưa rõ phạm vi, hãy xác định phạm vi bản build cho chuẩn trước khi viết dòng code đầu tiên, việc này giúp bạn khỏi phải cắt tính năng giữa chừng thay vì cắt trước khi bắt đầu.

Quy định của chính Apple nói rất thẳng về yêu cầu chính sách quyền riêng tư: Điều khoản 5.1.1(i) nêu rõ ứng dụng "phải bao gồm một liên kết đến chính sách quyền riêng tư của chúng" trong metadata trên App Store Connect và, trong nhiều trường hợp, ở ngay trong app. Đó không phải gợi ý. Thiếu nó là bị chặn nộp duyệt.

• Định nghĩa phạm vi MVP của bạn trong một câu
• Xác nhận bạn cần chính sách quyền riêng tư (gần như luôn luôn cần)
• Soạn Support URL (Điều khoản 1.5 của Apple bắt buộc)
• Kiểm tra khả năng áp dụng GDPR/KVKK nếu bạn có người dùng ở EU hoặc Thổ Nhĩ Kỳ
• Quyết định stack native hay cross-platform

Tuần build MVP

Tuần build MVP là nơi bạn quyết định thứ gì thực sự được ship và thứ gì bị cắt, và câu trả lời thật lòng là: nhiều hơn founder tưởng. Analytics và báo cáo crash phải được đưa vào ngay trong lúc build, chứ không phải sau đó. Gắn chúng vào sau khi ra mắt nghĩa là bạn mất đúng thứ dữ liệu mình cần để kiểm chứng giả định đầu tiên.

Thứ chúng tôi thực sự cắt khỏi phạm vi v1, trong hầu hết các trường hợp, là mọi thứ không phải cái duy nhất đang được kiểm chứng. Push notification, đăng nhập mạng xã hội, màn hình cài đặt với sáu công tắc, tất cả đều có thể đợi. Founder kháng cự điều này, cũng dễ hiểu; cảm giác như đang ship một thứ chưa hoàn thiện. Nó đúng là chưa hoàn thiện. Đó mới là vấn đề.

Như một founder đã ship vài ứng dụng từng viết trong một bài checklist trên dev.to, bỏ qua cơ chế nhận phản hồi từ sớm là sai lầm mà anh ấy "lần nào cũng hối hận". Hãy lắp nó vào ngay bây giờ, chứ không phải sau khi bài đánh giá đầu tiên ập đến. Nếu bạn muốn đẩy nhanh chính cuộc trao đổi về phạm vi, dùng AI để tăng tốc khâu xác định phạm vi rất đáng xem trước khi bắt đầu build.

• Gắn analytics trước bản TestFlight/build nội bộ đầu tiên
• Lắp báo cáo crash (Sentry hoặc Firebase Crashlytics)
• Tích hợp cơ chế nhận phản hồi vào app
• Cắt mọi tính năng không cốt lõi với cái duy nhất bạn đang kiểm chứng
• Viết chuỗi phiên bản đầu tiên (xem phần versioning bên dưới)

Tuần trước khi nộp duyệt

Đây là giai đoạn mà mọi checklist của đối thủ đều bỏ qua hoàn toàn, và cũng là nơi xảy ra nhiều lần trễ lịch có thể phòng tránh nhất. Semantic versioning cho ứng dụng theo mẫu MAJOR.MINOR.BUILD (1.0.0, rồi 1.0.1 cho bản vá, 1.1.0 cho lần thêm tính năng). Hãy chọn một quy ước ngay bây giờ, vì số phiên bản thiếu nhất quán làm rối cả hai store lẫn chính đội của bạn.

Phát hành theo giai đoạn tung bản cập nhật ra một tỷ lệ nhỏ người dùng trước (thường 1%, rồi 10%, rồi 50%) trước khi đến tất cả mọi người. Chỉ một trong ba checklist đối thủ mà chúng tôi xem xét có nhắc đến nó, và cũng chỉ thoáng qua. Nếu một lỗi crash lọt lưới, phát hành theo giai đoạn sẽ giới hạn bán kính thiệt hại thay vì giáng xuống 100% người dùng cùng lúc.

Những câu hỏi chúng tôi đặt ra trước khi bật đèn xanh cho lần nộp duyệt của khách hàng rất đơn giản: luồng quan trọng nhất có chạy thông suốt từ đầu đến cuối, ngay lúc này, trên một thiết bị thật không? Không phải trên simulator. Tỷ lệ phiên không crash có chấp nhận được không? Asset trên trang store đã thực sự hoàn chỉnh, không phải đồ giữ chỗ chưa?

• Xác nhận số phiên bản của bạn theo một quy ước nhất quán
• Test luồng quan trọng nhất từ đầu đến cuối thêm một lần nữa
• Chuẩn bị tỷ lệ phát hành theo giai đoạn nếu store hỗ trợ
• Xác nhận tỷ lệ phiên không crash ở mức chấp nhận được trước khi nộp
• Chụp màn hình và chuẩn bị mọi asset cho trang store

Ngày nộp duyệt: iOS và Android

Lần nộp duyệt iOS và Android thất bại vì những lý do khác nhau, và coi chúng như một checklist gộp chung là nguyên nhân lớn nhất gây trễ lịch ra mắt vào phút chót mà chúng tôi thấy. App Store Review Guidelines của Apple và chính sách nhà phát triển của Google Play mỗi bên đều nêu những yêu cầu cụ thể, kiểm tra được, và hầu hết founder chỉ biết về chúng sau một email từ chối.

Trong chính các lần nộp ứng dụng của chúng tôi, hai thứ làm founder lần đầu vấp ngã thường xuyên nhất là yêu cầu xóa tài khoản và một Support URL không truy cập được. Cả hai đều là những lần sửa trong một dòng nếu bạn phát hiện trước khi nộp. Và cả hai đều gây từ chối tự động nếu bạn không phát hiện.

App Store Review Guidelines của Apple rất cụ thể: Điều khoản 5.1.1(v) yêu cầu ứng dụng có hỗ trợ tạo tài khoản thì cũng phải cung cấp tính năng xóa tài khoản trong app, Điều khoản 1.6 bao quát phần khai báo Data Security, và Điều khoản 1.5 yêu cầu một Support URL hoạt động. Trên Android, chính sách nhà phát triển của Google Play yêu cầu cả đường dẫn xóa trong app VÀ một URL web công khai cho yêu cầu xóa tài khoản. Google công bố yêu cầu này vào tháng 4 năm 2023, đặt hạn chót 7 tháng 12 năm 2023 cho các câu hỏi về xóa dữ liệu trong biểu mẫu Data Safety, và cho phép gia hạn đến 31 tháng 5 năm 2024, sau mốc đó ứng dụng không tuân thủ sẽ bị xử lý. Đây không phải điều khoản cũ được miễn trừ cho app nhỏ; nó vẫn đang áp dụng.

Hai luồng nộp duyệt cũng khác nhau về mặt cơ học, chứ không chỉ trên giấy. Trên iOS, bạn tải bản build lên qua Xcode hoặc Transporter, App Store Connect xử lý nó (việc này mất từ vài phút đến hơn một giờ), và từ đó bạn hoặc chuyển nó sang TestFlight cho tester nội bộ và bên ngoài, hoặc nộp thẳng cho App Review. TestFlight không phải việc vặt tùy chọn: đó là cách Apple kỳ vọng bạn bắt được những bug mà nếu không người đánh giá sẽ từ chối bạn. Trên Android, Google Play Console chạy theo các track thay vì một lần nộp duy nhất, đi qua testing nội bộ, rồi testing kín hoặc testing mở, rồi production, mỗi track có nhóm người dùng riêng và bước thăng hạng riêng. Phát hành theo giai đoạn chỉ xuất hiện khi bạn đang cập nhật một bản phát hành production hiện có. Như tài liệu phát hành của chính Google viết, "nếu bạn đang tung bản phát hành đầu tiên, bạn sẽ không thấy tùy chọn chọn tỷ lệ phát hành," nên đừng lên kế hoạch lần ra mắt đầu đời quanh một lộ trình tăng tỷ lệ, thứ đó đến sau.

Giấy tờ, chứ không phải code, mới là thứ thực sự chặn hầu hết lần nộp đầu tiên. Apple yêu cầu privacy manifest cho một danh sách xác định các SDK bên thứ ba thường dùng (mạng quảng cáo, analytics, trình báo cáo crash), và hướng dẫn của chính họ nói rất thẳng về việc ai chịu trách nhiệm: "khi bạn dùng một SDK bên thứ ba với ứng dụng của mình, bạn chịu trách nhiệm cho toàn bộ code mà SDK đó đưa vào ứng dụng của bạn, và cần biết rõ các thực hành thu thập và sử dụng dữ liệu của nó," theo trang yêu cầu SDK bên thứ ba của Apple. Thiếu manifest cho một SDK trong danh sách là bản build của bạn không qua được App Store Connect. Cửa ải giấy tờ tương đương của Google Play là biểu mẫu Data Safety, và nó bắt buộc với mọi ứng dụng trên mọi track, ngoại trừ các bản build chỉ dành cho testing nội bộ: "mọi nhà phát triển có ứng dụng được phát hành trên Google Play đều phải hoàn tất biểu mẫu Data Safety, bao gồm ứng dụng trên các track testing kín, mở hoặc production," theo tài liệu Data Safety của Google Play. Khai sai và Google nói thẳng rằng họ "có thể thực hiện hành động phù hợp, bao gồm hành động thực thi" khi phát hiện chênh lệch giữa hành vi ứng dụng bạn khai báo và hành vi thực tế.

Có một kiểu thất bại thứ ba chẳng liên quan gì đến câu chữ chính sách: người đánh giá đơn giản là không thể test ứng dụng của bạn. Điều khoản 2.1 của Apple nói thẳng điều này: "hãy kèm thông tin tài khoản demo (và bật dịch vụ back-end của bạn lên!) nếu ứng dụng của bạn có đăng nhập." Không có thông tin đăng nhập demo chạy được, không có backend chạy thật trong cửa sổ xét duyệt, không có Support URL truy cập được, và bạn sẽ bị bật ra bất kể luồng xóa tài khoản của bạn tuân thủ đến đâu. Nếu bất kỳ phần nào của ứng dụng nằm sau paywall hoặc cổng đăng nhập, hãy viết ghi chú cho người đánh giá giải thích chính xác cách truy cập nó. Đó là bước hai phút mà founder lần đầu bỏ qua liên tục.

Thêm một cửa ải chỉ có trên Android cần được nhắc đến cùng: target API level. Tài liệu nhà phát triển của chính Android nêu rõ "ứng dụng mới và bản cập nhật ứng dụng phải target" mức Android API hiện được yêu cầu "để được nộp lên Google Play," và rằng "ứng dụng lỗi thời sẽ không khả dụng với người dùng mới trên các thiết bị chạy phiên bản Android mới hơn." Nó chẳng liên quan gì đến xóa tài khoản hay Data Safety, nhưng nó chặn lần nộp duyệt thẳng thừng y như vậy, và đó là kiểu yêu cầu thay đổi mỗi năm, nên hãy kiểm tra con số hiện hành trước khi build bản phát hành của bạn.

Không một checklist nào trong số các checklist xếp hạng cao nhất cho chính truy vấn tìm kiếm này trích dẫn lấy một số điều khoản App Store. Chúng tôi thì có, vì đoán mò về tuân thủ là cách các lần ra mắt bị trễ hết tuần này đến tuần khác. Nếu bạn đang xây dựng thế trận xử lý dữ liệu rộng hơn, checklist xử lý dữ liệu trước khi ra mắt bao quát phần bảo mật mà chúng tôi không lặp lại ở đây.

Checklist nộp duyệt iOS:

• URL chính sách quyền riêng tư đã lên sóng và truy cập được
• Luồng xóa tài khoản trong app đã ship (Điều khoản 5.1.1(v))
• Support URL đã lên sóng (Điều khoản 1.5)
• Khai báo Data Security đã hoàn tất (Điều khoản 1.6)
• Bản build TestFlight đã được duyệt trước khi nộp công khai

Checklist nộp duyệt Android:

• Biểu mẫu Data Safety đã hoàn tất trong Play Console
• Luồng xóa tài khoản trong app đã ship
• URL web công khai cho yêu cầu xóa tài khoản đã lên sóng (yêu cầu của Google Play)
• Tỷ lệ phát hành theo giai đoạn đã được đặt
• Target API level đáp ứng yêu cầu hiện hành của Play

Ngày ra mắt

Ngày ra mắt là ngày ứng dụng của bạn thực sự lên sóng với người dùng thật, tách biệt với nộp duyệt, việc có thể diễn ra trước đó vài ngày hoặc vài tuần, và tách biệt với tuần đầu tiên, tức phần hậu quả. Theo dõi staged rollout trong ngày đầu tiên là thứ cho bạn biết nên tiếp tục mở rộng hay bấm tạm dừng.

Hãy theo dõi dashboard App Store Connect hoặc Play Console mỗi giờ, chứ không phải mỗi ngày, trong 24 giờ đầu. Nếu tỷ lệ phiên không crash tụt, bạn muốn biết trong vòng một giờ, chứ không phải sáng hôm sau khi đã có thêm cả trăm người dùng dính cùng một bug. Luôn sẵn sàng một bản build để rollback. Cùng một kỷ luật harden-stabilize-deploy mà chúng tôi dùng cho tính năng AI áp dụng trực tiếp y như vậy ở đây.

• Theo dõi tỷ lệ phiên không crash mỗi giờ trong 24 giờ đầu
• Bố trí kênh hỗ trợ có người trực và sẵn sàng
• Xác nhận staged rollout đang mở rộng đúng kế hoạch
• Giữ sẵn một bản build rollback phòng khi có bug nghiêm trọng

Tuần đầu tiên lên sóng

Tuần đầu tiên lên sóng là nơi phần lớn công việc thực sự diễn ra, dù gần như chẳng ai lên kế hoạch cho nó. Rà soát báo cáo crash hằng ngày và trả lời những đánh giá đầu tiên trên store quan trọng hơn bất kỳ thứ gì bạn làm trong chính ngày ra mắt.

"Bản thân lần ra mắt ít quan trọng hơn bạn nghĩ. Thứ quan trọng là những gì bạn làm trong các tuần sau đó," như một founder đã viết trong checklist sau ra mắt của chính anh ấy. Đó là phiên bản thật lòng của tuần đầu tiên: vá nhanh, trả lời bằng giọng người thật, và thực sự kiểm tra luồng xóa dữ liệu của bạn chạy được trước khi một người dùng thật test nó thay bạn. Nếu giờ bạn đang tự hỏi tất cả chuyện này tốn bao nhiêu để build và duy trì, dự toán chi phí bảo trì và cập nhật sau ra mắt là bài đồng hành. Bài này bao quát độ sẵn sàng; bài đó bao quát hóa đơn.

• Rà soát báo cáo crash hằng ngày trong tuần đầu tiên
• Đích thân trả lời 10 đánh giá đầu tiên trên store
• Phân loại và vá mọi bug nghiêm trọng trong vòng 48 giờ
• Xác nhận quy trình yêu cầu xóa dữ liệu của bạn thực sự chạy thông suốt từ đầu đến cuối
• Đặt nhịp kiểm tra analytics đối chiếu với giả định MVP ban đầu của bạn

Cách Techsy tiếp cận việc này

Chúng tôi đối xử với khâu rà soát trước nộp duyệt theo cùng một cách cho mọi bản build của khách hàng: trước khi bật đèn xanh, chúng tôi hỏi luồng quan trọng nhất có chạy trên thiết bị thật không, tỷ lệ phiên không crash có đứng vững không, và mọi luồng do điều khoản bắt buộc (xóa tài khoản, chính sách quyền riêng tư, Support URL) có thực sự hoạt động không, chứ không chỉ tồn tại trong mockup. Đó là một danh sách ngắn, nhưng là danh sách quyết định ứng dụng có qua xét duyệt ngay lần đầu hay không.

Nếu bạn thà để một người đã từng đi qua những điều khoản này xử lý lần nộp duyệt của mình, quy trình phát triển ứng dụng di động của chúng tôi được xây quanh chính bước rà soát trước nộp duyệt này. Nó không thay thế cho việc bạn tự làm bài tập về nhà, nó là thứ chúng tôi làm sau khi bạn đã làm xong.

Câu hỏi thường gặp

MVP là gì và vì sao nó quan trọng với checklist ra mắt?

MVP là phiên bản nhỏ nhất của sản phẩm dùng để kiểm chứng một giả định cốt lõi với người dùng thật. Nó quan trọng ở đây vì mọi mục trong checklist này đều phình theo phạm vi, một MVP chặt hơn nghĩa là ít thứ có thể hỏng lúc nộp duyệt hơn và ít tính năng phải gắn đo lường, theo dõi và vá hơn trong tuần đầu tiên.

Vì sao ứng dụng bị App Store từ chối?

Những lý do phổ biến nhất có thể phòng tránh là thiếu liên kết chính sách quyền riêng tư (Điều khoản 5.1.1(i)), không có xóa tài khoản trong app (Điều khoản 5.1.1(v)), và Support URL không truy cập được (Điều khoản 1.5). Không lỗi nào trong số này cần công sức kỹ sư để sửa, chúng là các mục checklist, không phải bug.

Chuyện gì xảy ra nếu tôi không thêm tùy chọn xóa tài khoản vào ứng dụng?

Trên iOS, Điều khoản 5.1.1(v) biến điều này thành lý do từ chối tự động nếu ứng dụng của bạn hỗ trợ tạo tài khoản. Trên Android, Google Play yêu cầu cả đường dẫn xóa trong app lẫn đường dẫn công khai trên web, ứng dụng không tuân thủ sẽ bị xử lý sau hạn chót gia hạn 31 tháng 5 năm 2024, và bỏ sót nó sẽ chặn nộp duyệt trên cả hai nền tảng.

Startup có cần chính sách quyền riêng tư cho ứng dụng di động không?

Có, gần như luôn luôn. Apple yêu cầu một chính sách quyền riêng tư có liên kết theo Điều khoản 5.1.1(i), và Google Play yêu cầu một chính sách bên trong biểu mẫu Data Safety. Nếu bạn thu thập bất kỳ dữ liệu người dùng nào, dù chỉ là email để đăng ký, bạn cần có nó trước khi nộp.

Nộp lên App Store và Google Play khác nhau thế nào?

Khâu xét duyệt của Apple chạy theo điều khoản với các khoản được nêu tên (5.1.1, 1.5, 1.6) và một người đánh giá thật; Google Play dựa vào biểu mẫu Data Safety và các bước kiểm tra tự động. Yêu cầu xóa tài khoản giống nhau về tinh thần nhưng khác nhau về cơ chế; xem bảng so sánh ở trên.

Xét duyệt app store thực sự mất bao lâu?

Không store nào công bố thời gian xử lý đảm bảo, nên hãy coi bất kỳ con số nào bạn đọc được là kỳ vọng thô chứ không phải lời hứa. Trong các lần nộp của chính khách hàng chúng tôi, phê duyệt của Apple thường đến trong một hoặc hai ngày, với bất kỳ thứ gì đụng đến xóa tài khoản hoặc khai báo dữ liệu thì lâu hơn. Google Play thường nhanh hơn. Dù thế nào, hãy lên kế hoạch ngày ra mắt với khoảng đệm.

Staged rollout là gì và tôi có nên dùng không?

Staged rollout tung bản cập nhật ra một tỷ lệ nhỏ người dùng trước, rồi mở rộng dần, thay vì đến 100% cùng lúc. Hãy dùng bất cứ khi nào store hỗ trợ; nó giới hạn số người dùng dính bug trước khi bạn có thể tạm dừng và sửa.

Tôi có cần support URL để nộp ứng dụng không?

Có. Điều khoản 1.5 của Apple yêu cầu một Support URL hoạt động như một phần của lần nộp, và Google Play cũng kỳ vọng một liên hệ hỗ trợ. Một liên kết chết hoặc hộp thư không ai ngó ở đây là lý do từ chối dễ tránh.

Tôi nên theo dõi gì trong tuần đầu tiên ứng dụng lên sóng?

Báo cáo crash hằng ngày, mười đánh giá đầu tiên trên store, và liệu quy trình yêu cầu xóa dữ liệu của bạn có thực sự chạy thông suốt từ đầu đến cuối không. Đây cũng là lúc bạn bắt đầu đối chiếu dữ liệu sử dụng thật với giả định mà MVP của bạn được build để kiểm chứng.

GDPR hay KVKK có liên quan đến ứng dụng của một startup nhỏ không?

Nếu bạn có người dùng ở EU, GDPR áp dụng bất kể quy mô công ty của bạn. Nếu bạn có người dùng ở Thổ Nhĩ Kỳ, KVKK áp dụng theo cách tương tự. Không luật nào có ngoại lệ cho startup nhỏ, nên hãy kiểm tra khả năng áp dụng trong lúc xác định phạm vi, chứ không phải sau khi bạn đã có dữ liệu người dùng thật để bảo vệ.

Về tác giả

Mert Batur là Đồng sáng lập của Techsy.io, nơi đội ngũ ship các AI agent, hệ thống tự động hóa và pipeline voice/SDR cho khách hàng B2B. Anh viết về stack công cụ LLM mà đội Techsy thực sự dùng trong production. Kết nối trên LinkedIn.

Kết luận

Một checklist ứng dụng di động cho startup chỉ xứng đáng có chỗ nếu nó đủ cụ thể để hành động ngay hôm nay: định nghĩa MVP trong một câu, gắn analytics trước khi build, rà soát quy ước phiên bản vào tuần trước khi nộp, và tách checklist iOS với Android thay vì coi chúng như một danh sách. Chỉ riêng các mục xóa tài khoản và chính sách quyền riêng tư đã chiếm phần lớn những lần từ chối có thể tránh được mà chúng tôi thấy.

Hãy in checklist ra, làm qua từng giai đoạn, và đừng bỏ qua tuần đầu tiên lên sóng, đó là phần mà mọi checklist của đối thủ đều bỏ sót, và là phần thực sự quyết định lần ra mắt của bạn có đứng vững hay không. Nếu bạn muốn có một đôi mắt thứ hai rà soát lần nộp duyệt trước khi gửi đi, nhận tư vấn miễn phí →