أمثلة على ملاحظات الإصدار في App Store: اكتب نص «ما الجديد» الذي يخبر المستخدمين بما تغيّر (2026)

ملاحظات الإصدار الجيدة في App Store تجيب عن سؤال واحد: ما الذي أصبح مختلفًا بالنسبة إليّ بعد التحديث؟ جميع أمثلة ملاحظات الإصدار أدناه تتبع نمطًا واحدًا: ابدأ بالتغيير الذي سيلاحظه المستخدم، وسمِّ كل إصلاح بدقة، واستبعد كل ما لا يمكنه رؤيته. وإرشادات Apple نفسها لحقل What's New in This Version تقول الشيء ذاته؛ فهي تطلب الميزات الجديدة أو تحسينات الواجهة أو إصلاحات الأخطاء، وتوصي بإخبار المستخدمين بـ«تفاصيل التغييرات أو التحسينات أو الإصلاحات في الإصدار».

ما قواعد ملاحظات الإصدار في App Store Connect وGoogle Play؟

يتيح حقل «ما الجديد» لدى Apple ما يصل إلى 4,000 حرف، وهو مطلوب في كل إصدار بعد الأول. أما Google Play فيتيح 500 حرف Unicode لكل لغة ويحظر المحتوى الترويجي.

حتى أكتوبر 2026، تقول مساعدة Play Console: «لا تستخدم ملاحظات الإصدار لأغراض ترويجية أو لطلب إجراءات من المستخدمين». أما لدى Apple فضع النصوص التسويقية في Promotional Text بدلًا من ذلك. يتسع هذا الحقل لـ 170 حرفًا، ويظهر فوق الوصف، وتسمح لك Apple بتحديثه دون إرسال إصدار جديد.

كيف تبدو ملاحظات الإصدار الجيدة في App Store؟

ملاحظات الإصدار الجيدة تسمّي الموقف الذي كان فيه المستخدم والنتيجة التي يحصل عليها الآن. الأمثلة أدناه مأخوذة من تطبيق خيالي لتتبع العادات. أما الصيغ المبهمة فهي من نوع الملاحظات التي تُكتب في اللحظة الأخيرة.

إذا كان الإصلاح تقنيًا جدًا بحيث لا يمكن شرحه في جملة واحدة، فالأرجح أن المستخدمين لن يلاحظوه، لذا يمكن وضعه تحت سطر واحد بعنوان «تحسينات في الاستقرار» في النهاية. يسمح الإرشاد 2.3.12 بذلك للإصلاحات البسيطة، لكن ليس لتغييرات الميزات الحقيقية.

هل يوجد قالب لملاحظات الإصدار يمكنني إعادة استخدامه؟

نعم. يتكون القالب القابل لإعادة الاستخدام من عنوان، ثم أقسام New وImproved وFixed (جديد، محسَّن، مُصلَح). احفظه في المستودع بجوار سجل التغييرات واملأه عند إنشاء فرع الإصدار، لا بعد رفع البنية.

[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، اختصر الملاحظات نفسها إلى العنوان مع أهم نقطتين أو ثلاث لتتسع في 500 حرف. ضع وسوم كل لغة في أسطر مستقلة، مثل <en-US> و</en-US>. واحذف السطر الختامي في Play، لأنه يطلب من المستخدم القيام بإجراء.

كيف تحوّل طلبات الدمج المدمجة إلى ملاحظات إصدار؟

لتحويل طلبات الدمج (pull requests) المدمجة إلى ملاحظات إصدار، استبعد التغييرات التي لا يراها المستخدمون، ثم أعد صياغة كل تغيير متبقٍّ كعَرَض أو نتيجة. اتبع هذه الخطوات في كل إصدار.

1. صدّر عناوين طلبات الدمج المدمجة منذ آخر وسم (tag)، ثم احذف كل ما لا يراه المستخدمون، مثل إعادة الهيكلة وتحديثات الاعتماديات وتغييرات CI.
2. أعد صياغة كل عنصر متبقٍّ كعَرَض أو نتيجة. فعبارة "Fix nil coordinator" تصبح «إصلاح ظهور شاشة فارغة بعد تسجيل الدخول باستخدام Apple».
3. رتّب العناصر بحسب عدد المستخدمين المتأثرين بها، لا بحسب حجم العمل الهندسي الذي استغرقته.
4. في App Store Connect، أنشئ الإصدار الجديد، ثم امسح نص «ما الجديد» المنسوخ قبل لصق الملاحظات الجديدة، لأن البيانات الوصفية للإصدار السابق تُنقل تلقائيًا.
5. الصق الملاحظات في كل لغة موطَّنة تدعمها، مترجمةً أو على الأقل مراجَعةً في كل لغة، حتى لا يرى المستخدمون في المناطق الأخرى ملاحظات الإصدار الماضي.
6. بالنسبة إلى Play، الصق النسخة المختصرة داخل وسوم اللغة وتأكد أن كل لغة تبقى دون 500 حرف.
7. اقرأ الملاحظات بصوت عالٍ مرة واحدة. إذا احتاجت جملة إلى مطوّر ليشرحها، فأعد كتابتها.

ماذا يجب أن تقول ملاحظات الإصدار في الإصلاح العاجل؟

يجب أن تسمّي ملاحظات الإصلاح العاجل (hotfix) الإصدار المعطوب، وتصف العَرَض الذي أصبح مُصلَحًا، وتخبر المستخدمين المتأثرين بما سيحدث بعد التحديث. لا تتيح لك Apple العودة إلى إصدار سابق على App Store، لذا يُنشر الإصلاح دائمًا كإصدار جديد.

مثال: «إصلاح مشكلة في الإصدار 3.4.0 كانت تتوقف فيها التذكيرات عن العمل لدى بعض المستخدمين. ستُستأنف التذكيرات التي ضبطتها قبل التحديث تلقائيًا». بهذا يعرف المستخدمون المتأثرون أن عليهم التحديث، ويدرك غير المتأثرين أن الإصلاح لا يعنيهم. لا تُلقِ اللوم على نظام التشغيل ولا تَعِد بمواعيد لإصلاحات مستقبلية. وإذا كنت تنشر التحديثات عبر الإصدار التدريجي، فإن إيقاف الطرح مؤقتًا يحدّ من عدد المستخدمين الذين يحصلون على البنية المعطوبة بينما يكون الإصلاح قيد المراجعة. وإذا غيّر الإصلاح العاجل سلوك إحدى الميزات، فراجع قائمة التحقق لإرسال التطبيق إلى App Store مجددًا حتى تتطابق الملاحظات ولقطات الشاشة وملاحظات المراجعة.

هل يمكن أن ترفض مراجعة App Review تحديثًا بسبب ملاحظات الإصدار؟

نعم. ملاحظات الإصدار جزء من البيانات الوصفية، وإرشادات مراجعة App Store تتناولها مباشرة. ينص الإرشاد 2.3.12 على أنه «يجب أن تصف التطبيقات بوضوح الميزات الجديدة وتغييرات المنتج في نص "What's New"».

الصياغة العامة مسموحة لـ«إصلاحات الأخطاء البسيطة والتحديثات الأمنية وتحسينات الأداء»، لكن «يجب ذكر التغييرات الأهم في الملاحظات». ويحظر الإرشاد 2.3.10 أسماء منصات الهواتف الأخرى أو صورها في البيانات الوصفية، بما في ذلك «ما الجديد». لا تصف ميزات مخفية خلف علامات تفعيل (feature flags) أو أي شيء غير موجود في البنية المرسلة. ويشترط الإرشاد 2.3.1(a) بشكل منفصل أن تُوصف الميزات الجديدة «بدقة في قسم Notes for Review»، لذا ضع خطوات المراجِع والحساب التجريبي هناك، لا في الملاحظات العامة. وإذا تلقيت سؤالًا بشأن البيانات الوصفية، فإن دليلنا حول إصلاح حالات الرفض في App Store يشرح كيفية الرد.

ما المشكلات التي واجهها مطورون آخرون مع ملاحظات الإصدار؟

تُظهر الحالات المُبلَّغ عنها علنًا نوعين من الإخفاق: عمليات رفع تُرفض لتجاوزها حد الطول في المتجر، وحالات رفض في المراجعة تتضمن تعليمات التنظيف فيها نص «ما الجديد».

• حد الطول في Play ضمن CI. يُبلغ بلاغ على GitHub في قالب نشر Flutter عن سجل تغييرات مولَّد بالذكاء الاصطناعي أفشل رفع اختبار داخلي على 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 يشمل «ما الجديد». نشر مطوّر على منتديات مطوري Apple حالة رفض بموجب الإرشاد 2.3.10 سببها أشرطة حالة غير تابعة لـ iOS في لقطات الشاشة. وجاء في الخطوات التالية من Apple: «أزل جميع مواضع هذه المعلومات من تطبيقك وبياناته الوصفية، بما في ذلك وصف التطبيق والنص الترويجي ومعلومات What's New والمعاينات ولقطات الشاشة». ونصحت الردود بإعادة التقاط لقطات الشاشة ومراجعة كل حقل من حقول البيانات الوصفية، بما فيها ملاحظات الإصدار.

الخلاصة: حد الطول مسألة آلية تفشل بشكل واضح عند الرفع، أما قواعد المراجعة فتتعلق بالمحتوى وتنطبق على كل حقل من حقول البيانات الوصفية. اجعل التحقق من عدد الأحرف آليًا، واقرأ «ما الجديد» بالعناية نفسها التي تراجع بها لقطات الشاشة.

ما الذي يجب التحقق منه قبل إرسال ملاحظات الإصدار؟

قبل الإرسال، تحقق من أن الملاحظات تصف فقط ما هو موجود في البنية، وتلتزم بحدود كل متجر، وتحل محل نص الإصدار الماضي في كل لغة.

• العنوان يسمّي التغيير الذي سيلاحظه معظم المستخدمين.
• كل ميزة مهمة أو تغيير في المنتج مذكور، كما يشترط الإرشاد 2.3.12.
• كل إصلاح يصف عَرَضًا رآه المستخدم، لا شيفرة داخلية.
• لا ميزات خلف علامات تفعيل، ولا وعود مستقبلية، ولا أرقام تذاكر داخلية، ولا أسماء منصات أخرى.
• نص «ما الجديد» للإصدار السابق ممسوح ومستبدَل في كل لغة موطَّنة.
• ملاحظات Play دون 500 حرف لكل لغة، ومحاطة بوسوم لغة صحيحة، ودون ترويج أو دعوات لاتخاذ إجراء.
• الرسائل التسويقية منقولة إلى Promotional Text لدى Apple.
• إذا كنت تدير مختبِرين على Android أيضًا، فقد رُوجعت الملاحظات نفسها مقابل خطة الاختبار المغلق.

إذا أردت عينًا ثانية تراجع البيانات الوصفية لتحديثك قبل الإرسال، فراسل yagyeshsrbobde@gmail.com مرفقًا مسودة ملاحظاتك وقائمة التغييرات في البنية، أو اطّلع على خدماتنا.