Những lý do phổ biến nhất khiến app bị Apple từ chối — và cách tránh
Đội ngũ App Review của Apple từ chối phần lớn bản nộp đầu tiên vì một danh sách lý do khá ngắn và dễ đoán. Đây là những lý do đó và cách xử lý trước khi nộp.
Tóm tắt nhanh
- Phần lớn lỗi bị từ chối lần đầu là vấn đề về guideline và metadata, không phải bug code — luồng bị gãy, purpose string thiếu, tài khoản demo không hoạt động.
- App Completeness (2.1) và Minimum Functionality (4.2) chiếm phần lớn lý do từ chối với các app đơn giản hoặc dựng từ template.
- Mỗi quyền truy cập (camera, vị trí, thông báo, tracking) cần một purpose string cụ thể, trung thực — nội dung chung chung rất dễ bị từ chối.
- Nếu app bị từ chối, Resolution Center cho phép bạn phản hồi trực tiếp reviewer thay vì nộp lại mù quáng.
App Completeness (Guideline 2.1)
Đây là lý do từ chối phổ biến nhất với người nộp lần đầu: luồng điều hướng bị gãy, còn sót text/hình ảnh placeholder, tính năng không hoạt động, hoặc app crash ngay khi mở trên máy của reviewer.
Một lỗi thường gặp và dễ tránh: tài khoản demo/test cung cấp trong ghi chú App Review không còn hoạt động vào lúc reviewer thử. Hãy kiểm tra lại ngay trước khi nộp, chứ không phải lúc bạn mới viết ghi chú.
Minimum Functionality (Guideline 4.2)
Apple từ chối các app quá mỏng để xứng đáng tồn tại như một app native — một website đóng gói lại không có thêm chức năng, hoặc một app lặp lại thứ đã có sẵn trên Safari/app khác mà không có lý do rõ ràng để cài riêng.
Cách khắc phục không nhất thiết là "thêm tính năng" — mà là đảm bảo app làm được điều gì đó thực sự hưởng lợi từ việc là app native: truy cập offline, tích hợp thiết bị, thông báo, hoặc trải nghiệm thực sự tốt hơn bản web.
Quyền riêng tư & permission
Mỗi lời nhắc quyền (camera, vị trí, thông báo, danh bạ, tracking) cần một purpose string trong Info.plist giải thích cụ thể lý do app cần quyền đó — "app cần vị trí của bạn" là chưa đủ cụ thể.
Thông tin App Privacy trong App Store Connect cần khớp với những gì app thực sự thu thập. Sự không khớp giữa khai báo và hành vi thực tế của app là một lý do từ chối phổ biến, nên hãy đối chiếu phần khai báo App Privacy với bản build trước mỗi lần nộp.
Metadata & ảnh chụp màn hình
- Ảnh chụp màn hình phải phản ánh đúng giao diện app — không dùng mockup thể hiện tính năng hoặc nội dung không có trong bản build.
- Tên app, subtitle và mô tả không nên nhắc đến nền tảng khác, tên app khác, hay so sánh trực tiếp.
- Nhồi nhét từ khóa vào tên app để lách thứ hạng tìm kiếm là vi phạm chính sách, không chỉ là cách làm thiếu chuyên nghiệp.
Nên làm gì khi bị từ chối
Đọc kỹ số guideline được trích trong thông báo từ chối trước khi sửa bất cứ điều gì — nó cho biết chính xác phần nào cần đọc lại. Resolution Center cho phép bạn phản hồi trực tiếp reviewer nếu lý do chưa rõ hoặc bạn cho rằng có sự hiểu nhầm, thay vì đoán mò và nộp lại mù quáng.
Chỉ sửa đúng phần bị trích dẫn, test lại chính xác luồng đó, và ghi rõ trong phản hồi những gì đã thay đổi — để reviewer dễ kiểm chứng bản sửa.
Nên phản hồi trong Resolution Center hay nộp lại luôn?
Hãy phản hồi trước khi lý do chưa rõ hoặc bạn cho rằng reviewer hiểu sai app. Chỉ nộp lại khi đã sửa đúng phần guideline được trích dẫn.
Purpose string như thế nào thì được chấp nhận?
Nêu rõ tính năng cần quyền và lợi ích cho người dùng, ví dụ: "Vị trí của bạn được dùng để hiển thị cửa hàng trong bán kính 5 km." Tránh câu chung chung có thể áp dụng cho bất kỳ app nào.
Nếu reviewer thử một luồng mà tôi nghĩ đã test rồi thì sao?
Đọc lại guideline được trích, rồi test đúng đường đi reviewer có thể đã thử, kể cả lần mở app đầu tiên và đăng nhập. Nếu là hiểu nhầm, hãy giải thích từng bước trong Resolution Center và đính kèm video quay màn hình ngắn.