Guideline 4.2 Minimum Functionality: แอปถูกปฏิเสธ แก้ยังไง
โดย Mehdi Azizi
เผยแพร่เมื่อ , 9 นาที
Guideline 4.2: Apple ปฏิเสธแอปที่ให้อะไรไม่มากกว่าเว็บไซต์ ใส่ฟีเจอร์ native ไว้ที่หัวใจของการใช้งาน แล้วบอก reviewer ว่าอยู่ตรงไหน
Guideline 4.2 “Minimum Functionality” ใช้ปฏิเสธแอปที่ให้อะไรไม่มากกว่าเว็บไซต์ หรือมีของน้อยเกินกว่าที่ใครจะเก็บไว้ใช้ วิธีแก้ไม่ใช่การยัดฟีเจอร์ native เพิ่มเข้าไปเรื่อย ๆ แต่คือการวางฟีเจอร์ native สักตัวไว้ที่หัวใจของการใช้งาน แล้วบอก reviewer ว่าจะเจอมันได้ที่ไหน และการแก้แทบทุกครั้งต้องส่ง build ใหม่
ผมเผยแพร่แอป iOS ของตัวเอง: Solys, TradaZen และ Nolera อยู่บน App Store แล้ว คู่มือนี้อ้างอิงข้อความทางการของ Apple ที่ผมอ่านเมื่อวันที่ 15 ตุลาคม 2026 และกรณีถูกปฏิเสธด้วย 4.2 ที่นักพัฒนาโพสต์ไว้ในฟอรัมของ Apple แอปที่ถูกปฏิเสธซึ่งยกมาด้านล่างเป็นตัวอย่าง ถ้าอยากเห็นภาพรวมของเหตุผลการปฏิเสธทั้งหมด อ่านทำไม Apple ถึงปฏิเสธแอป ก่อนดีกว่าครับ
Guideline 4.2 พูดว่าอะไร?
4.2 อยู่ในหมวด 4 “Design” ของ App Review Guidelines ประโยคแรกตั้งเกณฑ์ไว้ว่า “Your app should include features, content, and UI that elevate it beyond a repackaged website.” พูดง่าย ๆ คือแอปของคุณต้องมีฟีเจอร์ คอนเทนต์ และหน้าตาที่ยกระดับมันให้เหนือกว่าเว็บไซต์ที่ถูกจับใส่กล่องใหม่
ข้อความยังเพิ่มอีกสองแนวคิด แอปที่ไม่ได้มีประโยชน์จริง ไม่มีเอกลักษณ์ หรือไม่ “app-like” ไม่ควรอยู่บน App Store และแอปที่ไม่ได้ให้ความบันเทิงระยะยาวหรือประโยชน์ที่เพียงพอ อาจถูกปฏิเสธได้ ดังนั้น 4.2 ตัดสินสองเรื่อง: ความต่างจากเว็บ และปริมาณคุณค่า
ข้อย่อยที่ข้อความปฏิเสธอาจอ้างถึง
| ข้อย่อย | สิ่งที่ Apple ต้องการ | กรณีถูกปฏิเสธที่พบบ่อย |
|---|---|---|
| 4.2 | ต้องไปไกลกว่าเว็บไซต์ | เว็บไซต์ที่แสดงใน WebView |
| 4.2.1 | ประสบการณ์ AR ที่เป็นของจริง | โมเดล 3D วางไว้ในมุมมอง AR เฉย ๆ |
| 4.2.2 | ไม่ใช่แค่การตลาดหรือรวมลิงก์ | แอปโชว์รูม, แอปรวบรวมคอนเทนต์, ลิงก์ |
| 4.2.3 | แอปที่ทำงานได้ด้วยตัวเอง ดาวน์โหลดชัดเจน | แอปที่ต้องมีแอปอื่นก่อน |
| 4.2.6 | ไม่ใช่แอปที่สร้างจากเทมเพลตเชิงพาณิชย์ | เทมเพลตที่ผู้รับจ้างส่งมา |
มีสามข้อที่ควรรู้ 4.2.2 ยกเว้นให้แคตตาล็อก: “Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” แคตตาล็อกสินค้าจึงผ่านได้ แต่แผ่นพับโฆษณาไม่ผ่าน
4.2.3 มีสองวรรค วรรค (i) กำหนดให้แอปทำงานได้ด้วยตัวเอง โดยไม่ต้องติดตั้งแอปอื่น วรรค (ii) กำหนดว่าถ้าแอปต้องดาวน์โหลดทรัพยากรตอนเปิดครั้งแรก ต้องแจ้งขนาดไฟล์และขอความยินยอมก่อน
4.2.6 เรื่องเทมเพลตเชิงพาณิชย์และบริการสร้างแอป อธิบายละเอียดไว้ในคู่มือ guideline 4.3 เพราะมันมาคู่กับกฎต่อต้านสแปม
ข้อความ 4.2 สองแบบที่เจอบ่อยที่สุด
ข้อความของ Apple จะขึ้นต้นด้วยหัวข้อ “Guideline 4.2 - Design - Minimum Functionality” ส่วนที่ตามมาจะบอกว่า reviewer เห็นปัญหาแบบไหนในสองแบบ นี่คือถ้อยคำสองแบบที่นักพัฒนาโพสต์ไว้ในฟอรัมของ Apple ซึ่งเก่ามาหลายปีแล้ว ถ้อยคำเป๊ะ ๆ อาจเปลี่ยนไป แต่สองกลุ่มปัญหานี้ไม่เปลี่ยน
แอปดูเหมือนเว็บไซต์ “Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.” ข้อความนี้ซึ่งโพสต์ไว้ในฟอรัมของ Apple มีประโยคชี้ขาดอยู่ประโยคหนึ่ง: “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.”
แอปบางเกินไป “We found that the usefulness of your app is limited by the minimal amount of content or features it includes.” ข้อความที่สอง นี้ขอให้ทบทวนคอนเซปต์ และยอมรับว่าไม่มีกฎที่เป็นตัวเลขกำหนดว่าอะไรมีประโยชน์หรือให้ความบันเทิง
การเพิ่มการแจ้งเตือน ตำแหน่งที่ตั้ง และปุ่มแชร์ให้เว็บไซต์ที่ถูกห่อไว้ไม่พอ: Apple เขียนไว้เองในข้อความปฏิเสธของตัวเอง
สี่กรณีที่ถูกปฏิเสธด้วย 4.2 บ่อย ๆ
สี่กรณีด้านล่างเป็นตัวอย่างที่สร้างขึ้นเพื่ออธิบายกฎ ไม่ใช่แอปจริง
เว็บไซต์ที่ถูกห่อเป็นแอป
ตัวอย่าง: ฟิตเนสแห่งหนึ่งแสดงเว็บมือถือของตัวเองใน WebView โดยมีแถบแท็บ native วางทับ ตารางคลาส การจอง และบัญชีผู้ใช้ล้วนเป็นหน้าเว็บ reviewer เห็นสิ่งเดียวกับที่ Safari แสดงให้ดู Apple บอกไว้ในหน้า App Review ว่าเว็บไซต์ที่เสิร์ฟผ่านแอป iOS คอนเทนต์เว็บที่ไม่ได้ปรับให้เข้ากับ iOS หรือการโต้ตอบแบบเว็บที่จำกัด ไม่ได้ทำให้เป็นแอปที่มีคุณภาพ
สิ่งที่ผมจะทำ: สร้างหน้าจอของการใช้งานหลักใหม่แบบ native ในกรณีนี้คือตารางคลาสและการจอง แล้วเพิ่มสิ่งที่เว็บทำไม่ได้: การเตือนก่อนเข้าคลาส ตารางที่ดูได้แม้ไม่มีเน็ต และคลาสถัดไปแสดงใน widget
แอปที่เรียบง่ายเกินไป
ตัวอย่าง: แอปที่แสดงคำคมวันละหนึ่งประโยค แค่นั้นเลย ใช้สิบวินาทีก็ดูครบแล้ว 4.2 พูดถึง “lasting entertainment value or adequate utility” คือคุณค่าที่อยู่ได้นาน หรือประโยชน์ที่เพียงพอ วิธีแก้คือเพิ่มความลึกให้การใช้งานหลัก ไม่ใช่เพิ่มหน้าจอรอบ ๆ ในกรณีนี้: ประวัติย้อนหลัง รายการโปรด การเตือนตามเวลาที่เลือก และ widget บนหน้าจอโฮม
แอปที่สร้างด้วย AI โดยไม่มีอะไร native เลย
ตัวอย่าง: ช่องพิมพ์ข้อความ ปุ่มหนึ่งปุ่ม และคำตอบจาก AI ที่แสดงเป็นข้อความเปล่า ๆ Apple ไม่ได้ตัดสินเครื่องมือ แต่ตัดสินสิ่งที่ไปโผล่บนจอของ reviewer ถ้าประสบการณ์ทั้งหมดใส่ในหน้าเว็บหน้าเดียวได้ ก็มีโอกาสสูงที่จะโดน 4.2
ผมอธิบายละเอียดว่า AI ทำอะไรได้ดีและพลาดตรงไหนในสร้างแอปด้วย AI ส่วนรูปแบบที่เครื่องมือสร้างแอปแต่ละตัวผลิตออกมา ไม่ว่าจะเป็นเว็บแอปหรือโปรเจกต์มือถือ ผมเปรียบเทียบไว้ในLovable, Rork หรือ FlutterFlow
เปลือกที่รอคอนเทนต์
ตัวอย่าง: ตลาดซื้อขายที่ไม่มีประกาศ ไดเรกทอรีว่างเปล่า ฟีดที่ขึ้นว่า “เร็ว ๆ นี้” reviewer เปิดแอปที่ไม่มีอะไรให้ดู กรณีนี้ยังเกี่ยวกับ 2.1 ที่ปฏิเสธคอนเทนต์ชั่วคราวด้วย ดูคู่มือ guideline 2.1 ส่งแอปตอนที่มีคอนเทนต์จริงแล้ว หรือให้บัญชีเดโมที่มีข้อมูลอยู่แล้ว
เทสต์ที่ผมใช้: “แล้วใน Safari ล่ะ?”
ก่อนส่ง ผมถามตัวเองว่าเว็บไซต์ให้ฟีเจอร์หลักแบบเดียวกันได้ไหม ถ้าได้ แอปก็เสี่ยงโดน 4.2 นี่คือเกณฑ์ที่ผมใช้ตัดสินฟีเจอร์ native ฟีเจอร์จะมีน้ำหนักก็ต่อเมื่อมันรับใช้การใช้งานหลัก ไม่ใช่แค่ประดับ
| ฟีเจอร์ | มีน้ำหนักเมื่อ... | ไม่พอเมื่อ... |
|---|---|---|
| การแจ้งเตือน | ให้ข้อมูลที่ผู้ใช้รอคอย | แค่ส่งต่อบทความของคุณ |
| ออฟไลน์ | คอนเทนต์หลักยังใช้งานได้ | มีแค่หน้าจอ error แสดงขึ้นมา |
| Widget | แสดงข้อมูลเฉพาะของผู้ใช้คนนั้น | แสดงแค่โลโก้ของคุณ |
| การแชร์ | ส่งคอนเทนต์เข้ามาในแอปของคุณได้ | แชร์ได้แค่ลิงก์ |
| กล้อง, เซนเซอร์ | เป็นส่วนหนึ่งของการใช้งานหลัก | แค่เปิดเว็บไซต์ของคุณ |
| ข้อมูลในเครื่อง | แอปคำนวณ จัดเก็บ และจดจำได้ | ทุกอย่างอยู่บนหน้าเว็บ |
คำแนะนำของ Apple ก็ไปในทางเดียวกัน widget แสดงคอนเทนต์ที่เป็นปัจจุบัน อ่านได้ในแวบเดียว การแจ้งเตือน ให้ข้อมูลที่มีประโยชน์ด้วยคำไม่กี่คำ และไม่ได้มีไว้ผลักให้คนไปทำงานบางอย่างในแอป
สิ่งที่แอปของผมทำได้แต่เว็บทำไม่ได้
ผมออกแบบแต่ละแอปโดยมีฟีเจอร์หลักที่ไม่มีในเบราว์เซอร์ หรือมีคุณค่าที่ทำให้คนกลับมาใช้
- Solys เป็นแอปนาฬิกาปลุก เสียงปลุกทำงานผ่าน AlarmKit ซึ่งเป็นบริการนาฬิกาปลุกของ iOS 26 จึงดังทะลุโหมดเงียบได้เหมือนนาฬิกาปลุกของ Apple จะปิดได้ต้องชนะมินิเกม และแอปที่เลือกไว้จะถูกพักไว้หลังตื่น ไม่มีหน้าเว็บไหนทำให้ iPhone ที่อยู่ในโหมดเงียบส่งเสียงได้
- TradaZen เป็นเกมจำลองการเทรด: กราฟจริงในวันที่จริง การตัดสินใจ แท่งเทียนที่ค่อย ๆ เผยออกมา การดวลแบบจัดอันดับ และแรงก์ที่ไต่ขึ้นไป ที่นี่ไม่ใช่ฟีเจอร์ native ที่แบกแอปไว้ แต่เป็นคุณค่าความบันเทิงระยะยาวที่ 4.2 พูดถึง
- Nolera เป็นแอปตู้เสื้อผ้า: คุณถ่ายรูปเสื้อผ้า แอปจะตัดพื้นหลังและจัดเก็บให้ แล้วแนะนำชุดให้ทุกเช้า กล้องเป็นส่วนหนึ่งของการใช้งานหลัก ไม่ใช่ของแถม
4.2 ไม่ได้ต้องการรายการฟีเจอร์ native แต่ต้องการเหตุผลที่คนจะติดตั้งแอปแทนการเปิดเว็บไซต์
แก้การปฏิเสธ 4.2 ทีละขั้น
- ระบุว่าเป็นปัญหากลุ่มไหน ถ้าพูดถึงการท่องเว็บ คือเว็บไซต์ที่ถูกห่อ ถ้าพูดถึงคอนเทนต์หรือฟีเจอร์น้อย คือแอปที่บางเกินไป ถ้าเป็น 4.2.3 คือพึ่งพาแอปอื่นหรือดาวน์โหลดโดยไม่แจ้ง
- เปลี่ยนตัวผลิตภัณฑ์ ไม่ใช่เปลี่ยนคำพูด คำตอบที่โต้แย้งโดยไม่เปลี่ยนอะไรเลยไม่มีเหตุผลอะไรที่จะโน้มน้าวได้ สร้างหน้าจอของการใช้งานหลักใหม่แบบ native หรือเพิ่มความลึกที่ขาดไป
- เตรียมส่ง build ใหม่ ต้นเหตุอยู่ในแอป อัปเดตจากระยะไกลจึงไม่พอ การส่งแต่ละครั้งต้องเข้าคิวใหม่ ดูระยะเวลารีวิวของ App Store
- เขียน review notes ที่นำทาง Apple ขอไว้ในหน้าข้อมูลสำหรับการรีวิวที่ครบถ้วน ให้อธิบายคอนเซปต์ ฟีเจอร์ และกลุ่มผู้ใช้ ถ้าเป็นการอัปเดต ให้บอกว่าอะไรเปลี่ยน และจะเจอได้ที่ไหน
- ยื่นอุทธรณ์เฉพาะเมื่อ reviewer มองข้ามบางอย่างไป ถ้าฟีเจอร์ native ของคุณมีอยู่แล้วแต่ไม่ถูกเห็น ให้ตอบใน App Store Connect พร้อมวิดีโอสั้น ๆ การอุทธรณ์ต่อ App Review Board สมเหตุสมผลเมื่อแอปของคุณถูกเข้าใจผิด ไม่ใช่เมื่อแอปบางเกินไป
เทมเพลต notes ที่ผมจะใช้ เป็นภาษาอังกฤษ ปรับตามแอปของคุณได้:
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]
เขียนเฉพาะสิ่งที่มีอยู่จริงใน build ที่ส่งไป ฟีเจอร์ที่ประกาศไว้แต่หาไม่เจอจะทำให้คุณโดนปฏิเสธอีกรอบ คราวนี้ด้วยเหตุผล 2.1
เช็กลิสต์ 4.2 ก่อนส่งรีวิว
- คุณอธิบายได้ในประโยคเดียวว่าแอปของคุณทำอะไรที่เว็บไซต์ทำไม่ได้
- หน้าจอของการใช้งานหลักเป็น native ไม่ใช่หน้าเว็บ
- ฟีเจอร์ native ทุกตัวรับใช้การใช้งานหลัก และ reviewer เจอมันภายในไม่ถึงสองนาที
- แอปมีคอนเทนต์จริงตั้งแต่เปิดครั้งแรก หรือมีบัญชีเดโมที่มีข้อมูลแล้ว
- แอปทำงานได้ด้วยตัวเอง ไม่ต้องติดตั้งแอปอื่น
- การดาวน์โหลดไฟล์ใหญ่ตอนเปิดครั้งแรกแจ้งขนาดและขอความยินยอม
- review notes อธิบายคอนเซปต์ กลุ่มผู้ใช้ และตำแหน่งของแต่ละฟีเจอร์
- ถ้าไอเดียของคุณเฉียดเส้น คุณได้ทดสอบมันก่อนเขียนโค้ดแล้ว ด้วยMVP แอป iOS ที่วางขอบเขตไว้ดี
ผ่าน 4.2 ตั้งแต่การส่งรีวิวครั้งหน้า
ถ้าแอปของคุณเพิ่งโดนปฏิเสธด้วย 4.2 Apple Review Kit ช่วยให้คุณหากฎที่ถูกอ้างถึงและสิ่งที่กฎนั้นต้องการ พร้อมเทมเพลต notes สำหรับผู้ทดสอบ ถ้าคุณยังสร้างแอปอยู่ เส้นทางของ iOS Kit เริ่มจากฟีเจอร์หลักก่อนเขียนโค้ดบรรทัดแรก ถ้าอยากได้คนช่วยดู จองเวลากับผมหนึ่งชั่วโมง ขั้นตอนทั้งหมดอยู่ในหน้าแอปถูก Apple ปฏิเสธ
ถ้าคุณกำลังเตรียมปล่อยแอปแรก ทำแบบประเมินฟรี มันจะเรียงขั้นตอนให้ถูกลำดับ และส่งเช็กลิสต์กันโดน Apple ปฏิเสธของผมให้คุณ หน้าแรกแสดงวิธีสร้างแอปมือถือ ที่คิดเรื่องการรีวิวไว้ตั้งแต่ต้น
ไม่มีใครรับประกันได้ว่า Apple จะอนุมัติแอปของคุณ แต่ผมช่วยให้แอปของคุณมีเหตุผลที่จะอยู่บน App Store ได้
คำถามที่พบบ่อย
“Guideline 4.2 - Design - Minimum Functionality” หมายความว่าอะไร?
คือหัวข้อของการปฏิเสธเพราะฟังก์ชันขั้นต่ำไม่พอ Apple มองว่าแอปของคุณเหมือนเว็บไซต์เกินไป หรือมีคอนเทนต์หรือฟีเจอร์น้อยเกินไป หัวข้อเดียวกันนี้อาจระบุข้อย่อยด้วย: “Guideline 4.2.2” สำหรับแอปโชว์รูมหรือแอปรวมลิงก์ และ 4.2.3 สำหรับแอปที่พึ่งพาแอปอื่น
แอปที่ใช้ WebView จะถูกปฏิเสธเสมอไหม?
ไม่ กฎนี้เล็งไปที่เว็บไซต์ที่ถูกจับใส่แอป ไม่ใช่เทคโนโลยี reviewer ตัดสินที่ประสบการณ์หลัก ถ้าหน้าจอหลักเป็นหน้าเว็บที่ทำสิ่งเดียวกับ Safari ความเสี่ยงก็สูง ส่วนหน้าช่วยเหลือที่เปิดในเบราว์เซอร์ไม่ใช่ประเด็น
เพิ่ม push notification อย่างเดียวพอให้ผ่าน 4.2 ไหม?
ไม่พอ ในข้อความปฏิเสธที่โพสต์ไว้ในฟอรัมของ Apple เอง Apple เขียนว่าการแจ้งเตือน ตำแหน่งที่ตั้ง และการแชร์ ไม่พอที่จะทำให้ประสบการณ์สมบูรณ์เพียงพอ การแจ้งเตือนจะมีน้ำหนักเมื่อมันรับใช้ฟีเจอร์หลัก เช่น นาฬิกาปลุก หรือการเตือนที่ผู้ใช้เลือกเอง
Guideline 4.2 กับ 4.3 ต่างกันอย่างไร?
4.2 ตัดสินแอปของคุณแบบเดี่ยว ๆ: มันให้อะไรมากพอเมื่อเทียบกับเว็บไซต์ไหม? 4.3 เปรียบเทียบกับแอปอื่น: มันเป็นของก๊อป เป็นเวอร์ชันย่อย หรือเป็นแค่อีกแอปในหมวดที่ล้นตลาดหรือเปล่า? แอปเดียวอาจโดนทั้งสองข้อได้ แต่วิธีแก้ไม่เหมือนกัน
ต้องส่ง build ใหม่หลังโดนปฏิเสธด้วย 4.2 ไหม?
แทบทุกครั้ง เพราะต้นเหตุอยู่ที่ตัวแอปเอง ข้อยกเว้นเดียวคือ reviewer หาฟีเจอร์ที่มีอยู่แล้วไม่เจอ กรณีนั้นให้ตอบใน App Store Connect พร้อม notes ที่ชัดเจนและวิดีโอสั้น ๆ โดยไม่ต้องเปลี่ยน build