Bị App Store từ chối theo 2.1 App Completeness: kế hoạch kiểm thử bản release trước khi gửi lại (2026)

Bị App Store từ chối theo 2.1 App Completeness nghĩa là người xét duyệt không thể dùng ứng dụng của bạn như một khách hàng thực. Có thể ứng dụng đã crash, hiển thị nội dung giữ chỗ, chặn họ ở màn hình đăng nhập hoặc ẩn một giao dịch mua trong ứng dụng. Cách khắc phục hiếm khi chỉ là sửa một dòng code. Trước khi gửi lại, hãy chạy một kế hoạch kiểm thử ngắn trên bản build release, với một bản cài mới và đúng thông tin đăng nhập bạn cung cấp cho App Review. Bài viết này đi qua kế hoạch đó và cho thấy các nhà phát triển khác đã khắc phục cùng kiểu từ chối này như thế nào.

Nguyên tắc 2.1 App Completeness của App Store kiểm tra những gì?

Nguyên tắc 2.1 kiểm tra rằng bản build bạn gửi là một ứng dụng hoàn chỉnh, hoạt động được. Nó cần metadata đầy đủ, các liên kết hoạt động, một tài khoản đăng nhập demo, backend đang chạy và các giao dịch mua trong ứng dụng mà người xét duyệt có thể tìm thấy và sử dụng.

App Review Guidelines của Apple chia 2.1 thành hai phần. 2.1(a) nói rằng bài gửi “phải là phiên bản cuối cùng, kèm đầy đủ metadata cần thiết và các URL hoạt động hoàn toàn”, đồng thời văn bản giữ chỗ và website trống phải được gỡ bỏ. Phần này cũng yêu cầu bạn kiểm thử trên thiết bị để tìm lỗi và đánh giá độ ổn định, và “cung cấp thông tin tài khoản demo (và bật dịch vụ backend của bạn!) nếu ứng dụng có đăng nhập”. Apple “sẽ từ chối các app bundle chưa hoàn chỉnh và các binary bị crash hoặc có vấn đề kỹ thuật rõ ràng”. 2.1(b) nói rằng giao dịch mua trong ứng dụng phải “đầy đủ, được cập nhật, hiển thị với người xét duyệt và hoạt động được”. Nếu một giao dịch mua đã cấu hình không thể tìm thấy trong ứng dụng, hãy giải thích lý do trong ghi chú xét duyệt.

Kiểu từ chối này rất phổ biến. Trang Preparing for App Review của Apple viết: “Trung bình, hơn 40% vấn đề chưa được giải quyết liên quan đến nguyên tắc 2.1: App Completeness, bao gồm crash, nội dung giữ chỗ, thông tin chưa đầy đủ và nhiều vấn đề khác.”

Vì sao kiểm thử bản debug không phát hiện được vấn đề 2.1?

Bản build debug không chạy giống bản mà người xét duyệt nhận được. Người xét duyệt cài một bản build release được ký để phân phối trên một thiết bị sạch, không có phiên đăng nhập đã lưu và không có lối tắt debug nào.

Simulator của bạn đã đăng nhập sẵn. API cục bộ có thể trỏ đến một server staging không bao giờ sập. Cờ debug bỏ qua paywall, còn feature flag mặc định đều bật. Người xét duyệt không có bất kỳ thứ nào trong số đó. Trang xét duyệt của Apple cũng yêu cầu bạn “kiểm thử kỹ lưỡng trên các thiết bị chạy phần mềm mới nhất”, nên người xét duyệt có thể dùng phiên bản iOS mới hơn điện thoại kiểm thử của bạn.

TestFlight là cách gần nhất để tái tạo môi trường của người xét duyệt. Theo TestFlight overview, bạn có thể thêm tối đa 100 người kiểm thử nội bộ từ nhóm App Store Connect và tối đa 10.000 người kiểm thử bên ngoài. Bạn có thể kiểm thử một build trong tối đa 90 ngày. Hãy tải lên đúng bản build bạn định gửi, cài nó từ TestFlight trên một thiết bị chưa từng chạy ứng dụng và kiểm thử chính bản đó.

Kế hoạch kiểm thử bản release cần bao gồm những gì trước khi gửi lại?

Kế hoạch kiểm thử bản release kiểm tra mọi điểm mà một người xét duyệt mới có thể bị kẹt: khởi chạy, quyền truy cập, đăng nhập, backend, nội dung, liên kết, giao dịch mua, lỗi mạng và iPad. Hãy chạy các bước theo thứ tự trên build TestFlight và ghi lại từng kết quả để bạn có thể trích dẫn trong ghi chú xét duyệt.

1. Cài mới trên iOS mới nhất. Xóa mọi bản cũ, cài từ TestFlight và khởi chạy khi không có trạng thái nào được lưu. Khởi chạy nguội (cold launch) ba lần và xác nhận phần onboarding không bị crash.
2. Từ chối mọi yêu cầu cấp quyền một lần. Từ chối thông báo, vị trí, camera và theo dõi (tracking). Ứng dụng vẫn phải đến được một màn hình dùng được. Đồng thời xác nhận Info.plist có usage description cho mọi tài nguyên được bảo vệ mà ứng dụng hoặc các SDK của nó sử dụng.
3. Đăng nhập bằng đúng thông tin tài khoản demo. Sao chép chúng từ App Store Connect, không phải từ trình quản lý mật khẩu của bạn. Tài khoản phải có dữ liệu thực tế, không cần xác minh email và không dùng xác thực hai yếu tố gắn với điện thoại của bạn.
4. Xác nhận backend là production và đang hoạt động. Build phải trỏ đến các endpoint production. Giới hạn tần suất (rate limit), danh sách IP được phép và chặn theo vị trí địa lý không được khóa người xét duyệt bên ngoài. Nguyên tắc 2.1(a) yêu cầu bạn bật dịch vụ backend.
5. Đi qua mọi tab và màn hình. Tìm lorem ipsum, các màn hình “Sắp ra mắt”, trạng thái trống không có giải thích, hình ảnh thử nghiệm và các nút không làm gì cả.
6. Nhấn vào mọi liên kết. Bao gồm chính sách quyền riêng tư, hỗ trợ, điều khoản và mọi web view. Apple nói rằng “Tất cả ứng dụng đều bắt buộc có liên kết đến trang hỗ trợ người dùng với thông tin liên hệ cập nhật và liên kết đến chính sách quyền riêng tư.”
7. Mở mọi giao dịch mua trong ứng dụng. Đăng nhập bằng một tài khoản mới. Kiểm tra rằng từng sản phẩm được gửi kèm phiên bản này đều hiển thị giá, có thể mua trong sandbox và tính năng Restore Purchases hoạt động.
8. Kiểm thử với mạng chậm hoặc bị ngắt. Bật chế độ máy bay giữa chừng một luồng thao tác. Một thông báo lỗi rõ ràng là chấp nhận được. Một vòng xoay tải không bao giờ dừng, hoặc crash, thì không.
9. Kiểm tra iPad nếu bạn hỗ trợ. Nếu ứng dụng chạy trên iPad, hãy khởi chạy trên đó và đảm bảo bố cục không khiến người dùng bị mắc kẹt.

Tài khoản demo ở bước 3 gây ra nhiều lần bị từ chối lặp lại hơn bất kỳ bước nào khác. Hướng dẫn thiết lập tài khoản demo cho App Store review của chúng tôi trình bày cách tạo một tài khoản dùng được lâu dài.

Làm sao để đối chiếu thông báo từ chối 2.1 với cách khắc phục?

Để đối chiếu một lần bị từ chối theo 2.1 với cách khắc phục, hãy đọc câu ngay sau số nguyên tắc. Câu đó nêu triệu chứng, và mỗi triệu chứng chỉ đến một bước trong kế hoạch kiểm thử.

Giả sử một ứng dụng theo dõi thói quen bị từ chối với thông báo “We were unable to review the app because it crashed on launch” (Chúng tôi không thể xét duyệt ứng dụng vì nó bị crash khi khởi chạy). Một ghi chú thứ hai cho biết người xét duyệt không tìm thấy các giao dịch mua trong ứng dụng. Bảng dưới đây đối chiếu các triệu chứng phổ biến với nguyên nhân, phép kiểm thử và cách khắc phục.

Để có phương pháp tổng quát hơn khi đọc bất kỳ thông báo từ chối nào, hãy xem Bị App Store từ chối: cách khắc phục theo từng nguyên tắc.

Các nhà phát triển khác đã bị từ chối theo 2.1 như thế nào?

Các trường hợp 2.1 công khai đều theo cùng một khuôn mẫu. Ứng dụng chạy tốt trên môi trường của nhà phát triển nhưng thất bại với người xét duyệt vì một điều chỉ lộ ra khi cài mới hoặc khi người lạ đăng nhập.

• Crash do thiếu usage description. Trên diễn đàn Solar2D, một nhà phát triển nhận được thông báo “We were unable to review the app because it crashed on launch” trên iPhone 13 mini chạy iOS 18.3.2, dù ứng dụng chạy được trong TestFlight. Một thành viên khác tìm thấy dòng này trong crash log đính kèm: “This app has crashed because it attempted to access privacy-sensitive data without a usage description” (Ứng dụng đã crash vì cố truy cập dữ liệu nhạy cảm về quyền riêng tư mà không có usage description). Nhà phát triển cho biết: “Đã được duyệt sau khi thêm: NSUserTrackingUsageDescription.”
• Đăng nhập mạng xã hội mà người xét duyệt không dùng được. Một nhà phát triển trên Apple Developer Forums cho biết họ liên tục bị từ chối theo 2.1 vì người xét duyệt “không thể dùng đăng nhập mạng xã hội”. Họ đã cung cấp tài khoản demo Apple và Google, nhưng việc đăng nhập bằng Apple ID cần mã xác minh gửi về điện thoại của nhà phát triển. Nhân viên Apple trả lời rằng App Review sẽ liên hệ trực tiếp với họ. Không có cách khắc phục nào được đăng công khai.
• Giao dịch mua trong ứng dụng “không tìm thấy trong binary đã gửi”. Trong một chủ đề trên cộng đồng RevenueCat, một nhà phát triển bị từ chối vì gói hàng tháng không được tìm thấy trong binary, dù giao dịch mua trong sandbox vẫn hoạt động. Một người hỗ trợ cho biết một trường hợp từ chối tương tự đã được giải quyết bằng cách trả lời kèm hướng dẫn chi tiết và ảnh chụp màn hình mọi đường dẫn đến paywall. Nhân viên RevenueCat khuyên nên hiển thị mọi sản phẩm đã gửi trên paywall mặc định và không đưa các tệp StoreKit test vào scheme Archive.

Trong cả ba trường hợp, kiểm thử của chính nhà phát triển đều đạt. Lỗi chỉ xuất hiện từ điểm xuất phát của người xét duyệt: không có điện thoại nhận mã 2FA, không có phiên đăng nhập trước và không biết paywall nằm ở đâu. Kế hoạch kiểm thử ở trên tái tạo chính điểm xuất phát đó.

Ghi chú cho App Review nên viết gì sau khi bị từ chối theo 2.1?

Ghi chú xét duyệt sau khi bị từ chối theo 2.1 nên cung cấp thông tin tài khoản demo hoạt động được, liệt kê những gì đã thay đổi so với build bị từ chối, và nói rõ chỗ tìm các giao dịch mua trong ứng dụng cũng như mọi tính năng khó thấy.

Trang xét duyệt của Apple yêu cầu đặt thông tin tài khoản và cấu hình đặc biệt trong mục App Review Information. Nếu một tính năng cần phần cứng hoặc môi trường khó thiết lập, hãy “chuẩn bị sẵn video demo hoặc phần cứng”. Nguyên tắc 2.3.1(a) bổ sung rằng tính năng mới phải được mô tả “một cách cụ thể” trong Notes for Review, và “mô tả chung chung sẽ bị từ chối”. Một ghi chú ngắn, có cấu trúc sẽ hiệu quả:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Nếu nghĩa vụ pháp lý hoặc bảo mật không cho phép dùng tài khoản demo, nguyên tắc 2.1(a) cho phép chế độ demo tích hợp sẵn, nhưng chỉ khi có sự chấp thuận trước của Apple, và chế độ đó phải thể hiện đầy đủ tính năng và chức năng của ứng dụng. Đừng chuyển sang chế độ demo khi chưa có sự chấp thuận đó.

Làm sao để gửi lại hoặc kháng nghị khi bị từ chối theo 2.1?

Để gửi lại sau khi bị từ chối theo 2.1, hãy tải lên hoặc chọn bản build bạn đã kiểm thử, trả lời App Review trong App Store Connect về những gì bạn đã thay đổi, cập nhật ghi chú xét duyệt và gửi lại. Chỉ kháng nghị nếu bạn tin rằng người xét duyệt đã hiểu sai ứng dụng.

1. Kiểm tra rằng số build gắn với phiên bản trong App Store Connect khớp với build TestFlight bạn đã kiểm thử.
2. Trả lời thông báo từ chối bằng một bản tóm tắt ngắn cho từng bản sửa lỗi. Với vấn đề về giao dịch mua hoặc điều hướng, hãy thêm hướng dẫn từng bước và ảnh chụp màn hình.
3. Cập nhật mục App Review Information với thông tin đăng nhập và ghi chú hiện tại.
4. Gửi xét duyệt. Tính đến tháng 10/2026, Apple cho biết họ thường xét duyệt “ít nhất 50% bài gửi trong vòng dưới 24 giờ và 90% trong vòng dưới 48 giờ”.

Nếu bạn tin rằng Apple đã sai, trang App Review cho phép bạn kháng nghị lên App Review Board. Hãy đưa ra lý do cụ thể vì sao ứng dụng tuân thủ, và “Chỉ gửi một lần kháng nghị cho mỗi bài gửi không vượt qua xét duyệt.” Tuy vậy, với lần bị từ chối theo 2.1, tái hiện vấn đề trên một thiết bị sạch thường nhanh hơn tranh luận. Nếu bạn muốn giao lại việc gửi lại cho người khác, dịch vụ gửi ứng dụng lên App Store của chúng tôi bao gồm chuẩn bị xét duyệt và xử lý phản hồi từ chối cho cả hai store với giá $599, chưa bao gồm phí tài khoản nhà phát triển.

Các vấn đề 2.1 thường quay lại ở những bản cập nhật sau: một feature flag mới, một API key được xoay vòng hoặc một tài khoản demo đã hết hạn. Hãy thêm kế hoạch kiểm thử này vào quy trình phát hành, cùng với checklist gửi ứng dụng lên App Store. Với các bản cập nhật, phát hành theo giai đoạn giúp hạn chế số người dùng gặp phải một lỗi bị bỏ sót. Để nhận ý kiến thứ hai về một build bị từ chối, hãy gửi email kèm thông báo từ chối đến yagyeshsrbobde@gmail.com.