iOS 27, Apple को और बढ़ते हुए regional laws की एक पूरी लिस्ट को, एक formal तरीका देता है कि आपकी app को user की age पता चले, इससे पहले कि आप उस पर कोई data collect करें। अगर आपकी app minors से कुछ भी collect करती है — और ज़्यादातर consumer apps ऐसा करती हैं बिना इसे इस तरह सोचे — तो consent माँगने और collection document करने का तरीका बदलना ज़रूरी है। कभी नहीं, बल्कि बढ़ते हुए regions की लिस्ट के लिए, अभी। भारत में Android का market share 95%+ है, फिर भी compliance की ज़िम्मेदारी platform-share से तय नहीं होती — अगर आपकी app iOS पर भी live है, तो यह checklist उतना ही ज़रूरी है, चाहे वो segment छोटा ही क्यों न हो।
चूँकि यह एक compliance topic है, शुरुआत में ही एक disclaimer: यह article marketing और product teams के लिए एक practical orientation है, legal advice नहीं। आपकी obligations इस पर depend करती हैं कि आपके users कहाँ हैं और आपकी app क्या करती है, और specifics पर एक lawyer का sign-off ज़रूरी है। यह guide बताती है कि iOS 27 क्या introduce कर रहा है, इसका आपकी tracking और segmentation पर क्या असर है, और App Store gate और सख्त होने से पहले काम करने के लिए एक checklist। Pushwoosh एक customer engagement platform है, और जहाँ consent और data collection आपके Pushwoosh setup को touch करते हैं, वहाँ हम सीधे point out करते हैं।
iOS 27 वास्तव में क्या introduce करता है
इसके केंद्र में दो APIs हैं, और ये साथ मिलकर काम करते हैं।
Declared Age Range API आपकी app को user की age band request करने देता है, जैसे 13+, 16+, या 18+, बिना कभी birthdate माँगे या store किए। Apple range देता है; आपको एक signal मिलता है, date नहीं। यह framework iOS 26 से available है, और iOS 27 में इसके आसपास के requirements और enforcement सख्त हो रहे हैं।
PermissionKit parental-consent वाला हिस्सा संभालता है। जब आपकी app कोई significant change करती है जो किसी minor के app इस्तेमाल करने के तरीके को affect करता है, तो PermissionKit वही flow है जो user को inform करता है और, regulated regions में, minor के आगे बढ़ने से पहले parent या guardian की approval माँगता है।
Design का सबसे ज़रूरी point यह है: system आपको बताता है कि यह कब apply होता है। isEligibleForAgeFeatures और requiredRegulatoryFeatures जैसे signals के through, OS बताता है कि किसी given user पर age obligations apply होती हैं या नहीं, और क्या आपको age range या parental consent request करने की ज़रूरत है। आप हर user के लिए guess नहीं कर रहे — platform खुद applicability बता देता है।
“September में mandatory” वाली headlines क्या गलत कहती हैं
यहाँ precise होना ज़रूरी है, क्योंकि यह obligation कोई एक single global switch नहीं है, और “September में mandatory” कोई ऐसी phrase नहीं है जो Apple खुद इस्तेमाल करता है। असल में दो अलग चीज़ें चल रही हैं, और coverage अक्सर इन्हें एक ही deadline में collapse कर देती है।
पहली चीज़ है App Store review gate। Apple लगातार यह सख्त करता जा रहा है कि आपकी privacy documentation और age handling क्या दिखाना चाहिए, और social या user-generated-content features वाली apps से expect किया जाता है कि वे Declared Age Range API पर based एक user-facing age gate implement करें। यह पूरे iOS 27 cycle में धीरे-धीरे सख्त होता है, किसी एक date पर switch नहीं होता — लेकिन अगर आपकी app में social features हैं, तो इसे अपने next release से पहले खत्म करने वाला काम मानिए, बाद का नहीं।
दूसरी चीज़, जिसकी hard dates हैं, वह है regional law, और यह कई जगहों पर already live है। Apple खुद Declared Age Range obligations को specific jurisdictions से जोड़ता है: Utah में नए Apple Accounts के लिए age categories 6 मई 2026 से और Louisiana में 1 जुलाई 2026 से share की जा रही हैं, और Apple ने Australia, Brazil और Singapore में 18+ downloads block करना 24 फरवरी 2026 से शुरू किया। बाकी laws अपने-अपने timelines पर हैं, कुछ पहले से in force, कुछ move हो चुके। System के regulatory signals इसलिए exist करते हैं क्योंकि “क्या मुझे यह इस user के लिए करना है” का जवाब उसके region और वहाँ के law की current state पर depend करता है।
Practical reading यह है: अगर आपके पास social या UGC features हैं, या आप किसी भी regulated region में minors से data collect करते हैं, तो यह live work है, future item नहीं। अगर आप पर दोनों में से कोई भी अभी apply नहीं होता, तब भी privacy documentation को current रखना expected है, और regional map बढ़ता जा रहा है — तो capability अभी build करना बाद में deadline के pressure में retrofit करने से सस्ता है।
यह marketing पर क्यों आ टिकता है, सिर्फ legal पर क्यों नहीं
Age assurance एक legal-and-engineering task जैसा लगता है, जब तक आप यह track नहीं करते कि यह touch कहाँ-कहाँ करता है। फिर यह सीधे आपकी tracking और segmentation पर आ जाता है।
अगर आप advertising identifiers collect करते हैं, automatic behavioral events fire करते हैं, या in-app activity पर segments बनाते हैं, तो एक age signal यह बदल देता है कि आप क्या collect कर सकते हैं और किसके बारे में। किसी protected age band के user को आप चुपचाप उसी behavioral tracking और ad-ID collection में शामिल नहीं कर सकते जिसमें एक adult को करते हैं। जिस moment OS आपको बता सकता है कि किसी regulated region में एक user minor है, “हम सबको एक ही तरह track करते हैं” defensible default नहीं रह जाता।
यह वो moment भी है जब बहुत सी apps जो gap साथ लेकर चलती हैं उसे close किया जाए: advertising IDs (iOS पर IDFA, Android पर GAID) का unclear या undocumented handling। अगर आपकी data documentation clearly नहीं बताती कि आप कौन-से advertising identifiers collect करते हैं और क्यों, तो यह gap पहले से ही एक liability थी। जैसे-जैसे review gate iOS 27 cycle में सख्त होता है, यह rejection risk बन जाता है। Age-collection story और ad-ID documentation दोनों को एक ही साथ fix करना efficient move है, क्योंकि दोनों एक ही privacy disclosures में रहते हैं।
आपकी compliance checklist
अपने legal और engineering partners के साथ यह काम करें:
- मैप करें कि आपके minors कहाँ हैं। पहचानें कि आप किन regions में operate करते हैं जहाँ live age-assurance laws हैं, और क्या आपकी app में social या UGC features हैं जो region चाहे जो हो, App Store gate trigger करते हैं।
- Applicability signals अपनाएं। अपनी guesswork build करने के बजाय, उन OS signals का इस्तेमाल करें जो बताते हैं कि किसी given user पर age obligations apply होती हैं या नहीं। Platform को यह बताने दें कि age range या consent कब request करनी है।
- Age range request करें, birthdate नहीं। जहाँ आपको age signal चाहिए, वहाँ Declared Age Range API इस्तेमाल करें ताकि आपको एक band मिले और आप कभी ऐसी birthdate collect या store न करें जिसे आपको बाद में protect करना पड़े।
- Significant changes के लिए parental consent wire up करें। अगर minors आपकी app इस्तेमाल करते हैं, तो सुनिश्चित करें कि जिन regions को इसकी ज़रूरत है वहाँ significant-change consent flow ready है।
- Age band के हिसाब से tracking segment करें। सुनिश्चित करें कि protected age bands में users को उस advertising-ID collection और behavioral tracking से exclude किया जाए जो minors के लिए permitted नहीं है। यह एक data collection और consent configuration है, हर user की manual review नहीं।
- अपनी privacy documentation update करें। अपने App Store privacy disclosures को current लाएं, और साथ ही advertising-ID documentation gap भी close करें ताकि IDFA और GAID handling clearly stated हो। Review gate सबसे पहले यही check करता है।
- अपनी consent copy review करें। सुनिश्चित करें कि minor या guardian को दिखने वाली consent language वही है जो आप actually collect करते हैं, बिल्कुल उसी spirit में जैसे आपकी GDPR consent practices।
Pushwoosh के साथ age-aware data collection को clean रखें
Pushwoosh आपको consent management और data-collection controls देता है ताकि आप tracking को age band के हिसाब से segment कर सकें, protected users को उस collection से exclude कर सकें जिसमें वे नहीं होने चाहिए, और अपनी advertising-ID handling documented और clean रख सकें। Pushwoosh SOC 2 Type I और ISO 27001:2022 certified है, GDPR और HIPAA compliant है, और EU व US में data centers operate करता है — enterprise-grade security, हर plan में। Compliance work कभी zero effort नहीं होता, लेकिन data वाला हिस्सा उसका सबसे hard part नहीं होना चाहिए।
