![Tránh bị Apple Reject: 9 lỗi chết người khi submit app lên App Store [2026]](https://photos.vndev.cc/6638b14c817b668552caa207a4d08fff-hero-1.png)
Ai cũng từng ít nhất một lần bị Apple từ chối#
Bạn đã dành 3 tháng phát triển app. Thiết kế UI chỉnh chu, backend ổn định, test trên 5 thiết bị khác nhau. Bạn tự tin nhấn nút “Submit for Review” trên App Store Connect. Rồi 48 giờ sau, email từ Apple hiện lên: “Your app has been rejected.”
Nghe quen không?
Theo dữ liệu từ chính Apple, khoảng 40% app bị từ chối ngay lần đầu submit. Con số này thậm chí cao hơn với developer lần đầu đưa app lên App Store. Không phải vì app của bạn dở — mà vì bạn chưa hiểu rõ App Store Review Guidelines dài hơn 13.000 từ kia thực sự đòi hỏi gì.
Sau khi phân tích toàn bộ guideline chính thức từ Apple và đối chiếu với kinh nghiệm thực tế từ cộng đồng developer Việt Nam, tôi nhận thấy hầu hết các lỗi reject đều rơi vào 9 điểm chết người thuộc 5 nhóm chính. Bài viết này sẽ giúp bạn:
- Nắm rõ 9 lỗi phổ biến nhất khiến app bị từ chối
- Hiểu đúng các quy định về thanh toán, quyền riêng tư và thiết kế
- Có checklist 20 điểm kiểm tra trước khi submit, tiết kiệm hàng tuần chờ đợi
Tại sao developer Việt Nam dễ bị Apple reject hơn?#
Trước khi đi vào từng lỗi cụ thể, cần hiểu bối cảnh. Developer Việt Nam đối mặt với 3 rào cản lớn khi submit app lên App Store:
Thứ nhất, khoảng cách ngôn ngữ. Toàn bộ guideline của Apple được viết bằng tiếng Anh pháp lý, dày đặc thuật ngữ. Một câu như “Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc.” — nếu đọc lướt, bạn dễ bỏ qua và mắc lỗi thanh toán.
Thứ hai, khác biệt hệ sinh thái. Nhiều developer quen với Google Play Store — nơi quy trình review tự động và có phần “dễ thở” hơn. App Store review bằng con người thật, mỗi reviewer đều được đào tạo để phát hiện vi phạm. Họ sẽ thực sự dùng app của bạn.
Thứ ba, thiếu kinh nghiệm với quy chuẩn Apple. Những thứ tưởng nhỏ như: thiếu privacy policy link, không có tài khoản demo cho reviewer, dùng icon vi phạm bản quyền, hay quên khai báo App Tracking Transparency — đều có thể khiến app bị reject ngay lập tức.
Vậy câu hỏi đặt ra là: Làm thế nào để submit app lên App Store thành công ngay lần đầu?
Dưới đây là 9 lỗi phổ biến nhất, phân theo 5 nhóm — cùng giải pháp cụ thể cho từng lỗi.
Nhóm 1: An toàn nội dung — Đừng để app của bạn bị gắn cờ “phản cảm”#
Lỗi số 1: Nội dung người dùng tạo (UGC) không có cơ chế kiểm duyệt#
Đây là lỗi khiến nhiều app social, diễn đàn, dating tại Việt Nam bị reject. Nếu app của bạn cho phép người dùng đăng tải nội dung (bình luận, ảnh, video, livestream), Apple yêu cầu bắt buộc phải có:
- Phương pháp lọc nội dung phản cảm — không nhất thiết phải là AI, có thể là báo cáo thủ công, nhưng phải có cơ chế
- Nút báo cáo nội dung vi phạm — hiển thị rõ ràng, dễ tìm
- Khả năng chặn người dùng lạm dụng — block user feature
- Thông tin liên hệ công khai của nhà phát triển
Đặc biệt, Apple thẳng tay xóa app có UGC dùng cho: nội dung khiêu dâm, chat ẩn danh kiểu Chatroulette, ứng dụng bình chọn ngoại hình (“hot-or-not”), hoặc nền tảng có nguy cơ bắt nạt, đe dọa.
Cách tránh: Trước khi submit, tự kiểm tra: “Nếu một người lạ đăng nội dung phản cảm lên app của tôi, liệu có cách nào để người dùng khác báo cáo và tôi xử lý trong 24 giờ không?” Nếu câu trả lời là không, bạn cần bổ sung ngay.
Lỗi số 2: Xếp hạng độ tuổi không chính xác#
App Store yêu cầu bạn trả lời bảng câu hỏi xếp hạng độ tuổi một cách trung thực. Đây không phải là việc “khai cho nhẹ để được duyệt” — nếu bạn khai app 4+ nhưng thực tế chứa nội dung người lớn, bạo lực nhẹ, hoặc link đến web có cờ bạc, Apple sẽ:
- Reject app ngay lập tức
- Có thể kích hoạt điều tra từ cơ quan quản lý tại một số quốc gia
Đặc biệt, nếu app hướng đến trẻ em (Kids Category), yêu cầu còn khắt khe hơn: không được chứa third-party analytics, không third-party advertising, không link ra ngoài app trừ khi đặt sau parental gate.
Nhóm 2: Hiệu suất & Metadata — App phải “thật” và hoàn chỉnh#
Lỗi số 3: Gửi app chưa hoàn chỉnh#
Apple reviewer sẽ thực sự mở app của bạn lên và dùng thử. Nếu họ gặp:
- Placeholder text kiểu “Lorem ipsum” hoặc “Nội dung đang cập nhật”
- Link chết, website trống
- Crash hoặc lỗi kỹ thuật rõ ràng
- Tính năng ẩn không được mô tả trong Notes for Review
App sẽ bị từ chối ngay. Điều này nghe có vẻ hiển nhiên, nhưng theo Apple, đây vẫn là nguyên nhân reject phổ biến nhất.
Cách tránh: Test app trên thiết bị thật (không chỉ simulator). Nhờ ít nhất một người chưa từng dùng app của bạn mở lên và thao tác — họ sẽ tìm ra những thứ bạn bỏ sót.
Lỗi số 4: Metadata không khớp với thực tế app#
Metadata bao gồm: tên app, mô tả, ảnh chụp màn hình, video preview, từ khóa. Apple cực kỳ khắt khe về tính chính xác của metadata:
- Screenshots phải là ảnh chụp thực tế từ app — không phải ảnh concept, không phải title art, không phải login page
- Tên app giới hạn 30 ký tự — không nhồi nhét từ khóa, không mạo danh app khác
- Mô tả phải đề cập rõ ràng nếu có in-app purchases
- Không được nhắc đến tên nền tảng khác (Android, Samsung…) trong metadata
- Previews chỉ được dùng video screen captures từ chính app — không phải animation quảng cáo
Một lưu ý nhỏ nhưng quan trọng: nếu app của bạn có tính năng mới hoặc phức tạp, hãy mô tả chi tiết trong Notes for Review (phần riêng cho reviewer, không hiển thị công khai). Đừng cho rằng reviewer sẽ “tự khám phá”.
Nhóm 3: Thanh toán & Business — IAP là “con dao hai lưỡi”#
Lỗi số 5: Không dùng In-App Purchase cho nội dung số#
Đây là lỗi tốn kém nhất và cũng là nguyên nhân reject phổ biến nhất trong nhóm Business. Quy tắc của Apple rất rõ ràng:
Bạn PHẢI dùng In-App Purchase nếu muốn mở khóa:
- Đăng ký (subscriptions)
- Tiền tệ trong game, vật phẩm ảo
- Cấp độ game, tính năng cao cấp
- Nội dung số (e-book, nhạc, video, khóa học)
- Mở khóa phiên bản đầy đủ của app
Bạn KHÔNG được phép dùng:
- License keys, QR codes để mở khóa nội dung
- Ví cryptocurrency để thanh toán nội dung trong app
- Link đến website thanh toán khác (trừ khi được Apple cấp entitlement đặc biệt)
Ngoại lệ quan trọng:
- Hàng hóa vật lý (quần áo, đồ ăn, xe cộ…) → dùng Apple Pay hoặc thẻ tín dụng
- Dịch vụ person-to-person (gia sư, tư vấn, fitness training 1-1) → không cần IAP
- Enterprise services bán cho tổ chức → không cần IAP
- Reader apps (tạp chí, báo, sách, nhạc, video) → có thể dùng phương thức riêng
Lỗi số 6: Subscription không cung cấp giá trị liên tục#
Nhiều developer chuyển từ mô hình “mua một lần” sang “subscription” nhưng không thực sự cung cấp giá trị liên tục. Apple yêu cầu:
- Subscription phải cung cấp giá trị liên tục trong suốt thời gian đăng ký
- Thời gian đăng ký tối thiểu: 7 ngày
- Không được lấy đi chức năng chính mà người dùng hiện tại đã trả tiền khi chuyển sang mô hình subscription
- Phải mô tả rõ ràng người dùng nhận được gì với giá đó trước khi yêu cầu thanh toán
Đặc biệt, Apple sẽ xóa app lừa đảo người dùng mua subscription — ví dụ: thiết kế giao diện gây nhầm lẫn để người dùng vô tình đăng ký, hoặc ẩn thông tin hủy đăng ký.
Cách tránh: Đọc lại Guideline 3.1.2(a) và 3.1.2© của Apple. Mô tả subscription của bạn rõ ràng trong Notes for Review — bao gồm: cung cấp gì, giá bao nhiêu, gia hạn thế nào, hủy ra sao.
Nhóm 4: Thiết kế & Chức năng — App phải thực sự là một “app”#
Lỗi số 7: Thiếu chức năng tối thiểu — App chỉ là website đóng gói#
Apple có một tiêu chuẩn đơn giản: Nếu app của bạn không hữu ích hơn website của chính nó, nó không thuộc về App Store.
Những thứ bị từ chối bao gồm:
- Website được bọc trong WebView không có chức năng gốc bổ sung
- App chỉ đơn giản là tập hợp link, content aggregator không có giá trị gia tăng
- App được tạo từ template thương mại hóa (app builder) mà không có nội dung gốc từ chính nhà cung cấp
- App ARKit chỉ đơn giản đặt model vào AR view mà không có tương tác phong phú
Cách tránh: Tự hỏi: “Nếu bỏ WebView đi, app của tôi còn làm được gì?” Nếu câu trả lời là “không gì cả”, bạn cần bổ sung tính năng gốc: camera, GPS, notification, haptic feedback, hoặc ít nhất là offline mode.
Lỗi số 8: Thiếu Sign in with Apple#
Nếu app của bạn sử dụng third-party login hoặc social login (Facebook, Google, Twitter, LinkedIn…) để thiết lập hoặc xác thực tài khoản chính, bạn bắt buộc phải cung cấp Sign in with Apple như một tùy chọn tương đương.
Yêu cầu cụ thể:
- Sign in with Apple phải có giao diện và vị trí tương đương với các nút login khác
- Chỉ thu thập tên và email của người dùng
- Cho phép người dùng chọn ẩn email thật (sử dụng Hide My Email)
- Không thu thập tương tác cho mục đích quảng cáo nếu không có sự đồng ý
Ngoại lệ (không cần Sign in with Apple):
- App dùng hệ thống tài khoản riêng của công ty (không có third-party login nào khác)
- App giáo dục/doanh nghiệp yêu cầu đăng nhập bằng tài khoản tổ chức
- App dùng hệ thống ID công dân/chính phủ
- App là client cho một dịch vụ bên thứ ba cụ thể (ví dụ: app điều khiển thiết bị IoT)
Lỗi số 9: Spam — Nhiều app giống hệt nhau#
Apple nghiêm cấm:
- Tạo nhiều Bundle ID cho cùng một app với thay đổi nhỏ (đổi màu, đổi tên, đổi ngôn ngữ)
- “Chất đống” vào danh mục đã bão hòa với app vô nghĩa (fart apps, flashlight apps, fortune telling…)
- Dùng template app builder để tạo hàng loạt app tương tự
Thay vì tạo 5 app giống hệt nhau cho 5 tỉnh thành, hãy dùng In-App Purchase hoặc cấu hình server để tạo các biến thể trong cùng một app.
Nhóm 5: Quyền riêng tư & Pháp lý — Nhóm lỗi ngày càng bị siết chặt#
Vấn đề cốt lõi: Privacy Policy và sự đồng ý#
Từ iOS 14.5 trở đi, Apple đã biến quyền riêng tư thành “át chủ bài” marketing, và điều này phản ánh rất rõ trong review guidelines. Bạn cần đặc biệt chú ý:
1. Privacy Policy link là bắt buộc — ở mọi nơi
- Trong App Store Connect metadata
- Trong chính app của bạn (thường đặt trong Settings)
- Phải nêu rõ: dữ liệu gì được thu thập, thu thập thế nào, dùng vào mục đích gì
2. Không được ép người dùng cấp quyền
- Chức năng trả phí không được phụ thuộc vào việc người dùng cấp quyền truy cập dữ liệu
- Phải có cách dễ dàng để người dùng rút lại sự đồng ý
- Không thao túng, lừa hoặc ép buộc đồng ý truy cập dữ liệu không cần thiết
3. Data minimization — Chỉ thu thập dữ liệu thực sự cần
- Chỉ yêu cầu dữ liệu liên quan đến chức năng cốt lõi của app
- Nếu có thể dùng out-of-process picker (ví dụ: UIImagePickerController thay vì truy cập toàn bộ thư viện ảnh), hãy làm vậy
4. App Tracking Transparency (ATT)
- Nếu bạn theo dõi người dùng qua các app/website khác, phải hiển thị ATT prompt và có sự đồng ý
- Không được yêu cầu người dùng bật tracking để truy cập chức năng
5. Xóa tài khoản trong app
- Nếu app hỗ trợ tạo tài khoản, phải cho phép xóa tài khoản ngay trong app
- Không chỉ deactivate — phải là xóa hoàn toàn
Các loại dữ liệu đặc biệt bị cấm dùng cho quảng cáo#
Apple cấm tuyệt đối việc sử dụng dữ liệu từ các API sau cho mục đích marketing, quảng cáo hoặc data mining:
- HealthKit & Clinical Health Records
- HomeKit
- Camera APIs & Photo APIs
- ARKit
- ClassKit
- MovementDisorder API
Vi phạm quy tắc này không chỉ khiến app bị reject — nó có thể khiến bạn bị xóa khỏi Apple Developer Program vĩnh viễn.
Checklist 20 điểm: Kiểm tra trước khi nhấn “Submit for Review”#
Trước khi gửi app, hãy chạy qua từng mục trong checklist này. Nếu có bất kỳ mục nào bạn trả lời “Không”, đừng submit vội.
| # | Hạng mục | Đạt? |
|---|---|---|
| 1 | App không crash hoặc có lỗi rõ ràng trên thiết bị thật | ☐ |
| 2 | Không có placeholder text, link chết, hoặc nội dung “đang cập nhật” | ☐ |
| 3 | Tất cả tính năng mới được mô tả chi tiết trong Notes for Review | ☐ |
| 4 | Đã cung cấp tài khoản demo đầy đủ cho reviewer (nếu cần đăng nhập) | ☐ |
| 5 | Backend services đang hoạt động trong thời gian review | ☐ |
| 6 | Screenshots là ảnh chụp thực tế từ app, phản ánh đúng giao diện hiện tại | ☐ |
| 7 | Tên app ≤ 30 ký tự, không nhồi nhét từ khóa, không vi phạm thương hiệu | ☐ |
| 8 | Mô tả app có đề cập rõ ràng đến in-app purchases (nếu có) | ☐ |
| 9 | Xếp hạng độ tuổi được khai báo trung thực | ☐ |
| 10 | Sử dụng In-App Purchase cho tất cả nội dung số cần mở khóa | ☐ |
| 11 | Subscription có mô tả rõ ràng về giá trị, giá, cách hủy | ☐ |
| 12 | Có cơ chế restore cho các IAP có thể khôi phục | ☐ |
| 13 | Privacy policy link có trong App Store Connect VÀ trong app | ☐ |
| 14 | Có sự đồng ý rõ ràng của người dùng trước khi thu thập dữ liệu | ☐ |
| 15 | App Tracking Transparency được triển khai nếu có theo dõi người dùng | ☐ |
| 16 | Cho phép xóa tài khoản trong app (nếu có tính năng tạo tài khoản) | ☐ |
| 17 | Có Sign in with Apple nếu dùng third-party login (Facebook, Google…) | ☐ |
| 18 | App có chức năng gốc thực sự — không chỉ là WebView bọc website | ☐ |
| 19 | Chỉ sử dụng public APIs, không dùng private framework | ☐ |
| 20 | Thông tin liên hệ nhà phát triển chính xác và dễ tìm | ☐ |
Mẹo thực tế: In checklist này ra và dán lên màn hình phụ trong lần review cuối cùng trước khi submit. Nghe có vẻ “thủ công”, nhưng nhiều team iOS developer tại Việt Nam xác nhận cách này giúp họ giảm 70% số lần bị reject so với trước đây.
Câu hỏi thường gặp#
App của tôi bị reject, mất bao lâu để gửi lại và được duyệt?
Sau khi sửa lỗi và gửi lại, thời gian review trung bình là 24-48 giờ. Bạn có thể yêu cầu “Expedited Review” nếu gặp lỗi nghiêm trọng ảnh hưởng đến người dùng hiện tại, nhưng không lạm dụng — Apple giới hạn số lần expedited review mỗi năm (Apple Developer Program, 2026).
Tôi có thể khiếu nại nếu cho rằng app bị reject không đúng không?
Có. App Store Connect có nút “Appeal” trong phần Resolution Center. Bạn cần giải thích rõ lý do app nên được duyệt, kèm bằng chứng (ví dụ: link đến guideline cho thấy bạn đã tuân thủ). Tỷ lệ appeal thành công khoảng 35-40% nếu bạn có lập luận rõ ràng và trích dẫn đúng guideline.
App của tôi dùng WebView để hiển thị nội dung web, có bị reject không?
Không nhất thiết. WebView không bị cấm, nhưng app phải có thêm chức năng gốc (native features) vượt ra ngoài những gì website làm được. Ví dụ: dùng camera để quét QR, push notifications, offline cache, hoặc tích hợp Apple Pay.
Tôi có phải trả 30% hoa hồng cho mọi giao dịch trong app không?
Hầu hết các giao dịch nội dung số (digital goods/services) chịu mức phí 30% (hoặc 15% nếu bạn tham gia App Store Small Business Program với doanh thu dưới 1 triệu USD/năm). Hàng hóa vật lý, dịch vụ person-to-person, và enterprise sales được miễn. Tại EU và Nhật Bản, có thêm các tùy chọn phân phối khác với điều khoản riêng.
Tôi đang phát triển app y tế, cần lưu ý gì thêm?
Apple rất khắt khe với app y tế. Bạn không được phép dùng cảm biến thiết bị (camera, đèn flash) để đo huyết áp, đường huyết, oxy máu. Công cụ tính liều thuốc phải đến từ nhà sản xuất thuốc, bệnh viện, đại học, hoặc được FDA phê duyệt. Nếu app liên quan đến nghiên cứu trên người, phải có phê duyệt từ hội đồng đánh giá đạo đức độc lập.
Review không phải là rào cản — nó là “QA miễn phí”#
Mỗi lần Apple reject app của bạn, hãy nghĩ khác đi một chút: đó là một lần QA miễn phí từ những reviewer chuyên nghiệp, những người đã xem xét hàng trăm ngàn app. Họ phát hiện ra những lỗi mà bạn và team có thể đã bỏ qua.
Quy trình review nghiêm ngặt của Apple tồn tại không phải để làm khó developer. Nó tồn tại để đảm bảo rằng khi người dùng mở App Store, họ tìm thấy những app an toàn, hoàn chỉnh và đáng tin cậy. App của bạn xứng đáng nằm trong số đó — nhưng trước tiên, nó phải vượt qua bài kiểm tra.
Dùng checklist 20 điểm trong bài viết này. Đối chiếu với guideline gốc nếu cần. Và nhớ rằng: lần submit thứ hai luôn dễ dàng hơn lần đầu, vì bạn đã hiểu “luật chơi” rồi.
Nếu bạn thấy bài viết hữu ích, hãy chia sẻ với team iOS developer của mình. Một team hiểu rõ guideline sẽ tiết kiệm hàng tuần thời gian chờ review — và quan trọng hơn, giữ được tinh thần cho lần submit đầu tiên.
