App Store Connect เทียบกับ Google Play Console: เวิร์กโฟลว์การเผยแพร่
ถ้าคุณส่งขึ้นสโตร์เดียว คุณก็เรียนรู้คอนโซลเดียวแล้วเดินหน้าต่อได้ แต่ถ้าส่งขึ้นทั้งสองสโตร์ คุณต้องถือ mental model สองแบบที่ใช้คำเดียวกันแต่หมายถึงคนละเรื่อง คำว่า "release", "review" และ "rollout" ล้วนมีความหมายต่างกันเล็กน้อยใน App Store Connect เทียบกับ Google Play Console บทความนี้จะเรียงเวิร์กโฟลว์ทั้งสองให้ตรงกันทีละขั้น เพื่อให้คุณวางแผนการเปิดตัวที่ลงพร้อมกันทั้งสองสโตร์โดยไม่มีเรื่องเซอร์ไพรส์
เวิร์กโฟลว์เทียบเคียงกัน
เริ่มที่นี่ แต่ละแถวคือขั้นตอนหนึ่งของการปล่อยอัปเดตให้ใช้งานจริง สองคอลัมน์คือสิ่งที่เกิดขึ้นจริงในแต่ละคอนโซล
| การแก้ไขเฉพาะ metadata | การเปลี่ยนแปลง listing ส่วนใหญ่ต้องผ่านเวอร์ชันใหม่และการรีวิว มีเพียงไม่กี่ฟิลด์ที่แก้ไขได้ทันที | การแก้ไข store listing ที่ส่งและรีวิวได้โดยไม่ต้องปล่อย build ใหม่ |
Apple ปล่อยเวอร์ชันอย่างไร
ใน App Store Connect หน่วยการทำงานคือเวอร์ชัน คุณแนบ build กรอก metadata และภาพหน้าจอ แล้วส่งทั้งชุดไปที่ App Review Apple มองมันเป็นแพ็กเกจเดียว นี่คือเหตุผลที่การเปลี่ยนภาพหน้าจอหรือแก้คำอธิบายเพียงอย่างเดียว โดยทั่วไปหมายถึงเวอร์ชันใหม่และต้องผ่านการรีวิวอีกรอบ
เมื่อ App Review อนุมัติแล้ว ตัวเลือกการปล่อยของคุณจะเป็นตัวตัดสินว่าจะเกิดอะไรขึ้นต่อไป เลือก อัตโนมัติ แล้วมันจะขึ้นใช้งานทันที เลือก กดเอง แล้วมันจะจอดอยู่ที่สถานะ "Pending Developer Release" คือ Apple อนุมัติแล้วแต่ยังไม่เปิดให้ใครเห็นจนกว่าคุณจะกดปุ่ม (รอได้ถึง 24 ชั่วโมงหลังจากกด) เลือก ตั้งเวลา แล้วมันจะปล่อยอัตโนมัติในหรือหลังวันเวลาที่คุณกำหนด คุณเลือกได้ทีละเวอร์ชัน ทุกอัปเดตจึงเป็นการตัดสินใจใหม่เสมอ
สำหรับการเปิดตัวแบบค่อยเป็นค่อยไป เปิด phased release ใช้กับอัปเดตอัตโนมัติของผู้ใช้เดิม และกระจายผ่าน 7 วันโดยไต่เปอร์เซ็นต์ขึ้นเรื่อย ๆ คุณหยุดชั่วคราวได้ถ้าตัวเลขดูผิดปกติ มันไม่ใช้กับแอปใหม่เอี่ยม และไม่ใช้กับการปล่อยแบบกดเอง นี่คือสิ่งที่เทียบเท่ากับ staged rollout ของ Google ไม่ใช่การกักการปล่อยทั้งหมด
Google ปล่อยไปยัง track อย่างไร
Google แบ่งงานเดียวกันออกเป็น track ต่าง ๆ build หนึ่งเริ่มที่ testing track ไม่ว่าจะเป็น internal, closed หรือ open แล้วค่อยเลื่อนขึ้นสู่ production เมื่อคุณพร้อม internal testing เหมาะกับกลุ่มที่ไว้ใจได้กลุ่มเล็ก (สูงสุด 100 คน) closed testing ขยายไปยังลิสต์ที่เชิญ (สูงสุด 2,000 คนต่อลิสต์) open testing เปิดให้สมัครเองสาธารณะโดยไม่จำกัดจำนวน production คือทุกคนในประเทศที่คุณเลือก
เมื่อคุณ push การปล่อย managed publishing คือสิ่งที่เทียบเท่ากับการกักแบบกดเองของ Apple เมื่อเปิดใช้ การเปลี่ยนแปลงที่ผ่านการอนุมัติจะรวมอยู่ในหน้า Publishing overview ภายใต้ "changes ready to send" และจะขึ้นใช้งานก็ต่อเมื่อคุณกด publish สะดวกสำหรับการวางกำหนดปล่อยให้ตรงกับวันการตลาด เมื่อปิดใช้ การเปลี่ยนแปลงที่ผ่านรีวิวจะเผยแพร่ทันที
สำหรับการเปิดตัวแบบค่อยเป็นค่อยไป ใช้ staged rollout คือปล่อยให้ผู้ใช้เป็นเปอร์เซ็นต์แล้วค่อยเพิ่มเองไปเรื่อย ๆ และหยุดได้ถ้าอัตรา crash พุ่งขึ้น เหมือนกับ phased release ของ Apple มันมีไว้สำหรับอัปเดต ไม่ใช่การเปิดตัวครั้งแรก การปล่อย production ครั้งแรกจะไปถึงทุกคนพร้อมกัน
จุดต่างที่มักทำให้คนสะดุด
นี่คือความแตกต่างที่ควรจำให้ขึ้นใจ Apple ผูก metadata ไว้กับเวอร์ชัน ส่วน Google แยก store listing ออกจากการปล่อยเสมอ
ใน Apple ภาพหน้าจอ คำอธิบาย และคีย์เวิร์ดของคุณเป็นส่วนหนึ่งของเวอร์ชันที่กำลังรีวิว อยากอัปเดตภาพหน้าจอระหว่าง build ล่ะ สำหรับฟิลด์ส่วนใหญ่นั่นหมายถึงเวอร์ชันใหม่และต้องผ่านรีวิวอีกครั้ง ใน Google store listing เป็นวัตถุแยกต่างหาก คุณอัปเดตข้อความและกราฟิกแล้วส่งเฉพาะส่วนนั้นผ่านรีวิวได้ โดยที่ build ของแอปที่ปล่อยไปแล้วยังคงเดิม สองสโตร์ให้คำตอบที่ต่างกันมากสำหรับคำถาม "เปลี่ยนสิ่งนี้ได้ไหมโดยไม่ต้องปล่อยเวอร์ชันใหม่ทั้งหมด"
เรื่องนี้สำคัญที่สุดเมื่อการเปิดตัวมีชิ้นส่วนที่ต้องขยับเยอะ ทั้ง build ชุดภาพหน้าจอ และข้อความที่แปลเป็นหลายภาษาในหลายสิบตลาด ใน Apple คุณมักรวมทุกอย่างเป็นเวอร์ชันเดียวเพื่อให้รีวิวพร้อมกัน ใน Google คุณจัดเตรียม listing กับ release แยกกันได้ และเผยแพร่ตามลำดับที่เหมาะกับแผนของคุณ
เวลารีวิว และข้อจำกัดสำหรับบัญชีใหม่
App Review ของ Apple ใช้เวลาประมาณ 24–48 ชั่วโมงสำหรับอัปเดตทั่วไปในปี 2026 นานกว่านั้นสำหรับการส่งครั้งแรกจากนักพัฒนาใหม่ หรือรายการที่ถูกทำเครื่องหมายให้ตรวจสอบใกล้ชิดขึ้น การรีวิวของ Google มักเร็วกว่า ตั้งแต่ไม่กี่ชั่วโมงถึงไม่กี่วันสำหรับบัญชีที่ตั้งมานานแล้ว แต่มีด่านสำหรับผู้มาใหม่
บัญชีนักพัฒนา Google Play แบบ ส่วนบุคคล ที่สร้างหลังกลางเดือนพฤศจิกายน 2023 ต้องรัน closed test ที่มีผู้ทดสอบเข้าร่วมอย่างน้อย 12 คนต่อเนื่อง 14 วันก่อนจึงจะขอสิทธิ์เข้าถึง production ได้ ถ้าจำนวนลดต่ำกว่า 12 คน สถิติวันต่อเนื่องอาจรีเซ็ต บัญชีองค์กรและบัญชีส่วนบุคคลเก่าไม่ต้องผ่านขั้นนี้ Apple ไม่มีข้อกำหนดแบบนี้โดยตรง ดังนั้นถ้าคุณกำลังเปิดตัวแอปแรกในทั้งสองสโตร์ ให้เผื่อเวลาสำหรับช่วงทดสอบของ Google ไว้ล่วงหน้า เพราะมักเป็นขั้นตอนที่ใช้เวลานานที่สุด
จุดที่ Mokbi เข้ามาช่วย
ทั้งสองคอนโซลต้องการชิ้นงานสำเร็จรูปแบบเดียวกัน นั่นคือภาพหน้าจอที่ใส่กรอบและข้อความ store ที่สะอาด แปลครบตามขนาดที่กำหนดทุกขนาด Mokbi สร้างชุดนั้นครั้งเดียว คุณออกแบบภาพหน้าจอและร่างข้อความ store ในโปรเจกต์เดียว จากนั้นแปลทั้งหมดเป็น 50 ภาษา แล้วส่งออกชุดที่ตรงกับขนาดของทั้ง App Store Connect และ Google Play Console ในรอบเดียว งานเดียวกันจึงป้อนสอง listing แทนที่จะต้องทำงานหนักสองรอบแยกกัน
Mokbi เผยแพร่ให้ด้วย มันส่ง listing และชิ้นงานตรงไปยัง Google Play ผ่าน Play Developer API และจัดเตรียมเวอร์ชันใน App Store Connect ให้พร้อมสำหรับคุณกดส่ง Apple กำหนดให้ต้องกด Submit และผ่านรีวิวขั้นสุดท้ายด้วยตัวเอง ดังนั้นการกดครั้งสุดท้ายนั้นยังคงเป็นหน้าที่ของคุณ (เป็นกฎของ Apple ไม่ใช่ข้อจำกัดของ Mokbi) ไม่ว่าจะทางไหน คุณจัดการอัปเดต listing ของทั้งสองคอนโซลได้จากที่เดียว ด้วยการสมัครสมาชิกเดียว เครื่องมือแก้ไขใช้ฟรีพร้อมลายน้ำ ส่วน Solo (€29.99/เดือน) หรือ Studio (€49.99/เดือน) ปลดล็อกการส่งออกและการเผยแพร่แบบไม่จำกัดตราบใดที่ยังสมัครสมาชิกอยู่