แอปถูก App Store ปฏิเสธ: วิธีแก้ไขทีละข้อตาม Guidelines (2026)

การถูก App Store ปฏิเสธ คือข้อความจาก App Review ที่อ้างถึง guideline บอกสิ่งที่ผู้ตรวจพบ และระงับการเผยแพร่ไว้จนกว่าคุณจะแก้ไข ชี้แจง หรืออุทธรณ์ ขั้นแรกให้เปลี่ยนข้อความนั้นเป็นปัญหาที่ทดสอบได้ ขั้นต่อไปขึ้นอยู่กับว่าผู้ตรวจใช้งานแอปไม่ได้ พบความไม่สอดคล้องกับนโยบาย หรือต้องการข้อมูลเพิ่มเติม ณ เดือนตุลาคม 2026 App Review Guidelines อัปเดตล่าสุดเมื่อวันที่ 16 ตุลาคม 2026 จึงควรตรวจเลขข้อในหน้าเว็บจริงก่อนอ้างอิง

ข้อความปฏิเสธจาก App Store บอกอะไรคุณบ้าง?

ข้อความปฏิเสธจาก App Store จะระบุ guideline ที่ผู้ตรวจใช้ อธิบายพฤติกรรมเฉพาะที่พบ และบอกขั้นตอนถัดไป บ่อยครั้งจะมีรุ่นอุปกรณ์ เวอร์ชัน iOS และภาพหน้าจอแนบมาด้วย

บันทึกข้อความทั้งหมด ภาพหน้าจอ หมายเลข build และรายละเอียดอุปกรณ์ไว้ อ่านข้อที่ถูกอ้างถึงในหน้า guidelines ฉบับปัจจุบัน แล้วเขียนสรุปหนึ่งประโยค: "ผู้ตรวจทำ X ไม่สำเร็จเพราะ Y" ถ้าข้อความขอข้อมูลที่ขาดไปแทนที่จะรายงานข้อบกพร่อง ให้จดให้ชัดว่าขาดอะไร ข้อความมาตรฐานของ Apple สำหรับข้อ 2.1 ยังบอกวิธีจำลองปัญหาด้วย: "สำหรับแอปใหม่ ให้ถอนการติดตั้งแอปทุกเวอร์ชันก่อนหน้าออกจากอุปกรณ์ จากนั้นติดตั้งและทำตามขั้นตอนเพื่อจำลองปัญหา"

• ข้อความระบุถึงการแครช หน้าจอที่เข้าไม่ได้ หรือฟีเจอร์ที่ยังไม่สมบูรณ์หรือไม่? ให้จำลองขั้นตอนนั้นใน release build ที่ส่งไป บนประเภทอุปกรณ์ที่ Apple ระบุ
• ข้อความระบุถึงภาพหน้าจอ คำอธิบาย หรือ review notes หรือไม่? ตรวจดูว่าแก้ได้ด้วย metadata อย่างเดียวหรือไม่
• ข้อความระบุถึงการชำระเงิน การล็อกอิน ความเป็นส่วนตัว หรือฟังก์ชันขั้นต่ำหรือไม่? เปรียบเทียบพฤติกรรมของผลิตภัณฑ์กับ guideline ที่ถูกอ้างถึง

การปฏิเสธจาก App Store มักอ้างถึง guideline ข้อใด และแต่ละข้อกำหนดอะไร?

แต่ละ guideline กำหนดข้อบังคับที่เป็นรูปธรรม ดังนั้นให้จับคู่เลขข้อที่ถูกอ้างถึงกับถ้อยคำของข้อนั้น แล้วทดสอบตามถ้อยคำนั้น ตารางด้านล่างยกข้อความปัจจุบันของ guideline ที่ข้อความปฏิเสธมักอ้างถึง

การอัปเดตเมื่อวันที่ 16 ตุลาคม 2026 เพิ่มข้อ 2.5.19 สำหรับฟีเจอร์ที่ซ่อน ไม่ได้ใช้งาน หรือไม่มีเอกสารประกอบ ซึ่งเดิมอยู่ภายใต้ข้อ 2.3.1 นอกจากนี้ยังเพิ่มข้อ 2.3.14 เกี่ยวกับ creative assets และรวม Music Streaming Services entitlement เข้ากับ StoreKit External Purchase Link entitlement ภายใต้ข้อ 3.1.1(a) ให้ใช้ตารางนี้เป็นจุดเริ่มต้น ไม่ใช่วิธีแก้ที่รับประกันผล เพราะ guideline ข้อเดียวอาจครอบคลุมปัญหาหลายแบบ และตัวอย่างที่ผู้ตรวจให้มาคือกรณีจริงที่คุณต้องแก้ให้ได้

แก้การปฏิเสธข้อ 4.2 minimum functionality อย่างไร?

แก้การปฏิเสธข้อ 4.2 ด้วยการเพิ่มคุณค่าที่แท้จริงให้แอป ไม่ใช่การเขียนคำอธิบายใหม่ Guideline 4.2 ระบุว่า: "หากแอปของคุณไม่ได้มีประโยชน์ ไม่มีเอกลักษณ์ หรือไม่ 'เหมือนแอป' เป็นพิเศษ แอปนั้นก็ไม่ควรอยู่บน App Store"

ถามตัวเองว่าผู้ใช้ทำอะไรในแอปของคุณได้บ้างที่ทำให้มันมีประโยชน์ในฐานะแอป เช่น ทำ workflow ให้เสร็จ บันทึกสถานะที่มีความหมาย ใช้ความสามารถของอุปกรณ์อย่างเหมาะสมกับแอป หรือได้รับประสบการณ์บนมือถือที่สร้างมาเพื่ออุปกรณ์นั้น ไม่มีรายการฟีเจอร์ใดที่เผยแพร่ไว้แล้วรับประกันการอนุมัติ หากมี workflow เหล่านั้นอยู่แล้ว ให้ระบุใน review notes พร้อมขั้นตอนที่ชัดเจนและภาพหน้าจอ หากแอปส่วนใหญ่แค่แสดงหน้าเว็บ ก็ต้องพัฒนาตัวผลิตภัณฑ์เพิ่ม การเพิ่มการแจ้งเตือนหรือหน้าตั้งค่าเปล่า ๆ เพียงเพื่อให้ดูเป็น native ไม่ได้ทดแทนคุณค่าที่แท้จริงต่อผู้ใช้

ตอบกลับ App Review ใน App Store Connect อย่างไร?

ตอบกลับใน App Store Connect: เปิด submission จากลิงก์ unresolved issues ของแอป คลิก Resolve แล้วคลิก Reply to App Review ตามหน้าช่วยเหลือของ Apple ต้องมีบทบาท Account Holder, Admin หรือ App Manager

1. ใน Apps ให้เลือกแอป
2. ที่ด้านบนของหน้า คลิกลิงก์ที่แจ้งว่ามีปัญหาที่ยังไม่ได้รับการแก้ไข (unresolved issues)
3. ในส่วน In Progress คลิก Resolve ข้าง submission
4. คลิก Reply to App Review แล้วพิมพ์ข้อความ
5. หากต้องการแนบภาพหน้าจอหรือเอกสาร คลิก Attach File แล้วคลิก Reply

Apple ระบุว่าคุณติดต่อและแนบไฟล์ได้ "จนกว่าคุณจะส่งให้ App Review อีกครั้ง" ดังนั้นให้ส่งหลักฐานก่อนส่งรีวิวใหม่ เขียนตอบให้สั้นและตรงตามข้อเท็จจริง: บอกว่าเปลี่ยนอะไร อยู่ตรงไหน และตรวจสอบได้อย่างไร อย่าโต้แย้งโดยยกแอปอื่นที่ดูเหมือนทำแบบเดียวกัน

ควรแก้ metadata อัปโหลด build ใหม่ หรือยื่นอุทธรณ์?

แก้ metadata แล้วส่ง build เดิมอีกครั้งเมื่อผิดแค่ข้อมูลในหน้า listing อัปโหลด build ใหม่เมื่อต้องเปลี่ยนพฤติกรรมของแอป ยื่นอุทธรณ์เฉพาะเมื่อคุณเชื่อว่าแอปปฏิบัติตาม guideline อยู่แล้ว

แนวทางการอุทธรณ์ของ Apple ขอให้คุณ "อธิบายทีละประเด็นว่าแอปของคุณเป็นไปตาม" guideline อย่างไร และยังระบุว่าไม่ควรอุทธรณ์หลังจากแก้ปัญหาและส่งใหม่ไปแล้ว คำอุทธรณ์ที่ครบถ้วน "ไม่ได้รับประกัน" ว่าการตัดสินจะถูกกลับ สำหรับแอปที่อยู่บน store แล้ว นโยบาย Bug Fix Submissions ใน guidelines ระบุว่าการแก้บั๊กจะไม่ถูกชะลอเพราะการละเมิด guideline "ยกเว้นกรณีที่เกี่ยวข้องกับประเด็นทางกฎหมายหรือความปลอดภัย"

นักพัฒนาคนอื่นแก้การปฏิเสธจาก App Store ในกรณีจริงอย่างไร?

ในกระทู้ฟอรัมสาธารณะ การปฏิเสธข้อ 2.1 จำนวนมากเกิดจากความแตกต่างระหว่างสภาพแวดล้อมของผู้ตรวจกับของนักพัฒนา เช่น เครือข่าย อุปกรณ์ หรือสถานะสิทธิ์การเข้าถึงที่ต่างกัน ส่วนการปฏิเสธข้อ 4.2 เป็นปัญหาระดับผลิตภัณฑ์ การปรับเล็กน้อยจึงแทบไม่เคยผ่าน

ข้อผิดพลาดตอนล็อกอินภายใต้ข้อ 2.1 นักพัฒนาคนหนึ่งใน Apple Developer Forums ยกข้อความ "โดยเฉพาะ เราไม่สามารถล็อกอินได้เนื่องจากข้อผิดพลาด" ทั้งที่เวอร์ชันจริงและเวอร์ชัน TestFlight ล็อกอินด้วยข้อมูลเดียวกันได้ นักพัฒนาคนอื่นในกระทู้รายงานวิธีแก้ต่างกันไป คนหนึ่งแก้ได้ด้วยการ "เปลี่ยน http เป็น https บนเว็บเซิร์ฟเวอร์" อีกคนหลังถูกปฏิเสธสามครั้ง ได้เพิ่มสถานะ "ตรวจสอบการเชื่อมต่อของคุณ" แทนตัวโหลดที่หมุนไม่รู้จบ คนที่สามนำ iPad ออกจาก deployment target หลังถูกปฏิเสธห้าครั้ง ซึ่งเป็นการเลี่ยงปัญหาด้วยการเลิกรองรับ iPad

แครชตอนเปิดแอป ใน ฟอรัม Solar2D นักพัฒนาคนหนึ่งได้รับแจ้งว่า "เราไม่สามารถรีวิวแอปได้เพราะแอปแครชตอนเปิด" บน iPhone 13 mini ที่ใช้ iOS 18.3.2 crash log ที่แนบมาแสดงว่าขาดคีย์ NSUserTrackingUsageDescription นักพัฒนายืนยันว่า: "ผ่านแล้วหลังเพิ่ม: NSUserTrackingUsageDescription"

แอป WebView ภายใต้ข้อ 4.2 นักพัฒนาคนหนึ่งใน Apple Developer Forums รายงานว่าแอปที่สร้างบน WebView ถูกปฏิเสธเป็นครั้งที่ 10 ผู้ตรวจส่งภาพหน้าจอเมนูด้านซ้ายมาพร้อมระบุว่าขาดเนื้อหา หน้าจอหลักเป็น native แล้ว แต่ยังมีสองถึงสามหน้าที่เปิด WebView คำตอบที่ถูกทำเครื่องหมายว่าเป็นคำตอบมาจาก App Review และแนะนำให้ขอคำปรึกษาแบบตัวต่อตัวกับ App Review กระทู้ไม่ได้ยืนยันว่าแอปได้รับการอนุมัติ

เปรียบเทียบกัน: กรณีข้อ 2.1 แก้ได้ด้วยการจำลองเงื่อนไขของผู้ตรวจและอ่าน crash log ส่วนกรณีข้อ 4.2 ติดค้างเพราะการส่งใหม่แต่ละครั้งเปลี่ยนเพียงบางส่วนของแอปที่ยังเป็นเว็บไซต์เป็นหลัก

ป้องกันไม่ให้ถูกปฏิเสธซ้ำด้วยเหตุผลเดิมได้อย่างไร?

เปลี่ยนทุกปัญหาที่แก้แล้วให้เป็นรายการใน release checklist และทดสอบซ้ำใน release build ก่อนส่งทุกครั้ง Guidelines ของ Apple เตือนว่าการรีวิว "จะใช้เวลานานขึ้น" หากแอปถูกปฏิเสธซ้ำด้วยการละเมิด guideline ข้อเดิม

• ลบแอปออก แล้วติดตั้ง release build ใหม่บน iPhone และ iPad เครื่องจริง
• ล็อกอินด้วยบัญชีสำหรับรีวิวบนเครือข่ายที่ไม่มีเซิร์ฟเวอร์สำหรับพัฒนาหรือข้อยกเว้น HTTP
• เปิดหน้าขอสิทธิ์ทุกหน้าและยืนยันว่ามี usage description ใน Info.plist ครบทุกรายการ
• ตรวจให้แน่ใจว่า in-app purchase ทุกรายการถูกส่งแล้ว มองเห็นได้ และอธิบายไว้ใน review notes
• อัปเดต review notes ทุกครั้งที่ขั้นตอนเปลี่ยน อย่าคัดลอก notes จากเมื่อหกรีลีสก่อนมาวาง

สำหรับปัญหาข้อ 2.1 ให้ทำตามแผนทดสอบ release build สำหรับการปฏิเสธข้อ 2.1 และตั้งค่าบัญชีเดโมสำหรับผู้ตรวจ จากนั้นไล่ตามเช็กลิสต์การส่งแอป สำหรับ build ถัดไป หากข้อความรีวิวยังทำให้คุณติดอยู่ ส่งรายละเอียดมาให้เรา แล้วเราจะช่วยหาว่าสิ่งที่ขาดไปคือการเข้าถึง metadata หรือโค้ด