App Review Guidelines ตุลาคม 2026 เปลี่ยนอะไร: ข้อ 1.2, 2.3.14, 2.5.19 และ 3.1.1(a) มีผลต่อแอปคุณอย่างไร

การเปลี่ยนแปลง App Review Guidelines เดือนตุลาคม 2026 ประกาศผ่านโพสต์ Updated App Review Guidelines are now available ของ Apple เมื่อวันที่ 16 ตุลาคม 2026 มีแนวทางใหม่สองข้อ (2.3.14 และ 2.5.19) มีการปรับถ้อยคำสามส่วน (1.2, 3.1.1(a) และหมวด 5) และส่วน Before You Submit กับ After You Submit ได้ลิงก์ไปยังเอกสารเพิ่มเติม ด้านล่างนี้คือการเปลี่ยนแปลงแต่ละข้อแบบเข้าใจง่าย ใครต้องดำเนินการ และเช็กลิสต์สำหรับการส่งรีวิวครั้งถัดไปของคุณ

App Review Guidelines เปลี่ยนอะไรบ้างเมื่อวันที่ 16 ตุลาคม 2026?

Apple เพิ่มแนวทางข้อ 2.3.14 สำหรับ creative assets และข้อ 2.5.19 สำหรับฟีเจอร์ที่ซ่อนอยู่ รวมถึงทำให้ข้อ 1.2 (เนื้อหาที่ผู้ใช้สร้าง) ข้อ 3.1.1(a) (ลิงก์ซื้อภายนอก) และหมวด 5 (กฎหมาย) ชัดเจนขึ้น บันทึกการเปลี่ยนแปลงของ Apple สรุปการแก้ไขไว้ดังนี้:

Apple ระบุว่าฉบับแปล "จะพร้อมใช้งานบนเว็บไซต์ Apple Developer ภายในหนึ่งเดือน" ณ เดือนตุลาคม 2026 หากฉบับแปลไม่ตรงกับต้นฉบับ ให้ยึด App Review Guidelines ฉบับภาษาอังกฤษเป็นหลัก

แนวทางข้อ 2.5.19 ใหม่เรื่องฟีเจอร์ที่ซ่อนอยู่กำหนดอะไรบ้าง?

แนวทางข้อ 2.5.19 กำหนดให้ทุกฟีเจอร์ในไบนารีของคุณต้องมองเห็นได้และมีคำอธิบายทั้งต่อผู้ใช้และทีม App Review การซ่อนฟังก์ชันการทำงาน รวมถึงการซ่อนด้วย obfuscation อาจทำให้แอปถูกถอดออกและบัญชีนักพัฒนาถูกยกเลิก

ข้อความฉบับเต็มระบุว่า: "อย่าใส่ฟีเจอร์ที่ซ่อนอยู่ ยังไม่เปิดใช้งาน หรือไม่มีเอกสารอธิบายไว้ในแอปของคุณ ฟังก์ชันการทำงานของแอปควรชัดเจนต่อผู้ใช้ปลายทางและ App Review ความพยายามซ่อนฟีเจอร์ที่ไม่มีเอกสารอธิบายไว้ในไบนารีของแอป เช่น ผ่านการ obfuscate โค้ดหรือวิธีอื่นๆ ถือเป็นเหตุให้ถอดแอปของคุณออกจาก App Store และยกเลิกบัญชีนักพัฒนาของคุณ" Apple อธิบายว่านโยบายนี้มีมานานแล้ว แต่เดิมอยู่ในข้อ 2.3.1 ส่วนข้อ 2.3.1(a) ปัจจุบันยังกำหนดให้ฟีเจอร์ใหม่ต้อง "อธิบายอย่างเจาะจงในส่วน Notes for Review" การปฏิเสธเพราะฟีเจอร์ที่ซ่อนอยู่จากนี้ไปควรอ้างอิงข้อ 2.5.19 แทน

ในทางปฏิบัติ ให้ระบุใน review notes ทุกฟีเจอร์ที่สามารถเปิดได้ด้วยสวิตช์ฝั่งเซิร์ฟเวอร์ โค้ดเชิญ การสแกน QR ภูมิภาค หรือระดับบัญชี ถ้า flag ใดจะเปิดฟีเจอร์หลังผ่านการอนุมัติ ให้เปิดฟีเจอร์นั้นในบิลด์ที่ส่งรีวิว หรือไม่ก็ตัดโค้ดนั้นออกไปจนกว่าจะถึงเวอร์ชันที่ปล่อยฟีเจอร์จริง

แอปแบบไหนได้รับผลกระทบจากการเปลี่ยนแปลงข้อ 1.2?

แนวทางข้อ 1.2 ตอนนี้ครอบคลุมทุกแอปที่ให้ผู้ใช้ "สร้าง ผลิต อัปโหลด แชร์ หรือมีส่วนร่วมในการเพิ่มเนื้อหาด้วยวิธีอื่น" และระบุถึงโซเชียลมีเดีย แพลตฟอร์ม UGC และแอปสร้างคอนเทนต์ด้วย AI อย่างชัดเจน แอปเหล่านี้ต้องกรองเนื้อหาที่ไม่เหมาะสม มีระบบรายงานพร้อมการตอบสนองอย่างทันท่วงที ให้ผู้ใช้บล็อกผู้ใช้ที่ก่อกวนได้ และเผยแพร่ข้อมูลติดต่อ

ข้อความฉบับปรับปรุงระบุ "ภาพลามกที่เผยแพร่โดยไม่ได้รับความยินยอม" ไว้คู่กับการละเมิดทรัพย์สินทางปัญญาและการกลั่นแกล้ง และเพิ่มว่า: "นักพัฒนาที่ไม่มีมาตรการป้องกันที่เหมาะสม หรือไม่แก้ไขการละเมิดที่ตรวจพบหลังได้รับแจ้ง อาจถือว่าละเมิด Developer Code of Conduct" แอปสร้างภาพหรืออวตารด้วย AI ที่สร้างเนื้อหาให้เฉพาะผู้ใช้เองก็อาจอยู่ในขอบเขตนี้ได้แล้ว การกรอง prompt และผลลัพธ์ ระบบรายงาน และข้อมูลติดต่อที่เผยแพร่ ต้องอยู่ในบิลด์ที่คุณส่งรีวิว ไม่ใช่อยู่ในแผนงานอนาคต

แนวทางข้อ 2.3.14 กำหนดอะไรเกี่ยวกับ creative assets?

แนวทางข้อ 2.3.14 กำหนดว่า creative assets ต้องเกี่ยวข้องกับเนื้อหา ฟังก์ชันการทำงาน หรือแบรนด์ของแอป ต้องเป็นไปตามกฎ metadata ปกติ และเหมาะสมกับผู้ชมทุกวัย โดยห้ามเนื้อหาที่ไม่เหมาะสม การอ้างถึงแอปอื่นอย่างชวนให้เข้าใจผิด คำกล่าวอ้างที่พิสูจน์ไม่ได้ และ "ข้อมูลราคาที่เจาะจงหรือราคาส่วนลด"

Creative assets คือสื่อภาพและวิดีโอที่ Apple เปิดตัวเมื่อวันที่ 5 ตุลาคม 2026 ตาม App Store asset best practices ของ Apple สื่อเหล่านี้จะแสดง "ใน iOS 27 และ iPadOS 27 ขึ้นไป รวมถึงในหน้าผลิตภัณฑ์ของคุณ ในผลการค้นหา และเมื่อแอปของคุณได้รับการแนะนำ" หน้าเดียวกันนี้ยังกำหนดไว้ละเอียดกว่าตัวแนวทาง โดยบอกให้ไม่ใส่ URL เว็บไซต์ สัญลักษณ์ลิขสิทธิ์ โลโก้ของแพลตฟอร์มอื่น และการยกย่องจาก Apple เช่น "Editor's Choice" และระบุว่าสื่อ "ต้องผ่านเกณฑ์อายุ 4+ แม้ว่าเรตติ้งของแอปคุณจะสูงกว่านั้น" ภาพส่วนหัวที่เขียนว่า "ลด 50% สัปดาห์นี้" หรือ "แอปจัดการงบอันดับ 1" ถือว่าผิดข้อ 2.3.14

ลิงก์ซื้อภายนอกในแนวทางข้อ 3.1.1(a) เปลี่ยนอะไรบ้าง?

แนวทางข้อ 3.1.1(a) ไม่มีหัวข้อ Music Streaming Services Entitlement แยกต่างหากอีกต่อไป entitlement นี้ถูกรวมไว้ในหัวข้อ StoreKit External Purchase Link Entitlements และข้อความระบุว่าลิงก์สามารถพาไปยัง "ปลายทางที่ได้รับอนุญาต" ได้ ปลายทางที่อนุมัติอาจแตกต่างกันไปตามภูมิภาค

กฎว่าลิงก์ใช้ได้ที่ไหนไม่ได้เปลี่ยนในการอัปเดตครั้งนี้ entitlement เหล่านี้ยังจำกัดเฉพาะบาง storefront และ storefront สหรัฐอเมริกายังคงเป็นข้อยกเว้นที่อนุญาตให้ใช้ปุ่ม ลิงก์ภายนอก และ call to action อื่นๆ ได้โดยไม่ต้องมี entitlement ถ้าคุณใช้ entitlement ตัวใดตัวหนึ่งอยู่แล้ว ให้ตรวจสอบว่าลิงก์ยังพาไปยังปลายทางที่ได้รับอนุญาตในทุก storefront ที่คุณเปิดให้บริการ

ในทางปฏิบัติ นักพัฒนาแก้การปฏิเสธเรื่องฟีเจอร์ที่ซ่อนอยู่และ UGC อย่างไร?

กรณีที่มีการรายงานต่อสาธารณะแสดงให้เห็นว่า การปฏิเสธภายใต้ถ้อยคำเรื่องฟีเจอร์ที่ซ่อนอยู่ของข้อ 2.3.1 เดิมและภายใต้ข้อ 1.2 มักแก้ได้ด้วยการทำให้ผู้รีวิวหาทุกฟีเจอร์และมาตรการป้องกันเจอได้ง่าย หรือด้วยการอุทธรณ์ การแก้โค้ดอย่างเดียวแทบไม่ได้ผล

• ในเดือนมีนาคม 2026 นักพัฒนารายหนึ่งบน Apple Developer Forums รายงานว่าแอปนาฬิกาปลุกเชิงโซเชียลแบบ native ถูกปฏิเสธภายใต้ "Guideline 2.3.1(a) - Hidden Features" และข้อ 4.2 โดยบอกว่าใช้ WebView เฉพาะกับนโยบายความเป็นส่วนตัว ข้อกำหนด และ FAQ เท่านั้น และได้ยื่นอุทธรณ์ App Review ตอบว่า App Review Board ได้ตอบกลับแล้ว จากนั้นนักพัฒนาขอให้ระบุหน้าจอที่เกี่ยวข้อง และไม่มีการโพสต์วิธีแก้ไข
• ใน GitHub issue ของ Flutter นักพัฒนาหลายรายได้รับแจ้งว่า "We discovered that your app contains hidden features" ทั้งที่เป็นแอปเรียบง่าย ผู้ร่วมพัฒนา Flutter คนหนึ่งเรียกตัวเฟรมเวิร์กว่า "a red herring" (ประเด็นหลอกให้หลงทาง) และชี้ไปที่ API ที่ไม่มีเอกสารในโค้ดแอปหรือปลั๊กอิน นักพัฒนาสองรายรายงานว่าได้รับการอนุมัติหลังอุทธรณ์โดยไม่ได้แก้โค้ด
• นักพัฒนารายหนึ่งบน Apple Developer Forums ถูกปฏิเสธภายใต้ข้อ 1.2 แม้จะมี EULA ระบบกรอง ระบบรายงาน และการบล็อกแล้ว โดยถูกขอให้มีข้อกำหนดที่ "ไม่ยอมรับเนื้อหาที่ไม่เหมาะสมเลย" และ "ดำเนินการกับรายงานเนื้อหาที่ไม่เหมาะสมภายใน 24 ชั่วโมง" การปฏิเสธครั้งที่สองเพิ่มเรื่องเรตติ้งอายุ 18+ การลบโพสต์ทันที และข้อมูลติดต่อภายในแอป นักพัฒนาตอบสนองด้วยการอธิบายทุกมาตรการป้องกันและให้ข้อมูลล็อกอินผู้ดูแลระบบไว้ใน review notes

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

ควรตรวจสอบอะไรบ้างก่อนส่งรีวิวครั้งถัดไป?

ก่อนบิลด์ถัดไป ให้ตรวจ feature flag มาตรการป้องกัน UGC creative assets และลิงก์ภายนอกเทียบกับข้อความใหม่ แล้วเขียน review notes ที่ชี้ไปยังแต่ละรายการ เช็กลิสต์ด้านล่างครอบคลุมการเปลี่ยนแปลงเดือนตุลาคม 2026

1. ทำรายการ flag ที่ควบคุมจากเซิร์ฟเวอร์ คีย์ remote config และเมนูที่ซ่อนอยู่ทั้งหมด แล้วเปิดแต่ละรายการให้ผู้รีวิวเห็น หรือตัดโค้ดที่มันควบคุมออก
2. อธิบายฟีเจอร์ใหม่แต่ละตัวอย่างเจาะจงใน Notes for Review ตามที่ข้อ 2.3.1(a) กำหนด รวมถึงวิธีเข้าถึงทุกอย่างที่อยู่หลังโค้ดเชิญ การสแกน หรือแพ็กเกจแบบเสียเงิน
3. ถ้าผู้ใช้โพสต์ แชต หรือสร้างเนื้อหาได้ ให้ยืนยันว่าระบบกรอง ระบบรายงาน การบล็อก และข้อมูลติดต่อที่เผยแพร่อยู่ในบิลด์ครบ และเขียนกระบวนการจัดการรายงานของคุณไว้
4. สำหรับการสร้างภาพหรือวิดีโอด้วย AI ให้เพิ่มตัวกรอง prompt และผลลัพธ์ที่บล็อกภาพทางเพศของบุคคลจริง และให้ผู้ใช้รายงานผลลัพธ์ได้
5. ตรวจ creative assets ทุกชิ้นว่าไม่มีราคา ส่วนลด URL คำกล่าวอ้างเรื่องรางวัล โลโก้ของแพลตฟอร์มอื่น และไม่มีสิ่งใดเกินเรตติ้ง 4+
6. ถ้าคุณใช้ entitlement สำหรับลิงก์ซื้อภายนอกหรือบริการสตรีมเพลง ให้ยืนยันว่าลิงก์พาไปยังปลายทางที่ได้รับอนุญาตในแต่ละ storefront
7. อ่านแนวทางฉบับภาษาอังกฤษซ้ำในทุกหมวดที่คุณพึ่งพา เพราะฉบับแปลอาจล่าช้าได้ถึงหนึ่งเดือน

ตัวอย่างจริง: สมมติแอปอวตาร AI ที่มีแกลเลอรีสาธารณะ และมีแพ็กสไตล์ "Pro" ที่เปิดด้วย remote config หลังเปิดตัว ภายใต้ข้อความใหม่ แอปนี้ต้องมีการกลั่นกรองและระบบรายงานสำหรับแกลเลอรี (1.2) แพ็ก Pro ต้องมองเห็นได้ในบิลด์ที่ส่งรีวิว หรือไม่ก็เก็บไว้ปล่อยในเวอร์ชันถัดไป (2.5.19) และสื่อส่วนหัวบน iOS 27 ห้ามเขียนว่า "Pro ลด 40% แล้ววันนี้" (2.3.14) ถ้าคุณกำลังรับมือกับการถูกปฏิเสธอยู่ คู่มือแก้ไขทีละแนวทาง ของเราอธิบายวิธีตอบกลับใน App Store Connect หากต้องการให้มีคนช่วยตรวจอีกแรงก่อนส่ง ดูบริการของเรา