Mobile storage debugging: why cookies vanish and localStorage empties

In mobile H5 and WebView development, storage problems are a frequent cause of strange user-facing behaviour. Whether it is a lost cookie making the login state disappear over and over, or localStorage / IndexedDB being wiped so the cache stops working, the effect on stability is serious.

Storage debugging is harder on mobile than on the desktop: different systems and different WebView engines support storage differently and apply different persistence policies. This article works through a real case, compares Safari Web Inspector, Chrome DevTools and WebDebugX, and sums up what works for a cross-platform team.

1. The common kinds of storage problem

1. Lost cookies
   • Common in the iOS WKWebView, caused by the SameSite policy or a missing Domain
   • Requests to another subdomain do not carry the cookie, so the login state is lost
2. localStorage that does not persist
   • By default the iOS WKWebView keeps it in memory only; it disappears when the page closes or the app is backgrounded
   • Android usually persists it to disk, so it is comparatively stable
3. sessionStorage oddities
   • Lost on reload or cross-document navigation; some containers reload in ways that differ from the standard
4. IndexedDB data loss
   • The quota is small, and writes fail once it is exceeded
   • On low battery or under memory pressure, the system may clear it automatically
5. Storage isolated per domain
   • Storage is isolated between subdomains and cannot be shared
   • Particularly damaging for single sign-on

2. A real case: the login that kept disappearing in an iOS WebView

An e-commerce app embedded H5 pages, and users were constantly asked to log in again.

How it was debugged

1. Checking the request headers in WebDebugX showed the sessionid cookie was not being sent
2. The storage panel in Safari Web Inspector showed the cookie had been written — but scoped to login.example.com, so it was invisible on shop.example.com
3. Looking at localStorage next showed the data was wiped once the WKWebView page closed
4. The fix: the backend changed the cookie to Domain=.example.com, and the front end stored a fallback token in localStorage where it needed one

The result

Afterwards the cookie was shared across subdomains, localStorage persisted more reliably, and the login state stopped disappearing.

3. The tools compared

1. Safari Web Inspector

Strengths

• Apple’s own tool for iOS, and complete
• View and edit cookies, localStorage and IndexedDB visually
• Accurate for verifying persistence behaviour

Weaknesses

• Requires a Mac and a direct USB connection
• No remote or collaborative use

Ease of use: ★★★★☆ — essential for iOS developers.

2. Chrome DevTools

Strengths

• The most complete option on Android
• Clear storage panel; IndexedDB snapshots can be exported
• Clean interface, low learning curve

Weaknesses

• Cannot debug an iOS WebView
• Limited support for WebView-specific quirks

Ease of use: ★★★★★ — the tool front-end developers know best.

3. WebDebugX

Strengths

• Cross-platform (Win / Mac / Linux + iOS / Android)
• Remote debugging, no direct USB connection needed
• Import, export, clear and simulate cookies, localStorage and IndexedDB
• Good for front-end and QA teams reproducing a scenario

Weaknesses

• Deep heap snapshots and engine-level debugging are less capable than the first-party tools
• Needs initial setup

Ease of use: ★★★★★ — the first choice for a cross-platform team.

4. Comparison table

Tool	Platforms	Feature coverage	Ease of use	Best for
Safari Web Inspector	Mac + iOS	★★★★★	★★★★☆	iOS storage debugging
Chrome DevTools	Win / Mac / Linux + Android	★★★★★	★★★★★	Android storage debugging
WebDebugX	Win / Mac / Linux + iOS / Android	★★★★☆	★★★★★	Cross-platform work and remote debugging

5. Best practice: the full debugging flow

1. First pass: use WebDebugX to check request headers and what is actually written to storage
2. Deep iOS analysis: confirm cookie attributes and localStorage persistence in Safari Web Inspector
3. Android verification: check reads and writes with Chrome DevTools
4. Across teams: use WebDebugX’s import / export to share a storage state and reproduce the problem quickly

6. What we learned

1. Storage is a common root cause behind lost logins and broken caching.
2. Safari Web Inspector and Chrome DevTools are each the strongest on their own platform, but neither covers both.
3. WebDebugX bridges the gap, solving remote debugging and team collaboration.
4. Recommended combination: first-party tools for deep verification, WebDebugX for day-to-day and cross-team debugging.

In mobile H5 development, storage debugging is what keeps the experience stable. Use Safari Web Inspector, Chrome DevTools and WebDebugX according to the platform differences, and build a storage debugging flow the whole team can work in — that is what actually eliminates “the login disappeared” and “the cache is gone”.