Bài viết này mô tả quy trình mà các cửa hàng thực hiện khi xem xét các bản gửi ứng dụng, đồng thời cung cấp các mẹo giúp ứng dụng được chấp thuận nhanh hơn. Nội dung được tham khảo từ các hướng dẫn gửi bài chính thức:

• Hướng dẫn gửi ứng dụng lên App Store
• Hướng dẫn gửi ứng dụng lên Google Play Store

Người dùng Adapty cần đặc biệt chú ý đến các vấn đề tuân thủ liên quan đến paywall và in-app purchase. Đây là một trong những lý do phổ biến nhất khiến ứng dụng bị từ chối.

Trước khi bắt đầu

Hãy xác nhận rằng ứng dụng của bạn đã sẵn sàng để nộp.

Adapty cung cấp một danh sách kiểm tra trước khi phát hành để giúp bạn chuẩn bị ứng dụng trước khi đăng tải.

Google Play Store yêu cầu các nhà phát hành lần đầu kiểm thử ứng dụng trước khi nộp. Quá trình kiểm thử phải có ít nhất 12 người tham gia và kéo dài tối thiểu 14 ngày liên tiếp. Yêu cầu này được áp dụng từ năm 2025 nhằm giảm số lượng ứng dụng lỗi đến tay đội ngũ kiểm duyệt của Google.

Tổng quan về quy trình đánh giá

Bước 1: Kiểm tra tự động

Cả App Store và Google Play Store đều theo quy trình đánh giá hai bước tương tự nhau. Ngay sau khi nộp, ứng dụng của bạn sẽ trải qua quá trình quét tự động, có thể mất đến vài giờ. Cả hai cửa hàng đều quét ứng dụng của bạn để tìm phần mềm độc hại, trong đó Google đặc biệt chú trọng vào quá trình này. Google tìm kiếm các dấu hiệu hành vi của hoạt động độc hại, như việc kết nối với các máy chủ đáng ngờ và truy cập dữ liệu người dùng không có lý do chính đáng. Nếu ứng dụng của bạn bị đánh giá là có khả năng gây hại, nó sẽ bị gắn cờ và chuyển đến một chuyên gia phân tích bảo mật để xem xét thủ công. Tài liệu Google Play Protect có danh sách gần đúng các kiểm tra được thực hiện trong bước này. Các cửa hàng cũng xác nhận sự hiện diện của metadata cần thiết, không có các dependency độc hại hoặc quá lỗi thời, và tính toàn vẹn của bản build.

Bước 2: Đánh giá thủ công

Sau khi ứng dụng của bạn vượt qua bước sàng lọc tự động, nó sẽ được một người đánh giá xem xét trực tiếp. Bước này có thể mất đến vài ngày, tùy thuộc vào độ phức tạp của ứng dụng và hàng đợi đánh giá hiện tại. Các ứng dụng xử lý dữ liệu nhạy cảm sẽ mất nhiều thời gian hơn để được xem xét.

Yêu cầu chung

Tính ổn định

Các ứng dụng bị crash trong quá trình kiểm duyệt sẽ bị từ chối. Người kiểm duyệt có thể cố tình mô phỏng điều kiện mạng không ổn định, vì vậy ứng dụng phải xử lý tốt tình huống này.

Tính đầy đủ

Cả Apple lẫn Google đều yêu cầu tính đầy đủ (“chức năng tối thiểu”) đối với nội dung trên cửa hàng.

• Placeholder, màn hình “sắp ra mắt”, và các tính năng bị lỗi đều có thể khiến ứng dụng iOS bị từ chối.
• Google linh hoạt hơn, đặc biệt nếu ứng dụng của bạn đang ở giai đoạn Early Access.
• Cả hai cửa hàng đều từ chối ứng dụng có ít hoặc không có chức năng. Điều này bao gồm các ứng dụng chỉ hiển thị một hình ảnh, file PDF, hoặc trang web.

Nội dung bị thiếu cũng rơi vào cùng danh mục này.

• Nếu ứng dụng không thực hiện được những gì bạn quảng cáo, nó sẽ bị từ chối.
• Nếu bạn cấu hình một in-app purchase trong dashboard nhưng không đưa nó vào bản build, ứng dụng sẽ bị từ chối.

Độ chính xác của metadata

Thông tin sai lệch, không chính xác, hoặc không nhất quán trong mô tả, ảnh chụp màn hình, và các metadata khác có thể dẫn đến việc bị từ chối.

Không sử dụng trang danh sách trên store để quảng cáo các tính năng tương lai của ứng dụng.

Nếu ứng dụng không được thiết kế cho công chúng nói chung, người kiểm duyệt sẽ yêu cầu tài liệu bổ sung giải thích quy trình hoạt động. Hãy bao gồm hướng dẫn rõ ràng trong metadata của ứng dụng.

Xếp hạng nội dung

Nội dung bên trong ứng dụng phải phù hợp với xếp hạng đã khai báo.

Khía cạnh pháp lý

• Chính sách quyền riêng tư của ứng dụng phải có thể truy cập từ bên trong ứng dụng. Bạn có thể sử dụng nút liên kết của Paywall Builder.
• Yêu cầu người dùng đọc và chấp nhận bất kỳ thỏa thuận pháp lý nào trước khi chúng có hiệu lực.
• Công khai sự hiện diện của quảng cáo trong ứng dụng. Không làm điều này có thể dẫn đến bị từ chối.
• Nếu ứng dụng iOS của bạn bao gồm in-app purchase, bạn phải chấp nhận Paid Apps Agreement trong dashboard App Store Connect.

Xác thực

Nếu một phần nội dung của ứng dụng chỉ có thể truy cập sau khi xác thực, hãy cung cấp thông tin đăng nhập hợp lệ cho người kiểm duyệt. Không thể truy cập đầy đủ nội dung là lý do hợp lệ để bị từ chối.

Nếu ứng dụng cho phép người dùng tạo tài khoản, nó cũng phải cho phép họ xóa tài khoản. Việc hướng người dùng đến hỗ trợ qua email hoặc website không đáp ứng yêu cầu này.

Quyền truy cập và quyền riêng tư

Metadata của ứng dụng phải nêu rõ lý do cho mỗi quyền được yêu cầu. Các quyền nhạy cảm nhất (ví dụ: quyền truy cập tin nhắn và nhật ký cuộc gọi) có thể yêu cầu video minh họa.

Nguyên tắc tương tự áp dụng với dữ liệu người dùng nhạy cảm: nếu bạn yêu cầu dữ liệu đó, hãy giải thích tại sao.

Yêu cầu liên quan đến IAP

Vi phạm chính sách kinh doanh là một trong những lý do phổ biến nhất khiến ứng dụng bị từ chối. Nếu phương thức kiếm tiền chính của ứng dụng là gói đăng ký và in-app purchase, ứng dụng sẽ bị kiểm tra kỹ lưỡng hơn.

Yêu cầu đối với paywall

Người kiểm duyệt ứng dụng kỳ vọng các paywall phải rõ ràng, dễ hiểu.

Nếu bị nghi ngờ thao túng người dùng, ứng dụng sẽ bị từ chối. Nếu nhiều lần kiểm duyệt phát hiện bằng chứng về hành vi gian lận, tài khoản của bạn có thể bị vô hiệu hóa và ứng dụng bị tạm ngưng. Google Play áp dụng hệ thống cảnh báo có thể dẫn đến việc xóa toàn bộ ứng dụng của bạn. Tuân thủ các nguyên tắc sau trong thiết kế paywall:

• Hãy minh bạch và rõ ràng ngay từ đầu.

  Hiển thị đầy đủ giá, tần suất thanh toán, lợi ích và điều kiện hủy của từng sản phẩm trước khi yêu cầu người dùng mua hàng.

  Phân biệt rõ ràng giữa sản phẩm mua một lần và sản phẩm yêu cầu thanh toán định kỳ.

  Nếu sản phẩm có dùng thử miễn phí, hãy nêu rõ thời gian và điều kiện của nó.

  Không sử dụng ngôn ngữ cố ý gây nhầm lẫn để đánh lừa người dùng.

• Nhất quán.

  Giá sản phẩm phải khớp nhau trên trang App Store, màn hình trong ứng dụng, màn hình quản lý gói đăng ký và nội dung marketing. Bất kỳ sự không khớp nào về giá, dù nhỏ, đều có thể bị từ chối.

  Paywall Builder của Adapty tự động đồng bộ giá giữa paywall và sản phẩm trong App Store Connect của bạn. Nếu paywall được code thủ công, bạn cần lấy giá của từng sản phẩm từ mảng dữ liệu của nó.

• Hiển thị tất cả các gói đồng đều.

  Không chọn sẵn tuỳ chọn đắt nhất, cũng không ẩn các tuỳ chọn rẻ hơn.

• Tránh “dark patterns”.

  Không tạo cảm giác cấp bách hoặc khan hiếm giả tạo.

  Không ép người dùng mua hàng bằng cách cố tình làm cho các tính năng miễn phí trở nên bất tiện hoặc khó tìm.

  

Đảm bảo quyền truy cập

Ứng dụng phải đảm bảo quyền truy cập của người dùng vào các sản phẩm họ đã mua.

• Truy cập ngay lập tức

  Một giao dịch mua thành công phải mở khóa quyền truy cập vào sản phẩm ngay lập tức, không có độ trễ hiển thị.

  Các trạng thái trung gian của quá trình xác thực thanh toán không được gây ra lỗi hay làm gián đoạn trải nghiệm người dùng.

  Một giao dịch mua thành công phải ẩn paywall ngay lập tức. Nếu bạn tiếp tục hiển thị paywall sau khi mua hàng, bạn đang ngăn người dùng truy cập vào nội dung họ đã trả tiền.

• Khôi phục quyền truy cập Người dùng cần có khả năng khôi phục quyền truy cập vào sản phẩm từ thiết bị mới. Hãy đặt nút khôi phục ở vị trí dễ thấy.

Nếu bạn xây dựng paywall bằng Flow Builder, nút khôi phục sẽ tự động kích hoạt quá trình khôi phục. Nếu bạn tự triển khai paywall thủ công, hãy thêm code để gọi phương thức restorePurchases. Adapty sẽ khôi phục mức độ truy cập của người dùng, trừ khi bạn sử dụng SDK ở chế độ observer mode. Ứng dụng cần có khả năng nhận diện các in-app purchase được thực hiện từ trang sản phẩm trên cửa hàng, hoặc từ các vị trí khác trong app store.

Phương thức thanh toán phù hợp

Cả hai cửa hàng đều cấm bán hàng hóa vật lý thông qua in-app purchase và yêu cầu sử dụng hệ thống thanh toán của cửa hàng cho hầu hết các sản phẩm kỹ thuật số.

Yêu cầu này không áp dụng ở một số khu vực địa lý, bao gồm Mỹ và EU. Tùy theo từng quốc gia, bạn có thể bỏ qua hoàn toàn hệ thống thanh toán của cửa hàng, hoặc cho người dùng lựa chọn giữa thanh toán qua app store và phương thức thanh toán thay thế. Một số danh mục ứng dụng (chẳng hạn như ứng dụng đọc sách điện tử hoặc ứng dụng hẹn hò) có thể đủ điều kiện sử dụng phương thức thanh toán thay thế ngay cả ngoài các khu vực này. Hãy kiểm tra hướng dẫn chính thức của các cửa hàng để biết thêm chi tiết.

Lưu ý rằng cả hai cửa hàng đều có quy định về tích hợp nhà cung cấp thanh toán, và vẫn tiếp tục thu phí hoa hồng cho các giao dịch sử dụng những dịch vụ này.

Xử lý khi bị từ chối

Nếu ứng dụng của bạn bị từ chối, người đánh giá sẽ nêu rõ hướng dẫn nào bị vi phạm. Hãy đọc kỹ hướng dẫn đó và khắc phục:

• Hướng dẫn gửi ứng dụng lên App Store
• Hướng dẫn gửi ứng dụng lên Google Play Store

Nếu bạn cho rằng việc từ chối là không công bằng, bạn có quyền khiếu nại. Hãy cung cấp bằng chứng tuân thủ và liên hệ với cửa hàng.

• Không cập nhật ứng dụng trong khi đang được xem xét.
• Mỗi lần bạn gửi ứng dụng để xem xét, bạn có thể gặp một người đánh giá khác. Điều này có thể có lợi hoặc bất lợi cho bạn.
• Không sửa từng vấn đề một. Hãy gửi ứng dụng để xem xét lại khi tất cả các sửa đổi đã được hoàn tất.
• Nếu Google Play từ chối ứng dụng của bạn vì vi phạm chính sách, hãy cập nhật dữ liệu liên quan trên tất cả các track, kể cả những track đang tạm dừng hoặc không hoạt động.
• Các lần xem xét tiếp theo thường mất ít thời gian hơn lần đầu.
• Xem xét nhanh có thể áp dụng cho các lỗi nghiêm trọng và các deadline khẩn cấp — hãy dùng tiết kiệm.

Sau khi xét duyệt: giám sát liên tục

Cả hai cửa hàng đều tiếp tục theo dõi ứng dụng của bạn ngay cả sau khi ứng dụng vượt qua quá trình xét duyệt.

Nếu chức năng của ứng dụng thay đổi sau khi được phê duyệt (ví dụ: do code được tải động), ứng dụng sẽ bị gắn cờ và gỡ khỏi danh sách. Một lượng lớn phản hồi tiêu cực từ người dùng cũng là lý do để ứng dụng bị xem xét thêm.

Trong giai đoạn 2024–2025, Google đã xóa 47% ứng dụng trên Play Store nhằm nâng cao chất lượng trung bình của nền tảng. Việc bỏ bê ứng dụng cũng tiềm ẩn rủi ro. Cả Google lẫn Apple đều gỡ các ứng dụng không được cập nhật hoặc không có lượt tải.

Xem thêm

• Kiểm thử sandbox
• Danh sách kiểm tra trước khi phát hành