I’m hoping to get some insight from Apple engineers or developers who have seen similar behavior. Background We previously had a React Native / Expo iOS app in production for several years. Recently, we rebuilt the app completely from scratch as a native SwiftUI app using WKWebView (no shared code, no RN runtime). The new app architecture is: Native SwiftUI container WKWebView loading a remote web app Firebase Analytics & Crashlytics Push notifications (APNs + FCM) No local database, no persistent native state Migration scenario Users update the app via the App Store: Old app: React Native / Expo New app: native SwiftUI + WKWebView For most users, the migration works fine. However, for a about 10% of users, the following happens: The issue After updating from the old React Native app to the new SwiftUI app: The app opens The native landing screen appears (solid black OR blue background, depending on which most recent version if being installed) The app never transitions to the WKWebView No crash Force-quitting does not help Deleting the app completely and reinstalling does fix it 9/10 times, but NOT ALWAYS. From the user’s perspective: “The app is stuck on a black OR blue screen forever.” Important detail Most of the times, a full uninstall + reinstall FIXES the issue, but funny enough, NOT always.. In some cases, the issue persists: What we’ve already tried Over the last weeks, multiple iOS developers have investigated this. We have implemented and/or tested: Full rebuild in SwiftUI (no RN remnants) Aggressive cleanup on first launch after update: -- UserDefaults cleanup -- WKWebsiteDataStore cleanup -- URLCache / cookies cleanup Timeouts and fallbacks so the UI never blocks indefinitely Explicit logging of: -- app_open -- session_start -- webview_init -- webview_load_start / finish -- blank screen detection Handling: -- WKWebView content process terminated -- network / TLS / DNS errors Added a native SwiftUI landing screen (in the latest version) so users no longer see a black screen, but now they see a BLUE screen when the transition fails Observations from Analytics & Crashlytics No native crashes Very high user engagement (~99%) Very low blank-screen detection (~1–2%) The issue does not appear to be mass-scale But support still receives complaints daily from affected users This suggests a device / iOS / network-specific edge case, not a general migration failure. Hypotheses (not confirmed) We suspect one of the following, but haven’t been able to prove it: WKWebView failing to initialize under specific conditions after App Store updates TLS / ATS / CDN edge behavior affecting first WKWebView load iOS lifecycle timing issue when transitioning from SwiftUI landing view to WKWebView OS-specific WebKit state that survives reinstall (keychain? system WebKit state?) ISP / DNS / IPv6-related issues on first launch What we’re looking for We would really appreciate insight on: Are there known cases where WKWebView fails silently after an App Store update, even after reinstall? Is there any system-level WebKit state that survives app deletion? Are there best practices for transitioning from a SwiftUI landing view to WKWebView to avoid dead-ends? Any known iOS versions / device classes where this behavior is more common? Any debugging techniques beyond Crashlytics / Analytics that could surface what WebKit is failing on? We’re not looking for generic “clear cache” advice — we’ve already gone far down that path. We’re trying to understand whether this is a known WebKit edge case or something we are fundamentally missing. Thanks in advance for any pointers or shared experiences.

Hi, hope you're all doing well. I have a real brain-cracker here... Have been looking into this for the past 20 hours, but can't figure it out. We built an iPhone app that essentially functions as a shell around a PWA Web-App using WebView. The tricky part here to set things up was getting the Push Notifications to work. Eventually we got this working though (with help of Firebase), and the app has been working great for the past 7 months. Now, all of a sudden as it seems, when users first open up the app, there's no FCM token generated and passed on to the WebView instance running javascript. Or at least, the listening event ('push-token') no longer gets fired. Users who already have their FCM token generated and stored earlier on, receive push notifications without any issues. It's just that no new FCM tokens seem to be generated - or at least no longer passed to the WebView's javascript code. I know this for a fact as my tests turn out that the following event (present in my PWA Web-App JS code) no longer gets fired. Again, this worked fine before. I have NOT updated the native app since 6-7 months. `/* LISTEN FOR FCM (PUSH MESSAGES) TOKEN FROM NATIVE (IOS) SHELL: */ window.addEventListener('push-token', function(event) { //alert("Push Token registration event called from native shell"); if (event && event.detail) { var token = event.detail; window.fcmPushMessageToken = token; localStorage.setItem('fcmPushMessageToken', token); //alert("Received FCM token: " + token); registerDeviceForPushMessages(); } });` Hereé the part in my native iOS code that used to call this event from within the native iOS shell: func handleFCMToken(){ DispatchQueue.main.async(execute: { Messaging.messaging().token { token, error in if let error = error { print("Error fetching FCM registration token: \(error)") checkViewAndEvaluate(event: "push-token", detail: "ERROR GET TOKEN") } else if let token = token { print("FCM registration token: \(token)") checkViewAndEvaluate(event: "push-token", detail: "'\(token)'") } } }) } func checkViewAndEvaluate(event: String, detail: String) { if (!EPDriversApp2.WebView.isHidden && !EPDriversApp2.WebView.isLoading ) { DispatchQueue.main.async(execute: { EPDriversApp2.WebView.evaluateJavaScript("this.dispatchEvent(new CustomEvent('\(event)', { detail: \(detail) }))") }) } else { DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { checkViewAndEvaluate(event: event, detail: detail) } } } Again, I have not updated the native iOS app OR the WebApp's code. This just stopped functioning all of a sudden. One "weird" thing I noticed that there's no Provisiong Profile associated with the app. I'm not sure whether this was ever the case before, to be honest. Is this even mandatory? Can not having a Provisiong Profile associated with the app effect the ability of an already pusblished app for generating Push Notification tokens?