Guideline 4.2 Minimum Functionality: app bị Apple từ chối

Guideline 4.2, "Minimum Functionality", từ chối những app không mang lại gì hơn một trang web, hoặc có quá ít thứ để người dùng muốn giữ lại. Cách chữa không phải là nhồi thêm tính năng native: mà là đặt một tính năng vào trọng tâm của cách dùng app, rồi nói cho reviewer biết tìm nó ở đâu. Việc sửa gần như luôn cần một build mới.

Mình tự phát hành app iOS của mình: Solys, TradaZen và Nolera đều đang có trên App Store. Bài hướng dẫn này dựa trên văn bản chính thức của Apple, mình đọc ngày 15 tháng 10 năm 2026, và trên các lần bị từ chối vì 4.2 mà các lập trình viên đã đăng trên diễn đàn của Apple. Các app bị từ chối nêu bên dưới chỉ là ví dụ. Muốn xem tổng quan mọi lý do từ chối, bạn hãy đọc bài vì sao Apple từ chối app.

Guideline 4.2 nói gì?

Mục 4.2 nằm trong phần 4, "Design", của App Review Guidelines. Câu đầu tiên đặt ra tiêu chí: "Your app should include features, content, and UI that elevate it beyond a repackaged website." Nói cách khác, app của bạn phải có tính năng, nội dung và giao diện giúp nó vượt lên trên một trang web được đóng gói lại.

Văn bản còn thêm hai ý. Một app không thực sự hữu ích, độc đáo hay "giống app" thì không có chỗ trên App Store. Và một app không mang lại giá trị giải trí lâu dài hay đủ hữu ích thì có thể bị từ chối. Vậy 4.2 đánh giá hai thứ: sự khác biệt so với web, và lượng giá trị.

Các quy tắc con mà thông báo có thể nhắc đến

Quy tắc con	Apple yêu cầu gì	Trường hợp bị từ chối điển hình
4.2	Vượt lên trên một trang web	Trang web hiển thị trong WebView
4.2.1	Trải nghiệm thực tế tăng cường thật sự	Một mô hình 3D đặt vào khung nhìn AR
4.2.2	Không chỉ là marketing hay đường link	App giới thiệu, app tổng hợp, link
4.2.3	App độc lập, tải xuống rõ ràng	App bắt buộc phải có app khác
4.2.6	Không phải app làm từ mẫu thương mại	Template do bên dịch vụ nộp lên

Ba điểm cần nói rõ. Mục 4.2.2 có ngoại lệ cho catalog: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." Nên một catalog sản phẩm có thể được duyệt. Một tờ rơi quảng cáo thì không.

Mục 4.2.3 có hai khoản. Khoản (i) yêu cầu app chạy được một mình, không cần cài app khác. Khoản (ii) yêu cầu nếu app phải tải tài nguyên ở lần mở đầu tiên thì phải báo dung lượng tải và xin đồng ý trước.

Mục 4.2.6, về mẫu thương mại và dịch vụ tạo app, được trình bày chi tiết trong bài hướng dẫn guideline 4.3, vì nó đi cùng với quy tắc chống spam.

Hai thông báo 4.2 thường gặp nhất

Thông báo của Apple mở đầu bằng tiêu đề "Guideline 4.2 - Design - Minimum Functionality". Phần sau cho biết reviewer đã thấy vấn đề nào trong hai vấn đề. Dưới đây là hai cách diễn đạt do các lập trình viên đăng trên diễn đàn của Apple. Chúng đã cách đây vài năm: câu chữ chính xác có thể đã đổi, nhưng hai nhóm vấn đề thì không.

App trông giống một trang web. "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience." Thông báo này, được đăng trên diễn đàn của Apple, có một câu mang tính quyết định: "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store."

App quá sơ sài. "We found that the usefulness of your app is limited by the minimal amount of content or features it includes." Thông báo thứ hai này yêu cầu xem lại ý tưởng, và thừa nhận rằng không có quy tắc định lượng nào xác định thế nào là hữu ích hay giải trí.

Thêm thông báo đẩy, định vị và nút chia sẻ vào một trang web được đóng gói là không đủ: chính Apple đã viết điều đó trong các thông báo từ chối của mình.

Bốn trường hợp bị từ chối 4.2 điển hình

Bốn trường hợp dưới đây là ví dụ dựng lên để minh họa quy tắc, không phải app có thật.

Trang web được đóng gói

Ví dụ: một câu lạc bộ thể thao hiển thị trang web mobile của mình trong WebView, kèm một thanh tab native ở trên. Lịch tập, đặt chỗ và tài khoản đều là trang web. Reviewer thấy đúng những gì Safari sẽ cho họ thấy. Apple nói rõ trên trang App Review: một trang web được phục vụ trong app iOS, nội dung web không được tối ưu cho iOS hay tương tác web hạn chế không tạo nên một app chất lượng.

Mình sẽ làm thế này: dựng lại bằng native các màn hình của thao tác chính, ở đây là lịch tập và đặt chỗ. Rồi thêm những thứ trang web không làm được: nhắc trước buổi tập, xem lịch khi không có mạng, buổi tập tiếp theo hiện trong widget.

App quá đơn giản

Ví dụ: một app hiển thị mỗi ngày một câu trích dẫn, và không gì khác. Mười giây là xem hết. Mục 4.2 nói về "lasting entertainment value or adequate utility": giá trị lâu dài, hoặc đủ hữu ích. Để sửa, hãy thêm chiều sâu cho thao tác chính, đừng thêm màn hình xung quanh. Ở đây: lịch sử, mục yêu thích, nhắc nhở vào giờ tự chọn, widget trên màn hình chính.

App tạo bằng AI, không có gì native

Ví dụ: một ô nhập văn bản, một nút bấm, câu trả lời của AI hiện dưới dạng văn bản thô. Apple không đánh giá công cụ, mà đánh giá thứ hiện lên màn hình của reviewer. Nếu trải nghiệm gói gọn được trong một trang web, khả năng cao 4.2 sẽ giáng xuống.

Mình trình bày chi tiết AI làm tốt gì và hỏng gì trong bài tạo app bằng AI. Định dạng mà từng công cụ tạo ra, web app hay dự án mobile, được so sánh trong bài Lovable, Rork hay FlutterFlow.

Cái vỏ chờ nội dung

Ví dụ: một chợ trực tuyến không có tin đăng, một danh bạ trống, một bảng tin hiện "Sắp ra mắt". Reviewer mở một app chẳng có gì để xem. Trường hợp này cũng dính tới 2.1, mục từ chối nội dung tạm: xem bài hướng dẫn guideline 2.1. Hãy gửi app khi đã có nội dung thật, hoặc cung cấp một tài khoản demo đã có sẵn dữ liệu.

Phép thử mình hay làm: "Thế trong Safari thì sao?"

Trước khi gửi, mình tự hỏi liệu một trang web có thể mang lại cùng tính năng chính hay không. Nếu có, app dễ dính 4.2. Đây là bảng mình dùng để đánh giá một tính năng native. Một tính năng có giá trị khi nó phục vụ thao tác chính, không phải khi nó chỉ để trang trí.

Tính năng	Có giá trị khi...	Không đủ khi...
Thông báo	Mang lại thông tin người dùng đang chờ	Chỉ chuyển tiếp bài viết của bạn
Ngoại tuyến	Nội dung chính vẫn dùng được	Chỉ hiện một màn hình lỗi
Widget	Hiển thị dữ liệu riêng của người dùng	Hiển thị logo của bạn
Chia sẻ	Người dùng gửi nội dung vào app của bạn	Chỉ chia sẻ một đường link
Camera, cảm biến	Là một phần của thao tác chính	Mở trang web của bạn
Dữ liệu cục bộ	App tính toán, sắp xếp và ghi nhớ	Mọi thứ nằm trên một trang web

Khuyến nghị của Apple cũng đi theo hướng đó. Một widget hiển thị nội dung cập nhật, đọc được chỉ trong một cái liếc. Một thông báo mang lại thông tin hữu ích, ngắn gọn, và không dùng để thúc người dùng làm một việc trong app.

Những gì app của mình làm được mà trang web không làm được

Mình thiết kế mỗi app quanh một tính năng chính không tồn tại trong trình duyệt, hoặc một giá trị khiến người dùng quay lại.

• Solys là app báo thức. Chuông đi qua AlarmKit, dịch vụ báo thức của iOS 26: nó vượt qua chế độ im lặng, giống báo thức của Apple. Muốn tắt, bạn phải thắng một mini-game, và các app đã chọn vẫn bị tạm khóa sau khi thức dậy. Không trang web nào làm iPhone đổ chuông khi đang im lặng.
• TradaZen là app mô phỏng giao dịch: một biểu đồ thật ở một ngày thật, một quyết định, các nến lần lượt hiện ra, các trận đấu xếp hạng và một thứ hạng tăng dần. Ở đây, không phải tính năng native gánh app. Mà là giá trị giải trí lâu dài mà 4.2 nhắc đến.
• Nolera là app tủ đồ: bạn chụp ảnh quần áo, app tách nền và sắp xếp chúng, rồi gợi ý cho bạn một bộ đồ mỗi sáng. Camera là một phần của thao tác chính. Nó không phải phần phụ.

4.2 không đòi một danh sách tính năng native: nó đòi một lý do để cài app thay vì mở một trang web.

Sửa lỗi bị từ chối 4.2, từng bước một

1. Xác định nhóm vấn đề. Trải nghiệm duyệt web: đó là trang web đóng gói. Nội dung hoặc tính năng tối thiểu: đó là app quá sơ sài. Mục 4.2.3: phụ thuộc vào app khác hoặc tải xuống không báo trước.
2. Thay đổi sản phẩm, không phải câu chữ. Một câu trả lời chỉ tranh luận mà không thay đổi gì thì chẳng có lý do gì để thuyết phục. Dựng lại bằng native các màn hình của thao tác chính, hoặc thêm chiều sâu còn thiếu.
3. Chuẩn bị một build mới. Nguyên nhân nằm trong app: cập nhật từ xa là không đủ. Mỗi lần gửi lại đều phải xếp hàng lại, xem thời gian duyệt App Store.
4. Viết ghi chú review có tính dẫn đường. Trong trang về thông tin cho một lần review đầy đủ, Apple yêu cầu mô tả ý tưởng, tính năng và đối tượng người dùng. Với bản cập nhật: cái gì đã thay đổi, và tìm nó ở đâu.
5. Chỉ kháng nghị khi reviewer đã bỏ sót điều gì đó. Nếu tính năng native của bạn đã có sẵn nhưng không được nhìn thấy, hãy trả lời trong App Store Connect kèm một video ngắn. Kháng nghị lên App Review Board là hợp lý khi app của bạn bị hiểu sai, không phải khi nó sơ sài.

Mẫu ghi chú mình sẽ dùng, bằng tiếng Anh, bạn tự điều chỉnh:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Chỉ viết những gì thực sự có trong build đã gửi. Một tính năng được nhắc đến mà không tìm thấy sẽ khiến bạn bị từ chối lần nữa, lần này theo mục 2.1.

Checklist 4.2 trước khi nộp

• Bạn nói được trong một câu app của bạn làm gì mà trang web không làm được.
• Các màn hình của thao tác chính là native, không phải trang web.
• Mỗi tính năng native phục vụ thao tác chính, và reviewer gặp nó trong chưa đầy hai phút.
• App có nội dung thật ngay từ lần mở đầu tiên, hoặc có tài khoản demo đã có dữ liệu.
• App chạy được một mình, không cần cài app khác.
• Một lượt tải lớn ở lần mở đầu tiên có báo dung lượng và xin đồng ý.
• Ghi chú review mô tả ý tưởng, đối tượng người dùng và vị trí của từng tính năng.
• Nếu ý tưởng của bạn sát giới hạn, bạn đã thử nghiệm nó trước khi code, với một MVP app iOS được khoanh vùng rõ ràng.

Vượt qua 4.2 ngay từ lần nộp tới

Nếu app của bạn vừa bị từ chối vì 4.2, Apple Review Kit giúp bạn tìm lại quy tắc được nhắc đến và yêu cầu của nó, kèm các mẫu ghi chú cho người kiểm duyệt. Nếu bạn vẫn đang xây dựng, lộ trình của iOS Kit bắt đầu từ tính năng chính trước cả dòng code đầu tiên. Muốn có góc nhìn của người thật, hãy đặt một giờ với mình. Toàn bộ quy trình có trên trang app bị Apple từ chối.

Nếu bạn đang chuẩn bị ra mắt lần đầu, hãy làm bài chẩn đoán miễn phí: nó sắp xếp lại các bước theo đúng thứ tự và gửi cho bạn checklist chống bị Apple từ chối của mình. Trang chủ cho bạn thấy cách tạo một app mobile được nghĩ cho khâu review ngay từ đầu.

Không ai có thể đảm bảo Apple sẽ chấp nhận app của bạn. Mình có thể giúp bạn cho nó một lý do để tồn tại trên App Store.

Câu hỏi thường gặp

"Guideline 4.2 - Design - Minimum Functionality" nghĩa là gì?

Đó là tiêu đề của lần từ chối vì tính năng tối thiểu. Apple cho rằng app của bạn quá giống một trang web, hoặc có quá ít nội dung hay tính năng. Cùng tiêu đề đó có thể nhắm tới một quy tắc con: "Guideline 4.2.2" cho app giới thiệu hay danh sách link, 4.2.3 cho app phụ thuộc vào app khác.

App dùng WebView có luôn bị từ chối không?

Không. Quy tắc nhắm vào trang web được đóng vào app, không phải công nghệ. Reviewer đánh giá trải nghiệm chính: nếu các màn hình của nó là trang web làm đúng những gì Safari làm, rủi ro sẽ cao. Một trang trợ giúp mở trong trình duyệt thì không phải vấn đề.

Thêm thông báo đẩy có đủ để qua 4.2 không?

Không. Trong một thông báo từ chối được đăng trên diễn đàn của mình, Apple viết rằng thông báo, định vị và chia sẻ không đủ để làm trải nghiệm đủ phong phú. Một thông báo có giá trị khi nó phục vụ tính năng chính, như báo thức hay lời nhắc do người dùng chọn.

Guideline 4.2 và 4.3 khác nhau thế nào?

4.2 đánh giá riêng app của bạn: nó có mang lại đủ so với một trang web không? 4.3 so sánh nó với các app khác: nó có phải bản sao, biến thể hay thêm một app nữa trong một danh mục đã bão hòa không? Một app có thể dính cả hai, nhưng cách sửa thì không giống nhau.

Có cần build mới sau khi bị từ chối 4.2 không?

Gần như luôn cần, vì nguyên nhân nằm trong chính app. Ngoại lệ duy nhất: reviewer không tìm thấy một tính năng đã có sẵn. Khi đó, hãy trả lời trong App Store Connect với ghi chú chính xác và một video ngắn, không cần đổi build.