Ink offline — a tap never waits shipped · v1134–v1136

Short answer: Ink now works like the big news apps. Everything paints from the phone first and is refreshed behind the paint. The last three days — every story, its Background page, its comments, its pictures — are saved on the phone automatically whenever Ink opens or you pull down. A pull is the one gesture that asks the network first. A tap opens a story at once — from the phone, or, if it isn't there yet, with its headline and picture while the body arrives. Never a dead tap, never an endless spinner.

The list of the articles can read, but when I click on the first article, I cannot load the subpage of the full article, until I wait for a while. … Study how major news apps do the cache and preloading and give our users the best experience. — the owner, 2026-09-28

1 · What was wrong

Terms: the list = today's edition (edition.json, 17 KB) · a brief's body = the text of its page, kept in pegs files · the service worker = the app's small proxy on the phone that decides "phone copy or network" for every file.

BEFORE (v1134) AFTER (v1135) tap a brief → needs its body → in pegs.json: tap a brief → needs its body → in pegs-<day>.json: EVERY brief ever written (228 · 2.3 MB, only that edition's 16 (~150 KB), asked for as the ~0.5 MB compressed), fetched once per open; list paints, already on the phone after a sync; until it arrives the tap does NOTHING a tap that beats it opens at once and fills Ink's data = network first, up to 6 s wait phone first, refreshed behind; a new edition → on the China→Singapore link every open waited found behind → "Fresh Ink"; a PULL = network first (8 s), then the phone's copy comments failed once → "No comments yet" for the a failed load is not remembered — the next rest of the session open tries again offline sync: the 2.3 MB file + pictures, TEXT FIRST for all three days (list, bodies, in list order comments), then pictures, today's first

2 · What the major news apps do

A research pass on 09-28 (sources at the end). Engineering detail is thin for most apps — the patterns that recur are what matters; anything the vendor never published is marked unverified.

AppWhen it downloadsOffline experience
Apple NewsRecent + saved stories, automatically, on Wi-Fi while charging"No Internet Connection" banner; stories not downloaded are dimmed; a "Check for New Stories" pill when back online
New York TimesOvernight background updates so normal reads don't hit the network (its open-source Store library); duplicate requests merged into oneThe feed looks the same offline, with "last updated"; comments marked unavailable. A reviewer's complaint: an un-downloaded image spins forever
GuardianSections pre-cached (since its 2009 app); the daily Editions app downloads a bundleIts website's offline page offers a crossword instead of a dead end
Financial TimesOffline was opt-in (casual visitors don't pay the download)Its lesson: never trust the browser's "online" flag — trust whether the download worked
The EconomistThe whole weekly edition downloads as one unitWi-Fi-only setting and retention: unverified
BBC · Google NewsSaved items on Wi-Fi (BBC audio kept 30 days); Google downloads saved topicsThe feed itself doesn't work offline; pictures may be missing

The eight patterns that recur — and where Ink stands:

PatternInk
1Show the saved copy at once, refresh behind it — never block the reader on the network✓ v1135
2Don't swap the list under a finger — a "new stories" notice instead✓ repaints only at the top with nothing open; otherwise「Fresh Ink — pull down to see it」
3The edition is one downloadable unit, fetched before it's needed✓ every open and pull saves three days
4Text before pictures — pictures are what goes missing✓ v1135 sync order; the smaller picture first
5A tap on something missing fails clearly and at once✓ opens with the headline;「Couldn't load this story — it isn't saved on this phone yet」
6Offline is judged by real downloads, not the browser's flag✓ the service worker marks a phone-copy answer (X-Ink-Saved)
7Bounded storage✓ three days (~10 MB), the oldest pruned; the phone is asked to keep it
9A pull keeps spinning until the new stories are really loaded (the owner's catch, 09-28)✓ v1136 — the band holds a ring and「Refreshing…」until the day's text is on the phone (the list, every brief, the comments); pictures keep coming behind; capped at 20 s so a dead link lets go
8Bulk downloads on Wi-Fi, overnightnot possible for a web app on iPhone — see §4

3 · Ink's rules, per file

FileSizeServedOn the phone for offline
edition.json — the list (today's pointer)17 KBphone first, refreshed behind; changed → "Fresh Ink"; a pull → network first✓
edition-<day>.json17 KBphone first, refreshed behind (the comment faces land after publishing)✓ three days
pegs-<day>.json — the day's bodies (new)~150 KBphone first; asked for the moment the list paints✓ three days
voices/<id>.json — comments~11 KBphone first✓
img/<id>.m.jpg · .jpg — pictures100–300 KBphone first (written once)✓ both sizes, the small one first
pegs.json — every brief ever2.3 MBonly a fallback for a server without the day files✗ removed from the phone

The brew writes pegs-<day>.json beside the edition on every publish (both lines, and a Source-card refresh); the app cuts any missing ones at boot (day_pegs_backfill). The phone's copy lives in its own store (mad-ink-offline), so a new app version never clears it.

4 · What a web app cannot do (yet)

Overnight download. The native apps fetch the edition at night. A web app on iPhone gets no background time at all; Android's periodic background sync exists, but the browser decides when, and only for installed apps people use. So Ink's dependable moment is when the app opens or comes back — which is exactly when it saves. For a flight: open Ink once before boarding and check the line at the end of the list —「Saved on this phone · 3 days · 06:20」.

Storage. An installed web app on iPhone may use a large share of the disk, and the phone is asked to keep Ink's store; ~10 MB for three days is far below any limit.

5 · Measured (dev server, service worker on, 09-28)

CheckResult
the app's boot cuts the day files20 editions → 20 pegs-<day>.json
online: the first brief tappedthe full page (2,693 characters) — the 2.3 MB file never fetched
a tap that beats the loadopens at once with the headline + "Loading…", fills when the day arrives; a story with no body anywhere ends on the clear message
server killed, app reopenedlands on Ink · 12 stories · tap → the full body in 15 ms · picture · 3 comments

6 · Status

DateWhat
2026-09-28 · v1136the pull holds its ring. Before: the band snapped shut on release and nothing showed while the request ran. After: released → a spinner +「Refreshing…」→ closes when the three days' text is saved (measured locally: 19 text files in 215 ms, pictures 14 → 90 after). ⚠ caught in testing: the first draft broke an if … else and the whole app script failed to parse — never committed; the served-shell lag (the service worker paints the cached page, fetches the new one behind) is why a fix shows on the second open.
2026-09-28 · v1135the day's pegs · phone-first serving + "ink-updated" · the never-dead tap · text-first sync · a failed comments load no longer remembered. owed the owner's read on a phone, on the real link.
2026-09-27 · v1134the offline store (three days, automatic on open and pull) · the app lands on Ink with no network · pull-down reaches the network.

Sources

support.apple.com/guide/iphone/offline-mode-read-downloaded-news-content-iph0c38a4b93/ios · github.com/nytimes/Store · uxcam.com/blog/new-york-times-offline-strategy · github.com/guardian/editions · github.com/Financial-Times/n-service-worker · github.com/matthew-andrews/ft-style-offline-web-app-part-4 · webkit.org/blog/14403/updates-to-storage-policy · developer.chrome.com/docs/capabilities/periodic-background-sync · developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria