ตัวอย่าง release notes บน App Store: เขียนข้อความ What's New ให้ผู้ใช้รู้ว่าอะไรเปลี่ยนไป (2026)

release notes บน App Store ที่ดีจะตอบคำถามเดียว: หลังอัปเดตแล้ว มีอะไรต่างไปสำหรับฉันบ้าง? ตัวอย่าง release notes บน App Store ด้านล่างนี้ทั้งหมดใช้รูปแบบเดียวกัน คือขึ้นต้นด้วยการเปลี่ยนแปลงที่ผู้ใช้จะสังเกตเห็น ระบุการแก้ไขแต่ละรายการอย่างเจาะจง และตัดสิ่งที่ผู้ใช้มองไม่เห็นออกไป คำแนะนำของ Apple เองสำหรับช่อง What's New in This Version ก็พูดไว้แบบเดียวกัน โดยขอให้ใส่ฟีเจอร์ใหม่ การปรับปรุง UI หรือการแก้บั๊ก และแนะนำให้บอกผู้ใช้ถึง "รายละเอียดของการเปลี่ยนแปลง การปรับปรุง หรือการแก้ไขในเวอร์ชันนี้"

กฎของ release notes ใน App Store Connect และ Google Play มีอะไรบ้าง?

ช่อง What's New ของ Apple รองรับได้ 4,000 อักขระ และต้องกรอกในทุกเวอร์ชันหลังเวอร์ชันแรก ส่วน Google Play รองรับได้ 500 อักขระ Unicode ต่อภาษา และห้ามใส่เนื้อหาเชิงโปรโมต

ณ เดือนตุลาคม 2026 Play Console Help ระบุว่า: "ห้ามใช้ release notes เพื่อการโปรโมตหรือเพื่อเชิญชวนให้ผู้ใช้ทำสิ่งใด" ฝั่ง Apple ให้ใส่ข้อความการตลาดไว้ใน Promotional Text แทน ช่องนี้รองรับได้ 170 อักขระ แสดงอยู่เหนือคำอธิบายแอป และ Apple อนุญาตให้แก้ไขได้โดยไม่ต้องส่งเวอร์ชันใหม่

release notes บน App Store ที่ดีมีหน้าตาแบบไหน?

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

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

มีเทมเพลต release notes ที่นำไปใช้ซ้ำได้ไหม?

มี เทมเพลตที่ใช้ซ้ำได้ประกอบด้วยหัวข้อหลัก แล้วตามด้วยส่วน New, Improved และ Fixed เก็บไว้ใน repository ข้าง changelog และกรอกตอนที่แตก release branch ไม่ใช่หลังจากอัปโหลด build ไปแล้ว

[One-line headline: the change most users will notice]

New
- [Feature]: [what you can now do], [where to find it]

Improved
- [Screen or flow]: [what feels different]

Fixed
- [Symptom the user saw] when [situation]

Thanks for the reports. Reply via Settings > Help if anything looks off.

สำหรับ Google Play ให้ตัดบันทึกชุดเดียวกันให้เหลือแค่หัวข้อหลักกับ bullet สองถึงสามข้อแรก เพื่อให้พอดีกับ 500 อักขระ วางแท็กของแต่ละภาษาไว้บรรทัดของตัวเอง เช่น <en-US> และ </en-US> และตัดบรรทัดปิดท้ายออกสำหรับ Play เพราะเป็นการขอให้ผู้ใช้ทำบางอย่าง

จะเปลี่ยน pull request ที่ merge แล้วให้เป็น release notes ได้อย่างไร?

ในการเปลี่ยน pull request ที่ merge แล้วให้เป็น release notes ให้กรองการเปลี่ยนแปลงที่ผู้ใช้มองไม่เห็นออกก่อน แล้วเขียนการเปลี่ยนแปลงที่เหลือแต่ละรายการใหม่ในรูปของอาการหรือผลลัพธ์ ทำตามขั้นตอนเหล่านี้ทุกครั้งที่ออก release

1. ดึงรายชื่อ pull request ที่ merge แล้วตั้งแต่ tag ล่าสุด แล้วลบทุกอย่างที่ผู้ใช้มองไม่เห็นออก เช่น การ refactor การอัปเดต dependency และการเปลี่ยนแปลง CI
2. เขียนแต่ละรายการที่เหลือใหม่ในรูปของอาการหรือผลลัพธ์ "Fix nil coordinator" จะกลายเป็น "แก้ไขหน้าจอว่างเปล่าหลังลงชื่อเข้าใช้ด้วย Apple"
3. เรียงลำดับรายการตามจำนวนผู้ใช้ที่ได้รับผลกระทบ ไม่ใช่ตามปริมาณงานวิศวกรรมที่ใช้
4. ใน App Store Connect ให้สร้างเวอร์ชันใหม่ แล้ว ลบข้อความ What's New ที่ถูกคัดลอกมา ก่อนวางบันทึกใหม่ เพราะ metadata ของเวอร์ชันก่อนหน้าจะถูกยกมาด้วย
5. วางบันทึกลงในทุกภาษาที่คุณรองรับ โดยแปลแล้วหรืออย่างน้อยตรวจทานในแต่ละภาษา เพื่อไม่ให้ผู้ใช้ในภาษาอื่นเห็นบันทึกของเวอร์ชันที่แล้ว
6. สำหรับ Play ให้วางเวอร์ชันที่ย่อแล้วไว้ภายในแท็กภาษา และตรวจสอบว่าแต่ละภาษาไม่เกิน 500 อักขระ
7. อ่านบันทึกออกเสียงหนึ่งรอบ ถ้าประโยคใดต้องให้นักพัฒนามาอธิบาย ให้เขียนใหม่

release notes ของ hotfix ควรเขียนว่าอะไร?

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

ตัวอย่าง: "แก้ไขปัญหาในเวอร์ชัน 3.4.0 ที่การแจ้งเตือนหยุดทำงานสำหรับผู้ใช้บางราย การแจ้งเตือนที่คุณตั้งไว้ก่อนอัปเดตจะกลับมาทำงานโดยอัตโนมัติ" ผู้ใช้ที่ได้รับผลกระทบจะรู้ว่าควรอัปเดต และผู้ใช้ที่ไม่ได้รับผลกระทบก็รู้ว่าการแก้ไขนี้ไม่เกี่ยวกับพวกเขา อย่าโทษระบบปฏิบัติการ และอย่าสัญญาวันที่สำหรับการแก้ไขในอนาคต ถ้าคุณปล่อยอัปเดตแบบ phased release การหยุด rollout ชั่วคราวจะช่วยจำกัดจำนวนผู้ใช้ที่ได้รับ build ที่มีปัญหาระหว่างที่การแก้ไขรอรีวิวอยู่ ถ้า hotfix เปลี่ยนวิธีการทำงานของฟีเจอร์ ให้ไล่ตาม เช็กลิสต์การส่งแอปขึ้น App Store อีกครั้ง เพื่อให้บันทึก ภาพหน้าจอ และ review notes ตรงกัน

App Review ปฏิเสธอัปเดตเพราะ release notes ได้หรือไม่?

ได้ release notes ถือเป็น metadata และ App Review Guidelines ครอบคลุมเรื่องนี้โดยตรง แนวทาง 2.3.12 ระบุว่า "แอปต้องอธิบายฟีเจอร์ใหม่และการเปลี่ยนแปลงของผลิตภัณฑ์อย่างชัดเจนในข้อความ "What's New""

ถ้อยคำแบบกว้างๆ ใช้ได้กับ "การแก้บั๊กทั่วไป อัปเดตด้านความปลอดภัย และการปรับปรุงประสิทธิภาพ" แต่ "การเปลี่ยนแปลงที่สำคัญกว่านั้นต้องระบุไว้ในบันทึก" แนวทาง 2.3.10 ห้ามใช้ชื่อหรือภาพของแพลตฟอร์มมือถืออื่นใน metadata ซึ่งรวมถึง What's New ด้วย อย่าอธิบายฟีเจอร์ที่ซ่อนอยู่หลัง flag หรือสิ่งใดที่ไม่มีอยู่ใน build ที่ส่งไป นอกจากนี้ แนวทาง 2.3.1(a) ยังกำหนดให้ฟีเจอร์ใหม่ต้อง "อธิบายอย่างเจาะจงในส่วน Notes for Review" ดังนั้นให้ใส่ขั้นตอนสำหรับผู้รีวิวและ บัญชีเดโม ไว้ตรงนั้น ไม่ใช่ในบันทึกสาธารณะ หากคุณได้รับคำถามเรื่อง metadata คู่มือ การแก้ไขเมื่อถูก App Store ปฏิเสธ ของเราอธิบายวิธีตอบกลับไว้

นักพัฒนาคนอื่นเคยเจอปัญหาอะไรกับ release notes บ้าง?

กรณีที่มีการรายงานต่อสาธารณะแสดงให้เห็นความล้มเหลวสองแบบ: การอัปโหลดถูกปฏิเสธเพราะเกินขีดจำกัดความยาวของสโตร์ และการปฏิเสธจากการรีวิวที่รวมข้อความ What's New ไว้ในคำสั่งให้แก้ไขด้วย

• ขีดจำกัดความยาวของ Play ใน CI GitHub issue ในเทมเพลตการ deploy ของ Flutter รายงานว่า changelog ที่สร้างโดย AI ทำให้การอัปโหลด internal test ขึ้น Google Play ผ่าน fastlane ล้มเหลวพร้อมข้อความ: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." ผู้ดูแลจึงเพิ่มสคริปต์ที่ตัดบันทึกให้สั้นลงก่อนอัปโหลด: 480 อักขระสำหรับ Play และ 3,800 ไบต์สำหรับ TestFlight ซึ่งวัดขีดจำกัดเป็นไบต์
• การแก้ไขตาม 2.3.10 ที่รวมถึง What's New นักพัฒนารายหนึ่งบน Apple Developer Forums โพสต์ถึงการถูกปฏิเสธตามแนวทาง 2.3.10 ที่เกิดจากแถบสถานะที่ไม่ใช่ของ iOS ในภาพหน้าจอ ขั้นตอนถัดไปจาก Apple ระบุให้ "ลบข้อมูลนี้ทั้งหมดออกจากแอปและ metadata ของคุณ รวมถึงคำอธิบายแอป promotional text ข้อมูล What's New พรีวิว และภาพหน้าจอ" คำตอบในกระทู้แนะนำให้ถ่ายภาพหน้าจอใหม่และตรวจสอบ metadata ทุกช่อง รวมถึง release notes ด้วย

บทเรียนคือ ขีดจำกัดความยาวเป็นเรื่องเชิงกลไกและจะล้มเหลวอย่างชัดเจนตอนอัปโหลด ขณะที่กฎการรีวิวเป็นเรื่องของเนื้อหาและมีผลกับ metadata ทุกช่อง ให้ตั้งการตรวจนับอักขระแบบอัตโนมัติ และอ่าน What's New อย่างละเอียดเท่ากับที่ตรวจภาพหน้าจอ

ควรตรวจสอบอะไรบ้างก่อนส่ง release notes?

ก่อนส่ง ให้ตรวจสอบว่าบันทึกอธิบายเฉพาะสิ่งที่มีอยู่ใน build อยู่ในขีดจำกัดของแต่ละสโตร์ และแทนที่ข้อความของเวอร์ชันที่แล้วในทุกภาษาแล้ว

• หัวข้อหลักระบุการเปลี่ยนแปลงที่ผู้ใช้ส่วนใหญ่จะสังเกตเห็น
• ฟีเจอร์หรือการเปลี่ยนแปลงผลิตภัณฑ์ที่สำคัญทุกรายการถูกระบุไว้ ตามที่แนวทาง 2.3.12 กำหนด
• การแก้ไขทุกรายการอธิบายอาการที่ผู้ใช้เคยเจอ ไม่ใช่โค้ดภายใน
• ไม่มีฟีเจอร์ที่ซ่อนหลัง flag ไม่มีคำสัญญาในอนาคต ไม่มีหมายเลข ticket ภายใน ไม่มีชื่อแพลตฟอร์มอื่น
• ลบข้อความ What's New ของเวอร์ชันก่อนหน้าและแทนที่แล้วในทุกภาษา
• บันทึกของ Play ไม่เกิน 500 อักขระต่อภาษา ครอบด้วยแท็กภาษาที่ถูกต้อง และไม่มีการโปรโมตหรือการเชิญชวนให้ทำสิ่งใด
• ย้ายข้อความการตลาดไปไว้ใน Promotional Text ฝั่ง Apple แล้ว
• ถ้าคุณมีผู้ทดสอบ Android ด้วย ได้ตรวจสอบบันทึกชุดเดียวกันกับ แผน closed testing ของคุณแล้ว

ถ้าคุณอยากให้มีคนช่วยตรวจ metadata ของอัปเดตอีกแรงก่อนส่ง ส่งอีเมลมาที่ yagyeshsrbobde@gmail.com พร้อมร่างบันทึกและรายการการเปลี่ยนแปลงใน build หรือดู บริการ ของเรา