Just to be clear: All text below is AI generated, but helpfull.
Title: iOS: vault reload loop is the WebContent renderer being jetsam-killed at its per-process memory limit
I have been chasing the endless “indexing → screen refreshes → indexing again” loop on iOS for a week and finally captured it in the device console. The loop is not Obsidian crashing or restarting. It is the WebKit renderer process hitting the per-process memory high-water mark and being killed by the kernel, after which Obsidian reloads its web view — which is what you see as a refresh.
Posting the raw evidence here because this thread asks for a reproducible case and there is no iOS variant yet.
Environment
- iPhone 14 Pro, iOS 26.6.1, Obsidian 1.13.7 (App Store build)
- Vault: 2,427 markdown files, 104 MB of markdown, 168 MB total, on iCloud Drive
- Reproduced deliberately by toggling one variable (see below)
What the console shows
Fifteen renderer kills in thirty-one seconds, roughly one every 2.2 seconds:
10:31:26.779 kernel memorystatus: killing_highwater_process pid 34907 [com.apple.WebKit.WebContent]
(highwater 100 4s rf:- type:app) 1738194KB - memorystatus_available_pages: 171026
10:31:29.399 kernel memorystatus: killing_highwater_process pid 34909 [com.apple.WebKit.WebContent]
(highwater 100 2s rf:- type:app) 1647010KB - memorystatus_available_pages: 177474
... (13 more, identical shape)
10:31:57.010 kernel memorystatus: killing_highwater_process pid 34935 [com.apple.WebKit.WebContent]
(highwater 100 3s rf:- type:app) 1581138KB - memorystatus_available_pages: 163027
10:31:27.706 ReportSystemMemory Process com.apple.WebKit.WebContent [34907] killed by jetsam reason highwater
10:31:26.346 ReportCrash Formulating simulated 309 report for corpse[34907] com.apple.WebKit.WebContent
Every kill sits between 1,539 MB and 1,916 MB resident footprint. After each kill runningboardd launches a fresh WebContent for the same host app and the main frameID increments — the page is loaded from scratch, which is the visible reload.
Four things this rules out
-
The app does not crash or restart. md.obsidian keeps a single PID (34904) for the entire log; the kernel never names it. Only its renderer children die.
-
This is not system memory pressure. At every kill the device has 2.5–2.7 GB free (memorystatus_available_pages 163027–177822 at 16 KB pages), and all 112 pressure lines report system vm pressure critical: 0. Closing other apps does not help; the ceiling is per process.
-
This is not a plugin leak. The renderer’s own accounting right before each kill:
javascript_gc_heap_capacity_mb: 234 javascript_gc_object_count: 45287
phys_footprint_mb: 1595 resident_size_mb: 1613
The JS heap stays at 192–286 MB while the footprint is 1,389–1,836 MB. Over a gigabyte lives outside the JavaScript heap — that is document/DOM and WebKit-side allocation, not plugin code. The GC object count spikes from 45K to 2.5M within one second just before the kill.
-
No storage quota involved. Zero occurrences of quota, IndexedDB or ENOSPC in the log, and every single reload in the window is preceded by a kernel kill — sixteen renderer starts, fifteen kills between them. There is no reload with another cause.
The trigger, and why plugin bisection kept contradicting itself
The deciding factor in my vault is one generated file: a compiled decision register of 2.26 MB with 1,650 headings and ~3,450 internal wikilinks in a single note. Moving it into a dot-prefixed folder (which Obsidian does not index) makes the full vault open reliably with all plugins enabled; moving it back reproduces the loop within seconds. That is exactly the toggle used to capture the log above.
This also explains why weeks of plugin bisection produced contradictory results. The peak footprints (1,539–1,916 MB) are stacked right against the ceiling, so it is a threshold effect on one variable — peak renderer footprint during index build. Anything worth a few hundred megabytes (a plugin on or off, a warm vs. cold metadata cache, iCloud still materialising files) flips the outcome. Every single-run bisection was measuring the same margin from a different side.
Note that this matches the desktop-side report in this thread: 962 KB / 26,505 lines / 6,151 headings → V8 out of memory. Same shape, different ceiling — on iOS the ceiling is the jetsam high-water mark for a WebContent extension, which is well below what the device actually has free.
Workarounds that work
- Keep very large generated notes in a dot-prefixed folder (
.something/) so Obsidian never indexes them. Git, scripts and external tools still read them by path.
- Rename to
.txt, as mentioned earlier in this thread.
- Neither reduces the underlying footprint — they only buy headroom below the ceiling.
What I would like to know
- Is there anything the app can do to keep the initial index build under the iOS per-process footprint limit — chunked/streamed parsing, or releasing intermediate structures between files?
- Is the >1 GB of non-JS-heap memory expected for a single large note with this heading/link count, or does it point at something retainable?
- Would a sanitised reproduction vault (one generated note of this shape, no plugins) be useful? I can produce one that reproduces on iOS in under ten seconds.