Research from webrtcHacks, Snap Camera Kit, and addpipe confirmed two things: 1. iOS Safari (and modern Android Chrome) hand drawImage(video) the raw landscape sensor buffer — they do NOT pre-rotate to match device orientation. The CSS-rotated <video> display is decoupled from the pixel buffer that drawImage / MediaRecorder receive. 2. The robust pattern is to always request landscape constraints (the sensor's native orientation), and rotate manually in canvas — iPhone tags portrait captures EXIF orientation 6 (= rotate 90° CW for display), so canvas.rotate(+PI/2) is the correct default. Restored from my earlier (mistaken) "let the browser auto-rotate" attempt: bios.mjs: - getDevice(): re-add the width/height swap on mobile portrait so getUserMedia gets a landscape request. Otherwise iOS may stick the stream at whatever orientation getUserMedia was first called in. - Default rotationAngle is now Math.PI / 2 (CW) for both rear and front cameras. The selfie mirror still flips X separately. The ?camrot=0|cw|180|ccw URL override stays available for on-device bisecting. sw.js: - Bump CACHE_NAME → ac-modules-v8 so existing v7 SWs reactivate and drop their stale entries. - Pull bios.mjs and lib/disk.mjs out of PRECACHE_MODULES and add them to NEVER_CACHE while we iterate. They're at the heart of the rotation/telemetry feedback loop and the stale-while-revalidate pattern is what kept the iPhone running pre-fix code for hours after deploys. Will revert this once the rotation default is locked in.