Ví dụ ghi chú phát hành App Store: viết mục What's New nói rõ cho người dùng điều gì đã thay đổi (2026)

Ghi chú phát hành App Store tốt trả lời một câu hỏi: điều gì khác đi với tôi sau khi cập nhật? Các ví dụ ghi chú phát hành App Store dưới đây đều theo cùng một khuôn mẫu. Mở đầu bằng thay đổi người dùng sẽ nhận thấy, nêu cụ thể từng bản sửa lỗi và bỏ qua mọi thứ họ không thể thấy. Hướng dẫn của chính Apple cho trường What's New in This Version cũng nói vậy. Apple yêu cầu nêu tính năng mới, cải tiến giao diện hoặc bản sửa lỗi, và khuyên bạn cho người dùng biết "chi tiết cụ thể về các thay đổi, cải tiến hoặc bản sửa lỗi trong phiên bản".

Quy tắc về ghi chú phát hành trong App Store Connect và Google Play là gì?

Trường What's New của Apple cho phép 4.000 ký tự và là bắt buộc với mọi phiên bản sau phiên bản đầu tiên. Google Play cho phép 500 ký tự Unicode cho mỗi ngôn ngữ và cấm nội dung quảng cáo.

Tính đến tháng 10/2026, Play Console Help ghi: "Không dùng ghi chú phát hành cho mục đích quảng cáo hoặc để kêu gọi người dùng hành động." Trên Apple, hãy đặt nội dung tiếp thị vào Promotional Text. Trường này cho phép 170 ký tự, hiển thị phía trên phần mô tả, và Apple cho phép bạn cập nhật nó mà không cần gửi phiên bản mới.

Ghi chú phát hành App Store tốt trông như thế nào?

Ghi chú phát hành tốt nêu tình huống người dùng đã gặp và kết quả họ nhận được bây giờ. Các ví dụ dưới đây lấy từ một ứng dụng theo dõi thói quen giả định. Phiên bản mơ hồ là kiểu ghi chú thường được viết vội vào phút chót.

Nếu một bản sửa lỗi quá kỹ thuật để giải thích trong một câu, có lẽ người dùng sẽ không nhận ra nó, nên có thể gộp vào một dòng "cải thiện độ ổn định" ở cuối. Guideline 2.3.12 cho phép điều đó với các bản sửa nhỏ nhưng không cho phép với những thay đổi tính năng thực sự.

Có mẫu ghi chú phát hành nào tôi có thể dùng lại không?

Có. Một mẫu dùng lại được gồm một dòng tiêu đề, sau đó là các mục New, Improved và Fixed. Hãy lưu nó trong repository cạnh changelog và điền vào khi bạn tạo nhánh phát hành, chứ không phải sau khi build đã tải lên.

[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.

Với Google Play, hãy rút gọn chính ghi chú đó còn dòng tiêu đề cùng hai hoặc ba gạch đầu dòng quan trọng nhất để vừa 500 ký tự. Đặt thẻ của mỗi ngôn ngữ trên dòng riêng, ví dụ <en-US> và </en-US>. Bỏ dòng kết thúc trên Play, vì nó yêu cầu người dùng làm một việc gì đó.

Làm thế nào để biến các pull request đã merge thành ghi chú phát hành?

Để biến các pull request đã merge thành ghi chú phát hành, hãy lọc bỏ những thay đổi người dùng không thấy được, rồi viết lại mỗi thay đổi còn lại thành một triệu chứng hoặc kết quả. Làm theo các bước sau cho mỗi bản phát hành.

1. Xuất tiêu đề các pull request đã merge kể từ tag gần nhất, rồi xóa mọi thứ người dùng không thấy được, như refactor, nâng cấp dependency và thay đổi CI.
2. Viết lại mỗi mục còn lại thành một triệu chứng hoặc kết quả. "Fix nil coordinator" trở thành "Đã sửa lỗi màn hình trống sau khi đăng nhập bằng Apple."
3. Sắp xếp các mục theo số người dùng bị ảnh hưởng, không phải theo khối lượng công việc kỹ thuật bỏ ra.
4. Trong App Store Connect, tạo phiên bản mới, rồi xóa nội dung What's New được sao chép trước khi dán ghi chú mới, vì metadata của phiên bản trước được chuyển tiếp.
5. Dán ghi chú vào mọi bản địa hóa bạn hỗ trợ, đã dịch hoặc ít nhất đã kiểm tra ở từng ngôn ngữ, để người dùng ở các khu vực khác không thấy ghi chú của phiên bản cũ.
6. Với Play, dán phiên bản rút gọn vào trong thẻ ngôn ngữ và xác nhận mỗi ngôn ngữ dưới 500 ký tự.
7. Đọc to ghi chú một lần. Nếu một câu cần lập trình viên giải thích, hãy viết lại.

Ghi chú phát hành cho bản hotfix nên viết gì?

Ghi chú phát hành cho bản hotfix nên nêu phiên bản bị lỗi, mô tả triệu chứng đã được sửa và cho người dùng bị ảnh hưởng biết điều gì sẽ xảy ra sau khi họ cập nhật. Apple không cho phép quay lại phiên bản trước trên App Store, nên bản sửa luôn được phát hành dưới dạng phiên bản mới.

Ví dụ: "Đã sửa lỗi trong bản 3.4.0 khiến lời nhắc ngừng hoạt động với một số người dùng. Các lời nhắc bạn đặt trước khi cập nhật sẽ tự động hoạt động lại." Người dùng bị ảnh hưởng biết cần cập nhật, còn người không bị ảnh hưởng hiểu rằng bản sửa không liên quan đến họ. Đừng đổ lỗi cho hệ điều hành và đừng hứa ngày cho các bản sửa trong tương lai. Nếu bạn phát hành bản cập nhật bằng phased release, việc tạm dừng triển khai sẽ hạn chế số người dùng nhận bản build lỗi trong khi bản sửa đang được xét duyệt. Nếu hotfix thay đổi cách một tính năng hoạt động, hãy rà lại danh sách kiểm tra khi gửi lên App Store để ghi chú, ảnh chụp màn hình và ghi chú cho người duyệt khớp nhau.

App Review có thể từ chối bản cập nhật vì ghi chú phát hành không?

Có. Ghi chú phát hành là metadata, và App Review Guidelines đề cập trực tiếp đến chúng. Guideline 2.3.12 ghi: "Ứng dụng phải mô tả rõ ràng các tính năng mới và thay đổi sản phẩm trong phần "What's New"."

Cách diễn đạt chung chung được chấp nhận cho "các bản sửa lỗi đơn giản, cập nhật bảo mật và cải thiện hiệu năng", nhưng "những thay đổi đáng kể hơn phải được liệt kê trong ghi chú." Guideline 2.3.10 cấm tên hoặc hình ảnh của các nền tảng di động khác trong metadata, bao gồm cả What's New. Đừng mô tả các tính năng ẩn sau feature flag hoặc bất cứ thứ gì không có trong bản build đã gửi. Guideline 2.3.1(a) còn yêu cầu riêng rằng tính năng mới phải được "mô tả cụ thể trong phần Notes for Review", vì vậy hãy đặt các bước cho người duyệt và tài khoản demo ở đó, không phải trong ghi chú công khai. Nếu bạn nhận được câu hỏi về metadata, hướng dẫn khắc phục khi bị App Store từ chối của chúng tôi giải thích cách phản hồi.

Các lập trình viên khác đã gặp vấn đề gì với ghi chú phát hành?

Các trường hợp được báo cáo công khai cho thấy hai kiểu thất bại: lượt tải lên bị từ chối vì vượt giới hạn độ dài của cửa hàng, và các lần bị từ chối khi xét duyệt có nhắc đến nội dung What's New trong yêu cầu dọn dẹp.

• Giới hạn độ dài của Play trong CI. Một GitHub issue trong một template triển khai Flutter báo cáo một changelog do AI tạo đã làm hỏng lượt tải lên bản internal test của Google Play qua fastlane với lỗi: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." Các maintainer đã thêm một script cắt ngắn ghi chú trước khi tải lên: 480 ký tự cho Play và 3.800 byte cho TestFlight, vốn tính giới hạn theo byte.
• Yêu cầu dọn dẹp theo 2.3.10 bao gồm cả What's New. Một lập trình viên trên Apple Developer Forums đã đăng về lần bị từ chối theo Guideline 2.3.10 do ảnh chụp màn hình có thanh trạng thái không phải của iOS. Các bước tiếp theo của Apple yêu cầu "xóa mọi nội dung này khỏi ứng dụng và metadata, bao gồm mô tả ứng dụng, promotional text, thông tin What's New, video xem trước và ảnh chụp màn hình." Các phản hồi khuyên chụp lại ảnh màn hình và kiểm tra mọi trường metadata, kể cả ghi chú phát hành.

Bài học rút ra: giới hạn độ dài mang tính cơ học và báo lỗi rõ ràng khi tải lên, còn quy tắc xét duyệt liên quan đến nội dung và áp dụng cho mọi trường metadata. Hãy tự động hóa việc kiểm tra số ký tự, và đọc What's New cẩn thận như khi xem ảnh chụp màn hình.

Cần kiểm tra gì trước khi gửi ghi chú phát hành?

Trước khi gửi, hãy kiểm tra rằng ghi chú chỉ mô tả những gì có trong bản build, nằm trong giới hạn của từng cửa hàng và đã thay thế nội dung của phiên bản trước ở mọi ngôn ngữ.

• Dòng tiêu đề nêu thay đổi mà phần lớn người dùng sẽ nhận thấy.
• Mọi tính năng hoặc thay đổi sản phẩm đáng kể đều được liệt kê, theo yêu cầu của guideline 2.3.12.
• Mỗi bản sửa lỗi mô tả triệu chứng người dùng đã gặp, không phải mã nội bộ.
• Không có tính năng ẩn sau flag, không hứa hẹn tương lai, không có số ticket nội bộ, không có tên nền tảng khác.
• Nội dung What's New của phiên bản trước đã được xóa và thay thế ở mọi bản địa hóa.
• Ghi chú Play dưới 500 ký tự cho mỗi ngôn ngữ, đặt trong thẻ ngôn ngữ đúng, không có quảng cáo hay lời kêu gọi hành động.
• Thông điệp tiếp thị đã được chuyển sang Promotional Text trên Apple.
• Nếu bạn cũng đang có người thử nghiệm Android, cùng bộ ghi chú đã được đối chiếu với kế hoạch closed testing của bạn.

Nếu bạn muốn có thêm một người xem lại metadata bản cập nhật trước khi gửi, hãy email đến yagyeshsrbobde@gmail.com kèm bản nháp ghi chú và danh sách thay đổi trong bản build, hoặc xem dịch vụ của chúng tôi.