อีเมลแจ้งปฏิเสธเขียนไว้แล้วว่าต้องทำอะไรต่อ

หาหมายเลขข้อกำหนดก่อน

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

ถ้าข้ามหมายเลขไปอ่านแต่เนื้อความ โอกาสแก้ผิดจุดสูงมาก ประโยคที่ว่า “แอปยังมีประโยชน์ไม่พอ” ฟังดูเหมือนให้ใส่ฟีเจอร์เพิ่ม แต่ถ้าหมายเลขที่แนบมาชี้ไปที่ข้อกำหนดเรื่องฟังก์ชันขั้นต่ำ สิ่งที่เขาขอไม่ใช่จำนวนแต่เป็นลักษณะ นั่นคือสิ่งที่เบราว์เซอร์ทำได้อยู่แล้วก็ไม่มีเหตุผลจะมาอยู่บนสโตร์อีกรอบ อ่านประโยคด้วยอารมณ์แล้วจะเดินไปทางเพิ่มฟีเจอร์ อ่านหมายเลขแล้วทิศทางถูกกำหนดให้เอง

เรื่องที่ต้องบิลด์ใหม่ กับเรื่องที่ตอบกลับก็จบ

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

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

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

ที่ถูกสกัดก่อนถึงมือผู้ตรวจ

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

รายการที่ต้องประกาศก็อยู่จุดเดียวกัน ถ้าสิ่งที่กรอกในแบบฟอร์มความปลอดภัยของข้อมูลไม่ตรงกับพฤติกรรมจริงของแอป งานจะถูกตีกลับ ใช้ตัวระบุโฆษณาแล้วไม่ประกาศก็ไปต่อไม่ได้เช่นกัน แอปที่เปิดให้สมัครบัญชีต้องมีทางขอลบบัญชีจากในแอปได้ และ Google ยังขอ URL หน้าคำขอลบบัญชีที่เปิดได้โดยไม่ต้องล็อกอินเพิ่มอีกหนึ่งอัน ส่วน URL นโยบายความเป็นส่วนตัวเป็นเงื่อนไขร่วมของทั้งสองสโตร์

ทั้งหมดนี้ไม่เกี่ยวกับฝีมือเขียนโค้ด ถ้าจ้างข้างนอกทำแอป ควรย้อนไปดูว่าตกลงกันไว้ว่าใครเป็นคนกรอกเอกสารและคำประกาศพวกนี้ สภาพที่งานพัฒนาเสร็จแล้วแต่งานฝั่งในบัญชีสโตร์ยังค้าง แล้วสองฝ่ายต่างคิดว่าเป็นหน้าที่ของอีกฝ่าย เกิดขึ้นบ่อย

แอปที่เป็นเว็บไซต์ห่อไว้ชั้นเดียว

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

สมมติว่าส่งรอบแรกแล้วผ่าน

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

มีอีเมลแจ้งปฏิเสธฉบับเดียวก็เริ่มได้

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