अगर आप अपनी app को iOS 27 SDK के against build करते हैं और UIScene lifecycle adopt नहीं करते, तो app launch ही नहीं होगी। और जो app launch नहीं होती, वो कभी push के लिए register भी नहीं करती — तो आपकी notifications बिना किसी crash report के silently बंद हो जाती हैं, जो push को कारण बताए। Symptom देखने में delivery का problem लगता है। असल में ये एक launch problem है।

ये गड़बड़ ज़्यादातर टीमों को off-guard पकड़ती है, क्योंकि push और app startup आपके codebase में और आपके दिमाग में भी बिल्कुल अलग कोने में रहते हैं। iOS 27 इन दोनों को जोड़ देता है। ये guide कवर करती है कि exactly क्या टूटता है, वो exact chain जो आपकी notifications silent करती है, कौन blast radius में है, और fix के लिए migration checklist। Pushwoosh एक customer engagement platform है, और इसका iOS SDK पहले से इस transition को handle कर रहा है, लेकिन नीचे दिया गया fix applicable है चाहे आप हमें use करें या ना करें।

📖

ये हमारे iOS 27 release guide का हिस्सा है। जब तक SDK का काम open है, अपना actual device reach भी check कर लीजिए।

असल में टूटता क्या है

Apple ने WWDC25 में announce किया था कि iOS 26 के बाद वाला release, latest SDK से बनी किसी भी UIKit app के लिए UIScene lifecycle require करेगा। iOS 27 वही release है। ये requirement अब enforce हो रहा है।

Trigger matter करता है, और ज़्यादातर panicked threads यहीं गलत समझते हैं: enforcement तब होता है जब आप Xcode 27 में iOS 27 SDK के against build करते हैं, ना कि सिर्फ तब जब कोई user आपकी existing app को iOS 27 पर run करता है। आपकी currently shipped build updated phones पर काम करती रहेगी। Break आपके next release के साथ आएगा, जो new SDK पर compile हुआ है। ये distinction आपको time देता है, लेकिन सिर्फ आपके next submission तक।

ये है जो change नहीं होता, और यहीं scare वाले articles ज़्यादा बोल देते हैं: APNs flow खुद untouched है। आप अब भी authorization request करते हैं, अब भी registerForRemoteNotifications() call करते हैं, और अब भी didRegisterForRemoteNotificationsWithDeviceToken में device token receive करते हैं। वो callback आपके AppDelegate में ही रहता है, और iOS 27 पर फिलहाल कोई scene-based equivalent नहीं है जहाँ इसे move किया जा सके। Push mechanics बिल्कुल fine हैं। Apple ने startup को change किया है।

वो chain जो आपका push silent करती है

जब scene manifest के बिना कोई app iOS 27 SDK के against build होती है, तो failure इस order में चलती है:

  1. UIKit launch पर scene adoption assert करता है और आपके Info.plist में कोई UIApplicationSceneManifest नहीं मिलता।
  2. AppDelegate का कोई भी method run होने से पहले ही app terminate हो जाती है।
  3. चूंकि application(_:didFinishLaunchingWithOptions:) कभी execute ही नहीं होता, registerForRemoteNotifications() कभी fire नहीं होता।
  4. Registration ना होने से didRegisterForRemoteNotificationsWithDeviceToken कभी call नहीं होता, तो app को कभी APNs token नहीं मिलता।
  5. Token नहीं, delivery नहीं। और चूंकि app startup पर crash हुई थी, आपके logs launch को blame करते हैं, notification pipeline को नहीं।

ये इतना debugging time waste करता है क्योंकि symptom और cause एक-दूसरे से बहुत दूर बैठे हैं। आप missing deliveries देखते हैं और अपने push provider, payloads, certificates audit करना start कर देते हैं। असली fault 3 layers ऊपर है, एक manifest file में जिसका notifications से कोई लेना-देना नहीं।

Blast radius में कौन है

Requirement UIKit apps को hit करता है, लेकिन ये आप तक कैसे पहुँचता है, ये आपके stack पर depend करता है।

StackExposure
Native UIKitDirect. अगर आप AppDelegate lifecycle own करते हैं, तो migration भी आप ही own करते हैं।
SwiftUIअगर आप App protocol और WindowGroup use करते हैं, जो पहले से scene-based हैं, तो risk कम है। जो apps अभी भी custom window logic वाले UIApplicationDelegateAdaptor पर depend करती हैं, उन्हें ध्यान से देखने की ज़रूरत है।
FlutterRecent versions पर framework unmodified AppDelegate वाली apps को auto-migrate करता है, लेकिन कोई भी custom native logic manually migrate करनी होगी।
React Nativeआपके native modules और किसी भी third-party SDK wrapper पर depend करता है जो AppDelegate को hook करता है।
Stack
1 / 4
Native UIKit
Exposure
Direct. अगर आप AppDelegate lifecycle own करते हैं, तो migration भी आप ही own करते हैं।
Stack
2 / 4
SwiftUI
Exposure
अगर आप App protocol और WindowGroup use करते हैं, जो पहले से scene-based हैं, तो risk कम है। जो apps अभी भी custom window logic वाले UIApplicationDelegateAdaptor पर depend करती हैं, उन्हें ध्यान से देखने की ज़रूरत है।
Stack
3 / 4
Flutter
Exposure
Recent versions पर framework unmodified AppDelegate वाली apps को auto-migrate करता है, लेकिन कोई भी custom native logic manually migrate करनी होगी।
Stack
4 / 4
React Native
Exposure
आपके native modules और किसी भी third-party SDK wrapper पर depend करता है जो AppDelegate को hook करता है।

Cross-platform teams के लिए sharp edge framework नहीं है, बल्कि उस पर layered SDKs हैं। कोई भी push या analytics SDK जो आपके AppDelegate को wrap करके खुद को install करता है, वो scene migration को तब तक block कर सकता है जब तक वो vendor scene support ship नहीं करता। अगर कोई dependency आपके @main entry point की owner है, तो आप उनके release का wait कर रहे हैं, सिर्फ अपने नहीं। हमने एक migration exactly इसी वजह से 2 हफ्ते तक stall होते देखा है — एक uncooperative dependency की वजह से, जबकि team जो कुछ actually control करती थी वो पहले ही ready था। Migration को same-day job मानने से पहले अपने notification SDK की scene compatibility check कर लीजिए। अगर आप हमारे Flutter plugin पर हैं, तो known migration issues page सबसे पहले पढ़ने वाली चीज़ है।

Migration checklist

Fix 2019 में scenes introduce होने के बाद से change नहीं हुआ है। जो change हुआ है वो ये कि ये optional नहीं रहा।

  • Scene manifest add करें। अपने Info.plist में एक UIApplicationSceneManifest डालें, या UIApplicationDelegate और UISceneDelegate methods के through code में scenes configure करें।
  • SceneDelegate create करें। अगर आपके पास नहीं है तो add करें और confirm करें कि वो actually आपके target में compile होता है। एक SceneDelegate जो project में exist करता है लेकिन कभी build sources में add नहीं हुआ, एक common trap है।
  • Window creation move करें। Window ownership AppDelegate से बाहर move होती है। UIWindow(frame:) को UIWindow(windowScene:) से replace करें और अपनी root view को scene से host करें।
  • UI lifecycle handling move करें। Foreground, background, और active/inactive transitions UISceneDelegate में move होते हैं। Migration के बाद, UIKit आपके AppDelegate पर UI-state methods call करना बंद कर देता है, तो जो भी वहाँ रह जाता है वो silently dead हो जाता है।
  • Push registration को जहाँ है वहीं रहने दें। Token registration और token callbacks AppDelegate में ही रहते हैं। Symmetry के पीछे भागकर इन्हें move मत कीजिए।
  • URL और deep-link handling migrate करें। Incoming URLs अब scene methods के through आते हैं। अगर push notifications specific screens open करती हैं, तो यही part है जो आपके deep links को working रखता है।
  • Rebuild करें और token issuance verify करें। iOS 27 SDK पर build करें, launch करें, और confirm करें कि app को APNs token मिलता है। अगर नहीं मिलता, तो iOS error troubleshooting guide से शुरू करें। Release से पहले real build पर verify करें, बाद में नहीं।

AppDelegate को रखें। यही वो point है जो teams miss कर देती हैं जब वो पढ़ती हैं “AppDelegate जा रहा है”। ये जा नहीं रहा। इसका role narrow होकर process और app-level events तक सीमित हो जाता है, जबकि UI lifecycle scene में move होता है। Push registration एक app-level concern है, और यही exact reason है कि ये अपनी जगह पर रहता है।

सिर्फ push पर depend करना क्यों fragile plan है

Fix से एक कदम पीछे हटकर देखिए। एक single manifest key, एक file में जो team में लगभग कोई नहीं खोलता, आपके पूरे push channel को अगले release में offline कर सकती है। एक delivery method पर इतनी सारी fragility ride कर रही है।

और ये push के पहले से existing ceiling के ऊपर आता है: opt-in। एक healthy prompt strategy के साथ भी, आपके users का एक बड़ा हिस्सा पहली बार में कभी push permission grant ही नहीं करता, तो एक अच्छे दिन पर भी push आपके base के सिर्फ एक fraction तक पहुँचता है। इस जैसे platform breaks सिर्फ उस gap को और widen करते हैं जो आप reach कर सकते हैं और जिन तक आप actually reach करते हैं, उनके बीच।

जो teams ऐसे changes को ride out करती हैं, वो वो होती हैं जो एक single channel पर depend नहीं करतीं। जब push, email, SMS, और in-app के साथ बस एक delivery method है, तो एक platform पर launch-time regression आपके पूरे reach को erase करने की बजाय सिर्फ dent करता है। आप exactly इसी तरह की surprise के लिए margin खरीद लेते हैं, जो Apple ने अभी ship की है।

👉🏻

जब तक SDK का काम open है, ये एक अच्छा moment है ये revisit करने का कि किसी notification को भेजने लायक क्या बनाता है

Pushwoosh के साथ अपना iOS 27 push setup check करवाएं

Pushwoosh SDK पहले से iOS 27 scene lifecycle को support करता है, और इसका multichannel setup मतलब है कि एक single-platform break कभी आपकी पूरी notification strategy को अपने साथ down नहीं ले जाता। अगर आप mid-migration हैं और कुछ register नहीं हो रहा, तो iOS SDK FAQ common snags cover करता है। और अगर आप चाहते हैं कि कोई second pair of eyes ये देखे कि आपका push registration इस move को survive करता है या नहीं, तो हम आपके साथ आपका integration walk कर सकते हैं — Android 95%+ market जैसे high-scale India apps के लिए भी।

अपना iOS 27 push setup check करवाएं
iOS 27 compatibility check करें

अक्सर पूछे जाने वाले सवाल

अपने आप नहीं। जो app पहले से App Store पर है, वो iOS 27 devices पर चलती रहेगी। Break तब होता है जब आप scene lifecycle adopt किए बिना iOS 27 SDK के against एक नया version build करते हैं, और वो build launch नहीं होगी। आपकी currently shipped build आपके next release तक safe है।

Pushwoosh Team
Content Team में Pushwoosh
शेयर करें

संबंधित लेख

सभी देखें