Apple cookie error

Hi everyone,

We are currently experiencing a strange issue with our PWA on iOS and I wanted to ask if anyone has seen something similar before. Setup

Around 1,200 active users

ASP.NET backend/server

PWA hosted on a subdomain: user.PLACEHOLDER.de

The app has two main areas:

    User area: /User

    Admin area: /Customers

Most users install the PWA normally through Safari using “Add to Home Screen”. The Problem

The issue only happens on iOS when the app is installed as a real PWA.

Steps to reproduce:

Admin opens the installed PWA

Admin navigates to the admin section (/Customers)

Admin closes the PWA while still being inside /Customers

When the admin reopens the app, the entire app is broken and nothing works anymore

However:

If the admin navigates back to the normal user area (/User) BEFORE closing the app, everything works fine

The issue only happens if the app is closed while inside /Customers

At this point, the only fix is:

uninstall the PWA

reinstall it

login again

The Weird Part

If the user only adds the website icon to the home screen WITHOUT installing it as a standalone PWA, everything works perfectly.

So the issue seems to happen specifically in iOS standalone PWA mode. Additional Notes

Only happens on Apple/iOS devices

    After latest IOS-Update

Android works perfectly

Has anyone experienced something similar or knows what could cause this behavior? The cookie settings in ASP.NET:

options.Cookie.Domain = ".PLACEHOLDER.de";

options.Cookie.IsEssential = true;

options.Cookie.HttpOnly = true;

options.Cookie.SameSite = SameSiteMode.None;

options.Cookie.Path = "/";

options.Cookie.Name = ".AspNet.SharedCookie";

options.Cookie.SecurePolicy = CookieSecurePolicy.Always;

EDIT:

I currently suspect that the issue is related to cookies/session handling, but I’m not sure. Unfortunately we cannot properly debug iOS because we only have Windows devices available.

The mainfest.json:

{ "manifest_version": 3, "name": "Name", "short_name": "Name", "description": "Buchen von Kursen", "icons": [ { "src": "/images/192x192.png", "sizes": "192x192" }, { "src": "/images/512x512.png", "sizes": "512x512" } ], "display": "standalone", "start_url": "https://user.PLACEHOLDER.de/User", "scope":"/", "content_scripts": [ { "js": [ "service-worker.js" ] } ]

}

Answered by DTS Engineer in 888082022

Thanks for the detailed reproduction. Before chasing the cookie theory, there are a few issues in your manifest.json that are likely contributing to what you're seeing. The manifest mixes Web App Manifest fields with Chrome Extension manifest v3 fields, which can leave your service worker completely unregistered in standalone PWA mode — and that alone can produce the kind of "broken on relaunch" behavior you're describing in iOS.

Manifest issues:

  • "manifest_version": 3 is a Chrome Extension field; Web App Manifests don't have it. Remove it.
  • "content_scripts": [{ "js": ["service-worker.js"] }] is also Chrome Extension syntax. Web App Manifests don't register service workers — you register them from JavaScript:
if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/service-worker.js', { scope: '/' });
}

After fixing the manifest and adding the registration call, you can confirm the service worker is active in Safari Web Inspector under Storage → Service Workers.

About debugging on iOS:

You won't get far without Safari Web Inspector, which only runs on the Mac. There's no Windows path. To make progress, you'll need access to at least one Mac — even a borrowed or cloud-rented one — connected to your iOS device via USB, with "Web Inspector" enabled on the iPhone (Settings → Safari → Advanced). From Safari on the Mac, choose Develop → [Your iPhone] → [the PWA] to attach. With the inspector attached during a reproduction, you can see the cookie store, service worker state, and any redirects fire as the bug happens. Without it, diagnosing this is mostly guesswork.

Suggested order:

  1. Fix the manifest, deploy, and confirm the service worker registers.
  2. With Web Inspector attached on a Mac, reproduce the close-from-/Customers path. Watch your auth cookie, SW state, and any navigation on relaunch.
  3. If it still reproduces with a clean manifest and an active service worker, file a Feedback Report at https://feedbackassistant.apple.com against Safari/WebKit, including the iOS version, exact steps, and the network trace.

A couple of smaller observations:

  • Domain = ".PLACEHOLDER.de" with the leading dot is legal but unusual for a single-subdomain deployment. If everything lives under user.PLACEHOLDER.de, you can drop the Domain attribute entirely and let the cookie default to host-only.
  • start_url: "/User" combined with closing the PWA inside /Customers means iOS may be relaunching at /User rather than restoring /Customers. If /User does anything during page load that interacts with the session, that's worth investigating.

Thanks for the detailed reproduction. Before chasing the cookie theory, there are a few issues in your manifest.json that are likely contributing to what you're seeing. The manifest mixes Web App Manifest fields with Chrome Extension manifest v3 fields, which can leave your service worker completely unregistered in standalone PWA mode — and that alone can produce the kind of "broken on relaunch" behavior you're describing in iOS.

Manifest issues:

  • "manifest_version": 3 is a Chrome Extension field; Web App Manifests don't have it. Remove it.
  • "content_scripts": [{ "js": ["service-worker.js"] }] is also Chrome Extension syntax. Web App Manifests don't register service workers — you register them from JavaScript:
if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/service-worker.js', { scope: '/' });
}

After fixing the manifest and adding the registration call, you can confirm the service worker is active in Safari Web Inspector under Storage → Service Workers.

About debugging on iOS:

You won't get far without Safari Web Inspector, which only runs on the Mac. There's no Windows path. To make progress, you'll need access to at least one Mac — even a borrowed or cloud-rented one — connected to your iOS device via USB, with "Web Inspector" enabled on the iPhone (Settings → Safari → Advanced). From Safari on the Mac, choose Develop → [Your iPhone] → [the PWA] to attach. With the inspector attached during a reproduction, you can see the cookie store, service worker state, and any redirects fire as the bug happens. Without it, diagnosing this is mostly guesswork.

Suggested order:

  1. Fix the manifest, deploy, and confirm the service worker registers.
  2. With Web Inspector attached on a Mac, reproduce the close-from-/Customers path. Watch your auth cookie, SW state, and any navigation on relaunch.
  3. If it still reproduces with a clean manifest and an active service worker, file a Feedback Report at https://feedbackassistant.apple.com against Safari/WebKit, including the iOS version, exact steps, and the network trace.

A couple of smaller observations:

  • Domain = ".PLACEHOLDER.de" with the leading dot is legal but unusual for a single-subdomain deployment. If everything lives under user.PLACEHOLDER.de, you can drop the Domain attribute entirely and let the cookie default to host-only.
  • start_url: "/User" combined with closing the PWA inside /Customers means iOS may be relaunching at /User rather than restoring /Customers. If /User does anything during page load that interacts with the session, that's worth investigating.
Apple cookie error
 
 
Q