Update: We didn’t stop there — how breaking “standard” WebGL rules actually saved our mobile stability
Quick follow-up for anyone following this thread. We kept pushing, ran dozens of stress tests, and managed to achieve rock-solid stability across mobile Safari.
The biggest lesson from this sprint: Strictly following textbook WebGL lifecycle guidelines kept leading us into dead ends and breaking things that worked. Standard .dispose() workflows weren’t accounting for how aggressively WebKit handles VRAM. Real stability only came when we bypassed standard practices and engineered custom, “unconventional” lifecycle hacks specifically tailored to iOS WebKit memory behavior.
Final Loadout Summary:
-
Geometry: Up to 3M+ triangles (no LODs)
-
Assets: Up to 50+ dynamic GLBs loaded simultaneously
-
Rendering: Dual live WebGL contexts, 6 custom shaders, full PBR, post-processing/bloom, and live on-chain state sync
By stepping away from standard WebGL patterns and building custom frame-budgeting, context pausing, and micro-delay teardowns, we cleared the memory ceiling without sacrificing a single polygon or shader pass.
If anyone in the community is currently fighting dual-context WebGL in mobile Safari, struggling with WebKit’s Jetsam limits, or wants to know how we bypassed standard disposal pipelines to keep 3M tris stable on mobile — drop a reply or reach out! Happy to share the exact architectural hacks that made it work.