App Store từ chối ứng dụng: cách khắc phục theo từng guideline (2026)

Bị App Store từ chối nghĩa là bạn nhận được thông báo từ App Review trích dẫn một guideline, mô tả những gì reviewer thấy và giữ bản phát hành lại cho đến khi bạn sửa, giải thích hoặc kháng nghị. Hãy bắt đầu bằng cách biến thông báo đó thành một vấn đề bạn có thể kiểm tra. Bước tiếp theo tùy thuộc vào việc reviewer không dùng được ứng dụng, phát hiện điểm không khớp với chính sách hay cần thêm thông tin. Tính đến tháng 10/2026, App Review Guidelines được cập nhật lần gần nhất vào ngày 16/10/2026, vì vậy hãy kiểm tra số mục hiện hành trước khi trích dẫn.

Thông báo từ chối của App Store thực sự cho bạn biết điều gì?

Thông báo từ chối của App Store nêu tên guideline mà reviewer áp dụng, mô tả hành vi cụ thể họ thấy và liệt kê các bước tiếp theo. Thông báo thường kèm thiết bị, phiên bản iOS và ảnh chụp màn hình.

Hãy lưu toàn bộ thông báo, mọi ảnh chụp màn hình, số build và thông tin thiết bị. Đọc mục được trích dẫn trên trang guidelines hiện hành. Sau đó viết một câu: "Reviewer không thể hoàn tất X vì Y." Nếu thông báo yêu cầu thông tin còn thiếu thay vì báo lỗi, hãy ghi lại chính xác những gì còn thiếu. Nội dung chuẩn của Apple cho mục 2.1 cũng hướng dẫn cách tái hiện lỗi: "Đối với ứng dụng mới, hãy gỡ cài đặt mọi phiên bản trước của ứng dụng khỏi thiết bị, sau đó cài đặt và làm theo các bước để tái hiện lỗi."

• Thông báo có nêu crash, màn hình không truy cập được hoặc tính năng chưa hoàn chỉnh không? Hãy tái hiện luồng đó trên bản release build đã gửi, trên đúng loại thiết bị Apple nêu.
• Thông báo có nhắc đến ảnh chụp màn hình, phần mô tả hoặc review notes không? Hãy kiểm tra xem bạn có thể sửa chỉ bằng metadata hay không.
• Thông báo có nhắc đến thanh toán, đăng nhập, quyền riêng tư hoặc chức năng tối thiểu không? Hãy so sánh hành vi của sản phẩm với guideline được trích dẫn.

App Store thường trích dẫn những guideline nào khi từ chối, và chúng yêu cầu gì?

Mỗi guideline đặt ra một yêu cầu cụ thể, vì vậy hãy đối chiếu số mục được trích dẫn với câu chữ của nó và kiểm tra theo đúng câu chữ đó. Bảng dưới đây trích nội dung hiện hành của các guideline thường xuất hiện trong thông báo từ chối.

Bản cập nhật ngày 16/10/2026 đã thêm mục 2.5.19 cho các tính năng ẩn, không hoạt động hoặc không được mô tả, trước đây thuộc mục 2.3.1. Bản cập nhật này cũng thêm mục 2.3.14 về tài sản sáng tạo và gộp entitlement Music Streaming Services vào entitlement StoreKit External Purchase Link thuộc mục 3.1.1(a). Hãy xem bảng này là điểm khởi đầu, không phải cách sửa chắc chắn thành công. Một guideline có thể bao quát nhiều vấn đề khác nhau, và ví dụ của reviewer mới là trường hợp cụ thể bạn cần giải quyết.

Làm thế nào để khắc phục lỗi từ chối 4.2 minimum functionality?

Hãy khắc phục lỗi từ chối 4.2 bằng cách bổ sung giá trị thực sự cho ứng dụng, không phải bằng cách viết lại phần mô tả. Guideline 4.2 viết: "Nếu ứng dụng của bạn không đặc biệt hữu ích, độc đáo hoặc không 'giống một ứng dụng', nó không thuộc về App Store."

Hãy tự hỏi người dùng có thể làm gì trong ứng dụng khiến nó hữu ích với tư cách một ứng dụng. Họ có thể hoàn thành một luồng công việc, lưu trạng thái có ý nghĩa, sử dụng khả năng của thiết bị theo cách phù hợp với ứng dụng, hoặc có trải nghiệm di động được xây dựng riêng cho thiết bị. Không có danh sách tính năng công khai nào bảo đảm được duyệt. Nếu các luồng đó đã có sẵn, hãy liệt kê chúng trong review notes kèm các bước chính xác và ảnh chụp màn hình. Nếu ứng dụng chủ yếu hiển thị một trang web, nó cần được phát triển thêm về mặt sản phẩm. Thêm thông báo đẩy hoặc một màn hình cài đặt trống chỉ để trông có vẻ native không thay thế được giá trị thực cho người dùng.

Làm thế nào để phản hồi App Review trong App Store Connect?

Phản hồi trong App Store Connect: mở bản gửi từ liên kết vấn đề chưa giải quyết của ứng dụng, nhấp Resolve, rồi nhấp Reply to App Review. Theo trang trợ giúp của Apple, bạn cần có vai trò Account Holder, Admin hoặc App Manager.

1. Trong Apps, chọn ứng dụng.
2. Ở đầu trang, nhấp vào liên kết cho biết có vấn đề chưa được giải quyết.
3. Trong mục In Progress, nhấp Resolve bên cạnh bản gửi.
4. Nhấp Reply to App Review và nhập nội dung.
5. Để đính kèm ảnh chụp màn hình hoặc tài liệu, nhấp Attach File, rồi nhấp Reply.

Apple cho biết bạn có thể trao đổi và đính kèm tệp "cho đến khi gửi lại cho App Review", vì vậy hãy gửi bằng chứng trước khi gửi lại. Giữ phản hồi ngắn gọn và đúng sự thật: nêu những gì đã thay đổi, nằm ở đâu và cách xác minh. Đừng tranh luận về các ứng dụng khác có vẻ làm điều tương tự.

Nên sửa metadata, tải build mới hay kháng nghị?

Sửa metadata và gửi lại cùng build khi chỉ thông tin trên trang ứng dụng bị sai. Tải lên build mới khi hành vi của ứng dụng cần thay đổi. Chỉ kháng nghị khi bạn tin ứng dụng đã tuân thủ guideline.

Hướng dẫn kháng nghị của Apple yêu cầu bạn "giải thích từng điểm cho thấy ứng dụng của bạn đáp ứng" guideline. Hướng dẫn cũng nói không nên kháng nghị sau khi bạn đã sửa lỗi và gửi lại. Một đơn kháng nghị đầy đủ "không bảo đảm" quyết định sẽ bị đảo ngược. Với các ứng dụng đã có trên store, chính sách Bug Fix Submissions trong guidelines cho biết các bản sửa lỗi sẽ không bị trì hoãn vì vi phạm guideline "ngoại trừ những vi phạm liên quan đến vấn đề pháp lý hoặc an toàn".

Các nhà phát triển khác đã khắc phục những lần bị App Store từ chối thực tế như thế nào?

Trong các chủ đề diễn đàn công khai, nhiều lần từ chối 2.1 xuất phát từ khác biệt giữa môi trường của reviewer và của nhà phát triển: mạng, thiết bị hoặc trạng thái cấp quyền khác nhau. Lỗi từ chối 4.2 là vấn đề sản phẩm, nên những chỉnh sửa nhỏ hiếm khi giải quyết được.

Lỗi đăng nhập theo 2.1. Một nhà phát triển trên Apple Developer Forums trích thông báo "Cụ thể, chúng tôi không thể đăng nhập do gặp lỗi", dù bản đang phát hành và bản TestFlight đều đăng nhập được với cùng thông tin. Những nhà phát triển khác trong chủ đề báo cáo các cách sửa khác nhau. Một người sửa được bằng cách "đổi http thành https trên web server". Một người khác, sau ba lần bị từ chối, đã thêm trạng thái "Kiểm tra kết nối của bạn" thay cho vòng tải vô tận. Người thứ ba bỏ iPad khỏi deployment target sau năm lần bị từ chối, cách này né vấn đề bằng việc ngừng hỗ trợ iPad.

Crash khi khởi động. Trên diễn đàn Solar2D, một nhà phát triển nhận được thông báo "Chúng tôi không thể review ứng dụng vì nó bị crash khi khởi động" trên iPhone 13 mini chạy iOS 18.3.2. Crash log đính kèm cho thấy thiếu khóa NSUserTrackingUsageDescription. Nhà phát triển xác nhận: "Ứng dụng đã được duyệt sau khi thêm: NSUserTrackingUsageDescription."

Ứng dụng WebView theo 4.2. Một nhà phát triển trên Apple Developer Forums cho biết ứng dụng dựa trên WebView của họ bị từ chối lần thứ 10. Reviewer đã gửi ảnh chụp menu bên trái và nói rằng nó thiếu nội dung. Các màn hình chính khi đó đã là native, nhưng hai hoặc ba màn hình vẫn mở WebView. Câu trả lời được đánh dấu là đáp án đến từ App Review và đề xuất một buổi tư vấn App Review trực tiếp một-một. Chủ đề không xác nhận ứng dụng đã được duyệt.

So sánh lại: các trường hợp 2.1 được khắc phục bằng cách tái hiện điều kiện của reviewer và đọc crash log. Trường hợp 4.2 bế tắc vì mỗi lần gửi lại chỉ thay đổi một phần của một ứng dụng mà về cơ bản vẫn là website.

Làm thế nào để không bị từ chối lại vì cùng một lý do?

Biến mỗi vấn đề đã giải quyết thành một mục trong checklist phát hành và kiểm tra lại trên bản release build trước mỗi lần gửi. Guidelines của Apple cảnh báo rằng quá trình review "sẽ mất nhiều thời gian hơn" nếu ứng dụng liên tục bị từ chối vì cùng một vi phạm guideline.

• Xóa ứng dụng, sau đó cài mới bản release build trên iPhone và iPad thật.
• Đăng nhập bằng tài khoản review trên một mạng không có server phát triển hay ngoại lệ HTTP.
• Mở từng hộp thoại xin quyền và xác nhận mọi usage description trong Info.plist đều có mặt.
• Bảo đảm mọi in-app purchase đều đã được gửi, hiển thị và được giải thích trong review notes.
• Cập nhật review notes mỗi khi một luồng thay đổi. Đừng dán lại ghi chú từ sáu bản phát hành trước.

Với các vấn đề 2.1, hãy làm theo kế hoạch kiểm thử release build cho lỗi từ chối 2.1 và thiết lập tài khoản demo cho reviewer. Sau đó rà soát checklist gửi duyệt cho build tiếp theo. Nếu thông báo review vẫn khiến bạn bế tắc, hãy gửi chi tiết cho chúng tôi và chúng tôi sẽ giúp bạn xác định phần còn thiếu nằm ở quyền truy cập, metadata hay mã nguồn.