App Store ปฏิเสธตามข้อ 2.1 App Completeness: แผนทดสอบ release build ก่อนส่งแอปใหม่ (2026)

การถูก App Store ปฏิเสธตามข้อ 2.1 App Completeness หมายความว่าผู้ตรวจไม่สามารถใช้แอปของคุณได้แบบที่ลูกค้าใช้ แอปอาจแครช แสดงเนื้อหาตัวอย่าง ติดอยู่ที่หน้าล็อกอิน หรือซ่อนการซื้อในแอปไว้ การแก้ไขแทบไม่เคยจบที่โค้ดบรรทัดเดียว ก่อนส่งใหม่ ให้รันแผนทดสอบสั้น ๆ บน release build ด้วยการติดตั้งใหม่ทั้งหมดและข้อมูลล็อกอินชุดเดียวกับที่ให้ App Review บทความนี้จะพาไล่ดูแผนนั้น และแสดงให้เห็นว่านักพัฒนาคนอื่นแก้การถูกปฏิเสธแบบเดียวกันอย่างไร

แนวทางข้อ 2.1 App Completeness ของ App Store ตรวจอะไรบ้าง?

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

App Review Guidelines ของ Apple แบ่งข้อ 2.1 เป็นสองส่วน 2.1(a) ระบุว่าการส่ง "ควรเป็นเวอร์ชันสุดท้ายที่มี metadata ที่จำเป็นครบถ้วนและ URL ที่ใช้งานได้เต็มที่" และต้องลบข้อความตัวอย่างกับเว็บไซต์ว่างเปล่าออก นอกจากนี้ยังให้ทดสอบบนอุปกรณ์จริงเพื่อหาบั๊กและตรวจความเสถียร และให้ "ใส่ข้อมูลบัญชีเดโม (และเปิดบริการแบ็กเอนด์ของคุณ!) หากแอปมีการล็อกอิน" Apple "จะปฏิเสธ app bundle ที่ไม่สมบูรณ์และไบนารีที่แครชหรือมีปัญหาทางเทคนิคที่เห็นได้ชัด" ส่วน 2.1(b) ระบุว่าการซื้อในแอปต้อง "สมบูรณ์ เป็นปัจจุบัน ผู้ตรวจมองเห็นได้ และใช้งานได้" หากหาการซื้อที่ตั้งค่าไว้ในแอปไม่เจอ ให้อธิบายเหตุผลไว้ใน review notes

การถูกปฏิเสธแบบนี้พบบ่อย หน้า Preparing for App Review ของ Apple ระบุว่า "โดยเฉลี่ย ปัญหาที่ยังไม่ได้รับการแก้ไขกว่า 40% เกี่ยวข้องกับแนวทางข้อ 2.1: App Completeness ซึ่งครอบคลุมการแครช เนื้อหาตัวอย่าง ข้อมูลที่ไม่ครบถ้วน และอื่น ๆ"

ทำไมการทดสอบ debug build ถึงจับปัญหาข้อ 2.1 ไม่ได้?

debug build ไม่ได้ทำงานแบบเดียวกับสำเนาที่ผู้ตรวจได้รับ ผู้ตรวจติดตั้ง release build ที่เซ็นแบบ distribution บนอุปกรณ์ที่สะอาด ไม่มีเซสชันที่บันทึกไว้ และไม่มีทางลัดสำหรับ debug

ซิมูเลเตอร์ของคุณล็อกอินไว้แล้ว API ในเครื่องอาจชี้ไปที่เซิร์ฟเวอร์ staging ที่ไม่เคยล่ม debug flag ข้าม paywall ไป และ feature flag เปิดไว้เป็นค่าเริ่มต้น ผู้ตรวจไม่ได้สิ่งเหล่านี้เลย หน้า review ของ Apple ยังขอให้คุณ "ทดสอบอย่างละเอียดบนอุปกรณ์ที่ใช้ซอฟต์แวร์เวอร์ชันล่าสุด" ดังนั้นผู้ตรวจอาจใช้ iOS ที่ใหม่กว่าโทรศัพท์ทดสอบของคุณ

TestFlight คือสภาพแวดล้อมที่ใกล้เคียงกับของผู้ตรวจที่สุด ตาม TestFlight overview คุณเพิ่มผู้ทดสอบภายในจากทีม App Store Connect ได้สูงสุด 100 คน และผู้ทดสอบภายนอกได้สูงสุด 10,000 คน ทดสอบบิลด์หนึ่งได้นานสูงสุด 90 วัน อัปโหลดบิลด์ตัวเดียวกับที่ตั้งใจจะส่ง ติดตั้งจาก TestFlight บนอุปกรณ์ที่ไม่เคยรันแอปนี้ แล้วทดสอบสำเนานั้น

แผนทดสอบ release build ก่อนส่งใหม่ควรครอบคลุมอะไรบ้าง?

แผนทดสอบ release build จะตรวจทุกจุดที่ผู้ตรวจซึ่งเริ่มจากศูนย์อาจติดค้าง ได้แก่ การเปิดแอป สิทธิ์การเข้าถึง การล็อกอิน แบ็กเอนด์ เนื้อหา ลิงก์ การซื้อ เครือข่ายล้มเหลว และ iPad รันขั้นตอนตามลำดับบนบิลด์ TestFlight และจดผลแต่ละข้อไว้ เพื่อนำไปอ้างอิงใน review notes

1. ติดตั้งใหม่บน iOS ล่าสุด ลบสำเนาเก่าออก ติดตั้งจาก TestFlight แล้วเปิดแอปโดยไม่มีสถานะที่บันทึกไว้ cold launch สามครั้งและยืนยันว่า onboarding ไม่แครช
2. ปฏิเสธทุกคำขอสิทธิ์หนึ่งครั้ง ปฏิเสธการแจ้งเตือน ตำแหน่งที่ตั้ง กล้อง และการติดตาม แอปควรยังไปถึงหน้าจอที่ใช้งานได้ และตรวจว่า Info.plist มี usage description สำหรับทรัพยากรที่ได้รับการป้องกันทุกตัวที่แอปหรือ SDK ใช้
3. ล็อกอินด้วยข้อมูลบัญชีเดโมชุดเดียวกันเป๊ะ คัดลอกจาก App Store Connect ไม่ใช่จากตัวจัดการรหัสผ่านของคุณ บัญชีควรมีข้อมูลสมจริง ไม่ต้องยืนยันอีเมล และไม่ใช้การยืนยันตัวตนสองขั้นตอนที่ผูกกับโทรศัพท์ของคุณ
4. ยืนยันว่าแบ็กเอนด์เป็น production และออนไลน์อยู่ บิลด์ต้องชี้ไปที่ endpoint ของ production การจำกัดอัตรา (rate limit) IP allowlist และการบล็อกตามภูมิภาคต้องไม่กันผู้ตรวจออก แนวทางข้อ 2.1(a) บอกให้คุณเปิดบริการแบ็กเอนด์ไว้
5. ไล่ดูทุกแท็บและทุกหน้าจอ มองหา lorem ipsum หน้าจอ "เร็ว ๆ นี้" หน้าว่างที่ไม่มีคำอธิบาย รูปภาพทดสอบ และปุ่มที่กดแล้วไม่เกิดอะไร
6. แตะทุกลิงก์ รวมถึงนโยบายความเป็นส่วนตัว การสนับสนุน ข้อกำหนด และ web view ทั้งหมด Apple ระบุว่า "ทุกแอปต้องมีลิงก์ไปยังฝ่ายสนับสนุนผู้ใช้พร้อมข้อมูลติดต่อที่เป็นปัจจุบัน และลิงก์ไปยังนโยบายความเป็นส่วนตัว"
7. เปิดการซื้อในแอปทุกรายการ ล็อกอินด้วยบัญชีใหม่ ตรวจว่าสินค้าทุกรายการที่ส่งพร้อมเวอร์ชันนี้แสดงพร้อมราคา ซื้อได้ใน sandbox และ Restore Purchases ทำงาน
8. ทดสอบบนเครือข่ายที่ช้าหรือขาดหาย เปิดโหมดเครื่องบินระหว่างใช้งานโฟลว์ ข้อความแจ้งข้อผิดพลาดที่ชัดเจนถือว่าใช้ได้ แต่ spinner ที่หมุนไม่หยุดหรือการแครชไม่ผ่าน
9. ตรวจบน iPad หากรองรับ ถ้าแอปรันบน iPad ได้ ให้เปิดบน iPad และตรวจว่าเลย์เอาต์ไม่ทำให้ผู้ใช้ติดค้าง

บัญชีเดโมในขั้นตอนที่ 3 เป็นสาเหตุของการถูกปฏิเสธซ้ำมากกว่าขั้นตอนอื่นใด คู่มือ การตั้งค่าบัญชีเดโมสำหรับ App Store review ของเราอธิบายวิธีสร้างบัญชีที่ใช้ได้ยาวนาน

จะจับคู่ข้อความปฏิเสธข้อ 2.1 กับวิธีแก้อย่างไร?

ในการจับคู่การถูกปฏิเสธข้อ 2.1 กับวิธีแก้ ให้อ่านประโยคที่ตามหลังหมายเลขแนวทาง ประโยคนั้นบอกอาการ และแต่ละอาการชี้ไปยังขั้นตอนหนึ่งในแผนทดสอบ

สมมติว่าแอปติดตามนิสัยแอปหนึ่งถูกปฏิเสธพร้อมข้อความ "We were unable to review the app because it crashed on launch" (เราไม่สามารถตรวจแอปได้เพราะแอปแครชตอนเปิด) และมีหมายเหตุที่สองว่าผู้ตรวจหาการซื้อในแอปไม่เจอ ตารางด้านล่างจับคู่อาการที่พบบ่อยกับสาเหตุ การทดสอบ และวิธีแก้

สำหรับวิธีอ่านข้อความปฏิเสธแบบครอบคลุมทุกข้อ ดู App Store ปฏิเสธแอป: วิธีแก้ทีละแนวทาง

การถูกปฏิเสธข้อ 2.1 ของนักพัฒนาคนอื่นเป็นอย่างไร?

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

• แครชเพราะขาด usage description ใน ฟอรัม Solar2D นักพัฒนาคนหนึ่งได้รับแจ้งว่า "We were unable to review the app because it crashed on launch" บน iPhone 13 mini ที่ใช้ iOS 18.3.2 แม้แอปจะรันใน TestFlight ได้ สมาชิกอีกคนพบข้อความนี้ใน crash log ที่แนบมา: "This app has crashed because it attempted to access privacy-sensitive data without a usage description." (แอปแครชเพราะพยายามเข้าถึงข้อมูลที่อ่อนไหวด้านความเป็นส่วนตัวโดยไม่มี usage description) นักพัฒนารายงานว่า "ผ่านหลังจากเพิ่ม NSUserTrackingUsageDescription"
• ล็อกอินโซเชียลที่ผู้ตรวจใช้ไม่ได้ นักพัฒนาคนหนึ่งใน Apple Developer Forums รายงานว่าถูกปฏิเสธตามข้อ 2.1 ซ้ำหลายครั้ง เพราะผู้ตรวจ "ไม่สามารถใช้การล็อกอินผ่านโซเชียลได้" เขาให้บัญชีเดโมของ Apple และ Google ไว้แล้ว แต่การล็อกอินด้วย Apple ID ต้องใช้รหัสยืนยันที่ส่งไปยังโทรศัพท์ของนักพัฒนา เจ้าหน้าที่ Apple ตอบว่า App Review จะติดต่อเขาโดยตรง และไม่มีการโพสต์วิธีแก้ต่อสาธารณะ
• การซื้อในแอป "could not be found in the submitted binary" ใน เธรดชุมชน RevenueCat นักพัฒนาคนหนึ่งถูกปฏิเสธเพราะหาแพ็กเกจรายเดือนไม่เจอในไบนารี แม้การซื้อใน sandbox จะใช้งานได้ ผู้ช่วยคนหนึ่งบอกว่าการถูกปฏิเสธที่คล้ายกันแก้ได้ด้วยการตอบกลับพร้อมคำอธิบายละเอียดและภาพหน้าจอของทุกเส้นทางไปยัง paywall เจ้าหน้าที่ RevenueCat แนะนำให้แสดงสินค้าทุกรายการที่ส่งไว้บน paywall เริ่มต้น และไม่ใส่ไฟล์ทดสอบ StoreKit ไว้ใน Archive scheme

ทั้งสามกรณี การทดสอบของนักพัฒนาเองผ่านหมด ความล้มเหลวปรากฏเฉพาะเมื่อเริ่มจากจุดเดียวกับผู้ตรวจ คือไม่มีโทรศัพท์รับรหัส 2FA ไม่มีเซสชันเดิม และไม่รู้ว่า paywall อยู่ตรงไหน จุดเริ่มต้นนี้คือสิ่งที่แผนทดสอบข้างต้นจำลองขึ้นมา

review notes หลังถูกปฏิเสธข้อ 2.1 ควรเขียนอะไร?

review notes หลังถูกปฏิเสธข้อ 2.1 ควรให้ข้อมูลบัญชีเดโมที่ใช้งานได้ ระบุสิ่งที่เปลี่ยนไปจากบิลด์ที่ถูกปฏิเสธ และบอกให้ชัดว่าจะหาการซื้อในแอปและฟีเจอร์ที่ไม่ชัดเจนได้ที่ไหน

หน้า review ของ Apple บอกให้ใส่รายละเอียดบัญชีและการตั้งค่าพิเศษไว้ในส่วน App Review Information หากฟีเจอร์ใดต้องใช้ฮาร์ดแวร์หรือสภาพแวดล้อมที่ตั้งค่ายาก ให้ "เตรียมพร้อมที่จะส่งวิดีโอสาธิตหรือฮาร์ดแวร์" แนวทางข้อ 2.3.1(a) ยังระบุว่าต้องอธิบายฟีเจอร์ใหม่ "อย่างเจาะจง" ใน Notes for Review และ "คำอธิบายแบบกว้าง ๆ จะถูกปฏิเสธ" notes สั้น ๆ ที่มีโครงสร้างชัดเจนใช้ได้ดี:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

หากข้อผูกพันทางกฎหมายหรือความปลอดภัยทำให้ให้บัญชีเดโมไม่ได้ แนวทางข้อ 2.1(a) อนุญาตให้ใช้โหมดเดโมในตัวแอปได้ แต่ต้อง ได้รับอนุมัติจาก Apple ล่วงหน้า เท่านั้น และโหมดนั้นต้องแสดงฟีเจอร์และการทำงานทั้งหมดของแอป อย่าเปลี่ยนไปใช้โหมดเดโมโดยไม่ได้รับอนุมัติ

จะส่งใหม่หรืออุทธรณ์การถูกปฏิเสธข้อ 2.1 อย่างไร?

ในการส่งใหม่หลังถูกปฏิเสธข้อ 2.1 ให้อัปโหลดหรือเลือกบิลด์ที่คุณทดสอบแล้ว ตอบกลับ App Review ใน App Store Connect ว่าเปลี่ยนอะไรไปบ้าง อัปเดต review notes แล้วส่งอีกครั้ง ให้อุทธรณ์เฉพาะเมื่อคุณเชื่อว่าผู้ตรวจเข้าใจแอปผิด

1. ตรวจว่าหมายเลขบิลด์ที่ผูกกับเวอร์ชันใน App Store Connect ตรงกับบิลด์ TestFlight ที่คุณทดสอบ
2. ตอบกลับข้อความปฏิเสธพร้อมสรุปสั้น ๆ ของการแก้ไขแต่ละข้อ สำหรับปัญหาการซื้อหรือการนำทาง ให้เพิ่มคำแนะนำทีละขั้นตอนและภาพหน้าจอ
3. อัปเดตส่วน App Review Information ด้วยข้อมูลล็อกอินและ notes ที่เป็นปัจจุบัน
4. ส่งเข้ารับการตรวจ ณ เดือนตุลาคม 2026 Apple ระบุว่าโดยทั่วไปจะตรวจ "การส่งอย่างน้อย 50% ภายในไม่ถึง 24 ชั่วโมง และ 90% ภายในไม่ถึง 48 ชั่วโมง"

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

ปัญหาข้อ 2.1 มักกลับมาในการอัปเดตครั้งถัดไป เช่น feature flag ใหม่ API key ที่ถูกหมุนเวียน หรือบัญชีเดโมที่หมดอายุ เพิ่มแผนทดสอบนี้เข้าไปในขั้นตอนการปล่อยเวอร์ชันของคุณควบคู่กับ เช็กลิสต์การส่งแอปขึ้น App Store สำหรับการอัปเดต phased release จะจำกัดจำนวนผู้ใช้ที่ได้รับผลกระทบจากบั๊กที่หลุดไป หากต้องการความเห็นที่สองเกี่ยวกับบิลด์ที่ถูกปฏิเสธ ส่งอีเมลพร้อมข้อความปฏิเสธมาที่ yagyeshsrbobde@gmail.com