App Store rejection คืออะไร และทำไมเรื่องนี้ควรสนใจ
App Store rejection คือกระบวนการที่ทีมตรวจสอบของร้านแอปปฏิเสธไม่อนุมัติให้แอปเผยแพร่ เนื่องจากปัญหาด้านความสมบูรณ์ การปฏิบัติตาม app store guidelines หรือการสื่อสารที่ไม่ชัดเจนในเอกสารและวิดีโอสาธิต เมื่อแอปถูกปฏิเสธ นักพัฒนาต้องปรับปรุงทั้งโค้ด ฟีเจอร์ และคำอธิบายประกอบเพื่อให้ผ่านเกณฑ์ การเข้าใจรูปแบบการปฏิเสธและกับดักทางเทคนิคตั้งแต่ต้นช่วยลดรอบการส่งใหม่ ประหยัดเวลาในการ mobile app debugging และลดความเสี่ยงที่โปรเจกต์ดีๆ จะถูกพับทิ้งกลางทางเพราะความเหนื่อยล้าจากการรีวิวซ้ำ
กรณีของ Buildhorn เป็นตัวอย่างสดว่าการถูก App Store rejection สามารถยืดเยื้อได้ยาวนาน แอปนี้ถูกส่งเข้าสู่กระบวนการรีวิวตั้งแต่วันที่ 7 กันยายน และใช้เวลาตรวจเฉลี่ยรอบละราวสองวัน โดยทุกครั้งที่โดนปฏิเสธจะเริ่มนับเวลาใหม่อีกครั้ง เจ้าของโปรเจกต์ต้องรีบให้แอปขึ้นสโตร์เพื่อส่งผลงานเข้าร่วม Shipaton 2026 ทำให้ทุกชั่วโมงของสถานะรอรีวิวมีเดิมพันสูง การยอมรับว่ากระบวนการนี้ช้าและคาดเดายากคือก้าวแรกในการวางแผนให้ทีมและโปรเจกต์ไปต่อได้โดยไม่เสียกำลังใจ
เมื่อ SwiftUI development และ KMP กลายเป็นจุดสอบเข้มในการรีวิว
Buildhorn เป็นแอปตัวอย่างของการใช้เทคโนโลยีสมัยใหม่แต่ต้องเผชิญกติกาเก่าที่เข้มข้น แอปนี้เป็น iOS app ที่พัฒนาโดยใช้ SwiftUI ดูแลชั้น UI และเรียกใช้ Kotlin Multiplatform สำหรับงาน networking การเก็บไฟล์ และ business logic ข้อดีคือโค้ดแชร์ข้ามแพลตฟอร์ม แต่ข้อเสียคือเวลารีวิว iOS app approval ฝั่ง Apple จะมองเฉพาะสิ่งที่เกิดบนเครื่อง iPhone และต้องมั่นใจว่าการพึ่งพา backend หรือระบบภายนอกไม่ทำให้แอป “ไม่สมบูรณ์” ตาม app store guidelines ข้อ 2.1
นักพัฒนาคนนี้ต้องแก้เกมด้วยการเปิดทางลับให้รีวิวเวอร์เข้าใช้บัญชีทดสอบที่ติดตั้ง Buildhorn ล่วงหน้าและข้ามขั้นตอนติดตั้ง GitHub App ใน onboarding เพิ่มรูป subscription ให้ต่างกันชัดเจน และส่งวิดีโออธิบายขั้นตอนล็อกอินและการดึงโค้ดยืนยันทางอีเมล อย่างไรก็ตาม แอปก็ยังถูกตีตกเพราะรีวิวเวอร์ไม่สามารถเข้าถึงรหัสยืนยันอีเมลของ GitHub ได้ และถูกระบุว่าไม่ครบถ้วนภายใต้ App Store Guideline 2.1 ถึงหกครั้ง ประโยคที่ควรจำคือ “ถือว่าทุกรีวิวเวอร์เป็นคนใหม่เสมอ” เขาแนะนำให้เขียน Review Notes อธิบายทุกขั้นตอนและแนบวิดีโอ walkthrough ทุกครั้งไม่ใช่ครั้งเดียว
เอกสาร วิดีโอ และการสื่อสารที่ดีคืออาวุธหลักในการผ่าน iOS app approval
จุดพลิกเกมของ Buildhorn ไม่ได้อยู่ที่โค้ด แต่คือคุณภาพการอธิบาย แอปยังโดน App Store rejection อยู่เรื่อยๆ จนเจ้าของเปลี่ยนวิธีสื่อสารจากโน้ตสั้นๆ และสกรีนช็อต มาเป็นวิดีโอสาธิตเต็มรูปแบบ เขาใช้ iPhone simulator เปิดแอป Buildhorn คู่กับหน้าเว็บ GitHub และบรรยายทีละขั้นว่าการเปลี่ยนแปลงสถานะ repository และ build status บน GitHub ถูกสะท้อนในแอปอย่างไร แล้วอัดวิดีโอ 10 นาทีด้วย OBS Studio ก่อนส่งเข้าไปในเธรดสนทนากับรีวิวเวอร์
วันถัดมาคือจุดจบของความยืดเยื้อ รีวิวเวอร์แจ้งข่าวว่า Buildhorn ผ่านการอนุมัติและสามารถปล่อยลงสโตร์ได้ในที่สุด คำพูดที่น่าจดจำคือเขาเล่าว่า “ผมทำงานร่วมกับทีม App Review อย่างต่อเนื่อง ให้ข้อมูลทุกอย่างที่ช่วยให้เขาเข้าใจแอปและระบบภายนอกที่เกี่ยวข้อง เพื่อแสดงให้เห็นว่านี่คือแอปที่ทำงานได้จริง” การมีเว็บไซต์ที่รวมหน้าแนะนำแอป บล็อก และหน้านโยบายความเป็นส่วนตัวกับข้อกำหนดการใช้งานก็เป็นส่วนหนึ่งที่ช่วยตอบโจทย์ข้อบังคับของ app store guidelines เพราะแพลตฟอร์มกำหนดชัดว่าต้องมีหน้าข้อมูลเหล่านี้ประกอบการส่ง
กรณี CareVocal: บั๊ก Intent บน Android ที่เกือบทำลายปุ่มขอความช่วยเหลือ
ถ้าฟีเจอร์ทั่วไปพัง ผู้ใช้แค่หงุดหงิด แต่ถ้าฟีเจอร์ฉุกเฉินพัง ความเสี่ยงคือชีวิต CareVocal เป็นแอป Android ที่ออกแบบให้คนไข้สูงวัยสื่อสารความรู้สึกผ่านสามปุ่มใหญ่ สีเขียวคือ “สบายดี” สีเหลืองคือ “มีอาการเจ็บ” และสีแดงคือ “ต้องการความช่วยเหลือ” โดยเจ้าของโปรเจกต์เขียนกติกาตั้งแต่ก่อนลงมือโค้ดว่า การกดแจ้งเตือนต้องไม่รอสิ่งที่ช้า เช่น network หรือการถอดเสียง เพราะคนกดอาจเวียนหัวหรือหวาดกลัว
ปุ่มแดงตั้งใจให้ทำสามอย่างในคลิกเดียว บันทึกข้อมูลและตั้งธงให้หมอ เปิดหน้าส่ง SMS ที่เขียนข้อความเตือนล่วงหน้าถึงผู้ติดต่อที่วางใจ พร้อมเวลา และเปิดหน้าดาวน์โหลดหมายเลขฉุกเฉินในตัว dialer โดยผู้ใช้ยังต้องกดส่งและกดโทรเอง เพื่อเลี่ยงข้อจำกัดของ Google Play ที่ไม่ให้แอปส่งข้อความหรือโทรอัตโนมัติในฉากหลัง แต่เมื่อทดสอบบนเครื่องจริงด้วยโค้ดที่เรียก context.startActivity สองครั้งต่อกัน พบว่าหน้าดาวน์โหลดชนะและหน้าส่ง SMS ไม่เคยโผล่เลย นี่คือ Bug 1 ของ mobile app debugging ที่เกิดจากการแข่งกันของ Intent ระหว่างสองแอป
บทเรียนจาก Intent race usability trap และแผนเดินหน้าหลังแอปผ่านรีวิว
การแก้บั๊กปุ่มแดงของ CareVocal แสดงให้เห็นว่า “บั๊กการใช้งาน” มักไม่โผล่ใน unit test นักพัฒนาพยายามใช้ดีเลย์ครึ่งวินาทีระหว่างการเปิดหน้าส่ง SMS และหน้าดาวน์โหลด แต่ผลคือเมื่อ SMS app กลายเป็น foreground แล้ว Android ไม่อนุญาตให้แอปที่อยู่เบื้องหลังเปิดกิจกรรมใหม่อีกครั้ง startActivity ครั้งที่สองจึงถูกปฏิเสธเงียบๆ ไม่มีข้อความผิดพลาดและไม่มีสิ่งใดบนหน้าจอ เขาจึงสรุปว่าไม่มีค่า delay ใดที่แก้การแข่งขันระหว่างสองกลไกระดับระบบปฏิบัติการได้ และทางออกที่ถูกคือใช้ startActivities เพื่อเปิดลำดับกิจกรรมทั้งชุดในคำสั่งเดียวแทน
เจ้าของแอปเตือนนักพัฒนาคนอื่นไว้ชัดว่า “ทดสอบเส้นทางล้มเหลวบนเครื่องจริง ด้วยข้อมูลจริง” เพราะ emulator ที่ไม่มีรายชื่อผู้ติดต่อเคยซ่อนบั๊กทั้งหมดในรอบทดสอบแรก ด้าน Buildhorn หลังผ่านรีวิวและขึ้นสโตร์ เจ้าของวางแผนติดตามพฤติกรรมผู้ใช้ วางแผนขั้นต่อไป เขียนโพสต์ส่งงาน Shipaton และส่งเวอร์ชัน 1.1 ให้ Apple ตรวจล่วงหน้าเพื่อรองรับ iPhone Duo พร้อมยืนยันว่าจะปรับดีไซน์และอัปเดตต่อเนื่อง ทั้งสองเรื่องเล่าชี้ให้เห็นทิศทางเดียวกันว่า แอปที่ผ่านสโตร์ได้ในยุคนี้คือแอปที่ให้ความสำคัญทั้งกับการออกแบบเส้นทางฉุกเฉิน ความเข้าใจในแพตเทิร์นบั๊กเฉพาะแพลตฟอร์ม และการสื่อสารอย่างละเอียดกับทีมรีวิว
