Safari Deletes Your Player After Seven Days. Your Portal Calls Them a New Visitor.

Safari wipes script-written browser storage after seven days without interaction. For a games portal, that turns saved progress and loyal players into nothing. The industry spent five years bracing for third-party cookie deprecation and never noticed that first-party persistence — the thing portal retention actually runs on — had already been quietly capped.

Ask most portal operators where a guest player's progress lives and you will get a shrug and the word "localStorage". Ask them what their seven-day return rate is and they will read you a number off an analytics dashboard. Those two answers are connected, and not in a good way: on a large share of their traffic, the second number is measuring the first one's expiry date.

This is not a privacy-compliance post. Consent, COPPA and the rest are separate problems. This is about a technical constraint that sits underneath retention reporting, save systems, ad frequency capping and login design, and that almost nobody prices in when they buy a catalogue and plan the traffic around it.

🍪 The Deprecation That Never Came, and the One That Already Did

On 17 October 2025, Google announced it was retiring most of Privacy Sandbox. Anthony Chavez, VP of Privacy Sandbox, wrote that after weighing ecosystem feedback and adoption, Google had decided to retire ten technologies — Topics, Protected Audience, Attribution Reporting, Private Aggregation, Related Website Sets, SDK Runtime and others. In the same post Google confirmed it would "maintain our current approach to offering users third-party cookie choice in Chrome." CHIPS and FedCM survived. Google's own Privacy Sandbox status page, last updated 14 August 2026, now tracks those APIs through deprecation and removal.

Adtech read this as a reprieve. For anyone running a games portal, it was mostly irrelevant. Third-party cookies were never what held a returning player's save file. That job belongs to first-party storage — localStorage, IndexedDB, a first-party cookie — and the restrictions on that shipped years ago, took effect without a countdown clock, and are still in force.

⏳ What Safari Actually Deletes, and When

WebKit's own engineering post on full third-party cookie blocking spells it out: Intelligent Tracking Prevention deletes "all of a website's script-writable storage after seven days of Safari use without user interaction on the site." The list of what goes is longer than most developers expect:

• IndexedDB
• LocalStorage
• SessionStorage
• Media keys
• Service Worker registrations and cache

Two details in that sentence do real damage. The first is "seven days of Safari use" — not seven calendar days. The counter tracks days the browser was used at all, so a player who opens Safari daily but does not visit your portal burns through the window in a week. The second is Service Worker registrations and cache. If you built offline play or a precached asset bundle on a service worker, that is in the deletion set too.

The obvious developer instinct is to reach for navigator.storage.persist(). It does not help here. MDN's reference on storage quotas and eviction notes that Safari's seven-day inactivity rule applies regardless of whether the origin is best-effort or persistent. MDN also records the one carve-out worth knowing: server-set cookies are preserved. Cookies written by a script are not the same thing as cookies written by a Set-Cookie response header, and on WebKit the difference decides whether your identifier survives the month.

📱 Half of North American Mobile Runs on This Browser

Operators tend to wave this away as an iOS edge case. Check the split before you do. StatCounter's July 2026 figures put Safari at 25.44% of worldwide mobile browser sessions, against Chrome's 66.79% and Samsung Internet's 2.48%. A quarter of global mobile is already a large hole to have in your retention data.

Regionally it stops being a hole and becomes the floor. In North America for the same month, StatCounter has Safari at 49.3% of mobile sessions and Chrome at 45.07%. If your portal's audience skews to the US or Canada, roughly half your mobile players are on a browser that will delete their progress and their identifier after a week away — and the players most likely to hit that threshold are precisely the lapsed ones you were hoping to win back.

Chrome forgets too, just more slowly

Chrome has no inactivity timer, but it is not a filing cabinet either. Per MDN, default storage is "best-effort": under storage pressure the browser evicts origins on a least-recently-used basis, and eviction is all-or-nothing — IndexedDB, Cache API and OPFS data for that origin go together, deliberately, to avoid leaving an app in an inconsistent half-state. Chrome and Safari also auto-decide persistence requests based on interaction history rather than prompting the user, so you cannot reliably opt in. MDN's own assessment is that browsers rarely evict data from regularly visited sites. That is reassuring right up until you remember which cohort you are trying to measure.

🎮 What the Large Portals Already Built Instead

The most useful evidence that this is a real operating problem is that the two biggest western web games platforms both solved it, independently, the same way — by treating browser storage as a cache and the server as the record.

CrazyGames runs an Automatic Progress Save system that backs up and restores window.localStorage for authenticated players with no developer implementation at all, syncing across devices; Unity builds get the same treatment via PlayerPrefs through IndexedDB. There is a hard restriction attached — the documentation states it is not permitted for games with in-game purchases, which are pushed toward a stricter account-linked path instead.

Poki's HTML5 SDK does the equivalent for logged-in players: it monitors localStorage and IndexedDB for changes and syncs them to the cloud transparently, throttled to limit network chatter, with a poki_ignore key prefix for caches and analytics buffers that should not travel between devices. It also publishes the ceiling — the gamesave payload must not exceed 1MB after gzip compression, and a player who exceeds it has cloud saves automatically disabled.

The most instructive line of all is in the CrazyGames account integration requirements, which cite over 35 million active players. Games "should always allow the user to start playing as Guest" — no login wall in front of the first play. But developers are explicitly warned off using localStorage to identify a guest across sessions, on the grounds that multiple people share a device. The guidance is to link guest progress to an account when the player eventually logs in.

That is the whole architecture in two sentences: never gate the first play, never trust the device as an identity. Everything else is implementation.

📲 The Home-Screen Install Is Not the Escape Hatch

The standard rebuttal is that installed web apps are exempt, so push the install prompt and move on. Be careful with that plan.

Push notifications on iOS do require it. Per WebKit's own announcement of web push for web apps on iOS and iPadOS, it works only for web apps added to the Home Screen, and permission must be requested from a direct user gesture inside the installed app. An open Safari tab cannot ask. So if web push is part of your re-engagement plan, the install is a prerequisite, not an optimisation.

The storage exemption is shakier ground. When the seven-day cap arrived, home-screen web apps sat outside Safari and kept their own usage counter, which was widely read as an exemption. Whether that still holds is genuinely contested — Apple's developer forums carry recurring reports of installed web app data disappearing after long idle periods, and the EU regulatory detour around home-screen web apps muddied the picture further. There is no current WebKit document that guarantees it. Treat an undocumented, disputed carve-out as what it is: not an architecture. Build the server-side save, then treat the install as a bonus that improves the experience rather than the thing holding your data up.

📊 Your Retention Chart May Be Measuring the Browser

Here is where this stops being a developer problem and becomes a commercial one. If your returning-player metric is keyed on an identifier written by a script into localStorage, then on WebKit traffic your measurable seven-day return window is capped by the platform, not by your catalogue. Every player who comes back on day nine is a fresh install of a stranger.

That distortion runs in one direction, and it is the expensive direction:

• New-user counts inflate. The same human is counted repeatedly. Your acquisition looks healthier than it is.
• Retention curves flatten early and stay flat. Long-tail return traffic is misfiled as new, so the shape of the curve tells you nothing about whether the games are sticky.
• Channel comparisons break. A channel that delivers iOS-heavy traffic will look worse on retention and better on new users than an Android-heavy channel delivering identical humans.
• Frequency capping leaks. Ad frequency caps and session-based interstitial pacing built on script storage silently reset, which affects the player experience and your quality scores before it affects revenue.
• You buy the wrong catalogue. If retention is the number you use to judge which licensed titles to renew, and that number is partly an artefact of browser policy, you are renewing on noise.

The fix for measurement is not the same as the fix for saves. Server-side event collection with a first-party, server-set cookie gives you a durable analytics identity even when the game's own client-side save is gone. They are two separate pieces of work, and portals routinely do neither.

🚫 Five Ways Portals Build This Wrong

1. Treating a localStorage UUID as a user ID. It is a device-and-browser-and-recency key. It is shared between household members, it disappears on WebKit after a quiet week, and it is destroyed by any privacy sweep the player runs. Fine as a cache key, useless as identity.
2. Putting the login wall before the first play. The one thing both major platforms insist on is that guest play works immediately. A registration gate in front of a free casual game does not convert; it just removes the session that would have earned you the right to ask.
3. Overwriting on login instead of merging. A guest plays for two weeks, then signs in, and the empty server record clobbers the local one. This is the single most common way portals destroy the progress they just spent effort persuading players to protect — and the player who loses a save on login does not sign in again.
4. Syncing everything, then hitting the ceiling. Poki disables cloud saves for players who exceed 1MB gzipped. If you bundle analytics buffers, asset caches or replay data into the same keyspace as the save, you will cross that line on your most engaged players first. Namespace what travels and what doesn't.
5. Buying traffic against retention numbers you never validated. Before you use a return-rate figure to justify spend, segment it by browser. If Safari's curve differs sharply from Chrome's on the same catalogue and the same acquisition source, you are looking at storage policy, not player behaviour.

🎮 Where a Licensed Catalogue Fits

Persistence is a portal-layer responsibility, not something you can buy per title — but it does belong in title-level due diligence, because how a game writes its save data determines whether your account layer can capture it at all. A game that writes to localStorage under predictable keys can be synced generically, the way CrazyGames and Poki do it. A game that writes to IndexedDB under randomised keys, or holds progress only in memory, cannot.

So the question to put to any licensor alongside price and territory is a technical one: what does each title write, where does it write it, and can the keys be namespaced? Forestry Games has licensed HTML5 games and Android titles since 2017 across a catalogue of 1,049 games, and that question is answerable per title in a way that a scraped or aggregated catalogue usually is not. If you are building a white-label portal or running a subscription games portal where a returning player is the entire business model, ask it before you sign, not after your first retention review.

🧭 What to Do This Quarter

Four things, in order of how cheap they are relative to what they tell you:

1. Segment your retention report by browser family. One afternoon of analytics work. If WebKit traffic shows a return curve that dies at day seven while Chrome's does not, you have confirmed the problem in your own data and can stop arguing about it.
2. Move your analytics identifier to a server-set first-party cookie. This is the smallest change with the largest reporting payoff, and it is independent of anything you do to game saves.
3. Audit what your licensed titles actually write. Load each one, watch the storage panel, and record the keys. You cannot build a sync layer over a catalogue you have not inventoried.
4. Ship guest-to-account merging before you ship the login prompt. Merge logic is the part that breaks, and shipping the prompt first means discovering the bug on real players' save files.

None of this makes your games better. It makes the difference between a portal that knows whether its games are good and one that has been reading a browser policy off a chart and calling it player behaviour. If you are weighing how a returning audience turns into revenue, that argument starts with monetization — but it does not start until the returning audience is something you can actually see.