App Store रिलीज़ नोट्स के उदाहरण: ऐसा What's New टेक्स्ट लिखें जो यूज़र्स को बताए कि क्या बदला (2026)

अच्छे App Store रिलीज़ नोट्स एक सवाल का जवाब देते हैं: अपडेट करने के बाद मेरे लिए क्या अलग है? नीचे दिए गए App Store रिलीज़ नोट्स के सभी उदाहरण एक ही पैटर्न पर चलते हैं। उस बदलाव से शुरू करें जिसे यूज़र नोटिस करेगा, हर फ़िक्स का नाम साफ़-साफ़ लें, और जो कुछ यूज़र देख नहीं सकते उसे छोड़ दें। What's New in This Version फ़ील्ड के लिए Apple की अपनी गाइडेंस भी यही कहती है। यह नए फ़ीचर, UI सुधार या बग फ़िक्स के बारे में पूछती है और सुझाव देती है कि यूज़र्स को "वर्ज़न में हुए बदलावों, सुधारों या फ़िक्स का ब्योरा" बताया जाए।

App Store Connect और Google Play में रिलीज़ नोट्स के नियम क्या हैं?

Apple की What's New फ़ील्ड में 4,000 कैरेक्टर लिखे जा सकते हैं और पहले वर्ज़न के बाद हर वर्ज़न पर यह ज़रूरी है। Google Play हर भाषा के लिए 500 Unicode कैरेक्टर की अनुमति देता है और प्रमोशनल कंटेंट पर रोक लगाता है।

अक्टूबर 2026 तक, Play Console Help कहता है: "रिलीज़ नोट्स का इस्तेमाल प्रमोशन के लिए या यूज़र्स से कोई एक्शन करवाने के लिए न करें।" 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 पर आख़िरी लाइन हटा दें, क्योंकि वह यूज़र से कुछ करने को कहती है।

मर्ज हुए पुल रिक्वेस्ट को रिलीज़ नोट्स में कैसे बदलें?

मर्ज हुए पुल रिक्वेस्ट को रिलीज़ नोट्स में बदलने के लिए, वे बदलाव हटा दें जो यूज़र्स देख नहीं सकते, फिर बचे हुए हर बदलाव को एक समस्या या नतीजे के रूप में दोबारा लिखें। हर रिलीज़ के लिए ये स्टेप्स अपनाएँ।

1. पिछले टैग के बाद मर्ज हुए पुल रिक्वेस्ट के टाइटल एक्सपोर्ट करें, फिर वह सब हटा दें जो यूज़र्स नहीं देख सकते, जैसे रिफ़ैक्टर, डिपेंडेंसी बंप और CI बदलाव।
2. बचे हुए हर आइटम को एक समस्या या नतीजे के रूप में दोबारा लिखें। "Fix nil coordinator" बन जाता है "Apple से साइन इन करने के बाद दिखने वाली खाली स्क्रीन ठीक की गई।"
3. आइटम्स को इस हिसाब से क्रम दें कि वे कितने यूज़र्स पर असर डालते हैं, न कि उन पर कितना इंजीनियरिंग काम लगा।
4. App Store Connect में नया वर्ज़न बनाएँ, फिर नए नोट्स पेस्ट करने से पहले कॉपी हुआ What's New टेक्स्ट हटा दें, क्योंकि पिछले वर्ज़न का मेटाडेटा आगे आ जाता है।
5. नोट्स को हर उस लोकलाइज़ेशन में पेस्ट करें जिसे आप सपोर्ट करते हैं, अनुवाद करके या कम से कम हर भाषा में जाँचकर, ताकि दूसरे लोकेल के यूज़र्स को पिछले वर्ज़न के नोट्स न दिखें।
6. Play के लिए, छोटा वर्ज़न लैंग्वेज टैग के अंदर पेस्ट करें और पक्का करें कि हर भाषा 500 कैरेक्टर से कम रहे।
7. नोट्स को एक बार ज़ोर से पढ़ें। अगर किसी वाक्य को समझाने के लिए डेवलपर की ज़रूरत पड़े, तो उसे दोबारा लिखें।

हॉटफ़िक्स के रिलीज़ नोट्स में क्या लिखना चाहिए?

हॉटफ़िक्स के रिलीज़ नोट्स में टूटे हुए वर्ज़न का नाम होना चाहिए, उस समस्या का वर्णन होना चाहिए जो अब ठीक हो गई है, और प्रभावित यूज़र्स को बताना चाहिए कि अपडेट के बाद क्या होगा। Apple आपको App Store पर पिछले वर्ज़न पर वापस जाने नहीं देता, इसलिए फ़िक्स हमेशा नए वर्ज़न के रूप में ही शिप होता है।

एक उदाहरण: "3.4.0 में कुछ यूज़र्स के लिए रिमाइंडर बंद हो जाने की समस्या ठीक की गई। अपडेट से पहले सेट किए गए रिमाइंडर अपने-आप फिर से चालू हो जाएँगे।" जो यूज़र्स प्रभावित थे, उन्हें पता चल जाता है कि अपडेट करना है, और जो नहीं थे, वे समझ जाते हैं कि यह फ़िक्स उनसे जुड़ा नहीं है। ऑपरेटिंग सिस्टम पर दोष न डालें और आगे के फ़िक्स की तारीख़ों का वादा न करें। अगर आप फ़ेज़्ड रिलीज़ के साथ अपडेट शिप करते हैं, तो रोलआउट रोकने से उन यूज़र्स की संख्या सीमित रहती है जिन्हें टूटा हुआ बिल्ड मिलता है, जब तक फ़िक्स रिव्यू में है। अगर हॉटफ़िक्स किसी फ़ीचर का व्यवहार बदलता है, तो App Store सबमिशन चेकलिस्ट दोबारा देखें ताकि नोट्स, स्क्रीनशॉट और रिव्यू नोट्स आपस में मेल खाएँ।

क्या App Review रिलीज़ नोट्स की वजह से अपडेट रिजेक्ट कर सकता है?

हाँ। रिलीज़ नोट्स मेटाडेटा हैं, और App Review Guidelines सीधे उन पर लागू होती हैं। गाइडलाइन 2.3.12 कहती है, "ऐप्स को अपने "What's New" टेक्स्ट में नए फ़ीचर और प्रोडक्ट बदलावों का साफ़ वर्णन करना चाहिए।"

"साधारण बग फ़िक्स, सिक्योरिटी अपडेट और परफ़ॉर्मेंस सुधार" के लिए सामान्य शब्दों की अनुमति है, लेकिन "बड़े बदलाव नोट्स में सूचीबद्ध होने चाहिए।" गाइडलाइन 2.3.10 मेटाडेटा में दूसरे मोबाइल प्लेटफ़ॉर्म के नाम या इमेजरी पर रोक लगाती है, और इसमें What's New भी शामिल है। फ़्लैग के पीछे छिपे फ़ीचर या ऐसी किसी चीज़ का वर्णन न करें जो सबमिट किए गए बिल्ड में नहीं है। गाइडलाइन 2.3.1(a) अलग से यह माँग करती है कि नए फ़ीचर "Notes for Review सेक्शन में ब्योरे के साथ बताए जाएँ", इसलिए रिव्यूअर के स्टेप्स और डेमो अकाउंट वहीं रखें, पब्लिक नोट्स में नहीं। अगर आपसे मेटाडेटा को लेकर कोई सवाल पूछा जाता है, तो App Store रिजेक्शन ठीक करने पर हमारी गाइड बताती है कि जवाब कैसे दें।

दूसरे डेवलपर्स को रिलीज़ नोट्स में कौन-सी समस्याएँ आई हैं?

सार्वजनिक रूप से रिपोर्ट किए गए मामलों में दो तरह की विफलताएँ दिखती हैं: स्टोर की लंबाई सीमा पार करने पर रिजेक्ट हुए अपलोड, और ऐसे रिव्यू रिजेक्शन जिनके सुधार निर्देशों में What's New टेक्स्ट भी शामिल है।

• CI में Play की लंबाई सीमा। एक Flutter डिप्लॉयमेंट टेम्पलेट के GitHub इश्यू में बताया गया है कि AI से बने एक चेंजलॉग ने fastlane के ज़रिए Google Play इंटरनल टेस्ट अपलोड को इस एरर के साथ तोड़ दिया: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." मेंटेनर्स ने एक स्क्रिप्ट जोड़ी जो अपलोड से पहले नोट्स छोटे कर देती है: Play के लिए 480 कैरेक्टर और TestFlight के लिए 3,800 बाइट, जो अपनी सीमा बाइट्स में मापता है।
• 2.3.10 का सुधार जिसमें What's New शामिल है। Apple Developer Forums पर एक डेवलपर ने गाइडलाइन 2.3.10 का रिजेक्शन पोस्ट किया, जो स्क्रीनशॉट में नॉन-iOS स्टेटस बार की वजह से हुआ था। Apple के अगले स्टेप्स में कहा गया था कि "इस जानकारी के सभी उदाहरण अपने ऐप और उसके मेटाडेटा से हटा दें, जिसमें ऐप डिस्क्रिप्शन, प्रमोशनल टेक्स्ट, What's New जानकारी, प्रीव्यू और स्क्रीनशॉट शामिल हैं।" जवाबों में स्क्रीनशॉट दोबारा लेने और रिलीज़ नोट्स समेत हर मेटाडेटा फ़ील्ड जाँचने की सलाह दी गई।

सीख यह है: लंबाई सीमा एक मशीनी जाँच है और अपलोड के समय साफ़ तौर पर फ़ेल होती है, जबकि रिव्यू के नियम कंटेंट से जुड़े हैं और हर मेटाडेटा फ़ील्ड पर लागू होते हैं। कैरेक्टर जाँच को ऑटोमेट करें, और What's New को उतनी ही सावधानी से पढ़ें जितनी सावधानी से आप स्क्रीनशॉट देखते हैं।

रिलीज़ नोट्स सबमिट करने से पहले क्या जाँचना चाहिए?

सबमिट करने से पहले जाँचें कि नोट्स सिर्फ़ वही बताते हैं जो बिल्ड में है, हर स्टोर की सीमाओं में आते हैं, और हर भाषा में पिछले वर्ज़न के टेक्स्ट की जगह ले चुके हैं।

• हेडलाइन उस बदलाव का नाम लेती है जिसे ज़्यादातर यूज़र्स नोटिस करेंगे।
• हर बड़ा फ़ीचर या प्रोडक्ट बदलाव सूचीबद्ध है, जैसा गाइडलाइन 2.3.12 माँगती है।
• हर फ़िक्स उस समस्या का वर्णन करता है जो यूज़र ने देखी, अंदरूनी कोड का नहीं।
• फ़्लैग के पीछे के फ़ीचर नहीं, भविष्य के वादे नहीं, अंदरूनी टिकट नंबर नहीं, दूसरे प्लेटफ़ॉर्म के नाम नहीं।
• पिछले वर्ज़न का What's New टेक्स्ट हर लोकलाइज़ेशन में हटाकर बदल दिया गया है।
• Play नोट्स हर भाषा में 500 कैरेक्टर से कम हैं, सही लैंग्वेज टैग में लपेटे गए हैं, और इनमें कोई प्रमोशन या कॉल टू एक्शन नहीं है।
• मार्केटिंग मैसेज Apple पर Promotional Text में ले जाए गए हैं।
• अगर आप Android टेस्टर्स के साथ भी काम कर रहे हैं, तो इन्हीं नोट्स को अपने क्लोज़्ड टेस्टिंग प्लान से मिलाकर जाँच लिया गया है।

अगर आप चाहते हैं कि सबमिट करने से पहले कोई और आपके अपडेट मेटाडेटा पर नज़र डाले, तो अपने ड्राफ़्ट नोट्स और बिल्ड में हुए बदलावों की सूची के साथ yagyeshsrbobde@gmail.com पर ईमेल करें, या हमारी सेवाएँ देखें।