The shared scan zip is 90–120 MB #68

The scan zip that "Share scan" offers was 119.5 MB in run 1 and 93 MB in run 2. That's slow to share, and the phone's upload to Drive was still running when run 1's recording ended.

Seen in. Device field test of TestFlight build 4.1 (beta at 45017ba), iPhone 14 without LiDAR, iOS 26.6.2. Times are in each run's screen recording.

• Run 1 (indoor mock wall), 6:31–6:48: the share sheet reports scan.zip at 119.5 MB (Drive showed 114 MB), for 206 photos.
• Run 2 (same mock wall), 5:04–5:12: 93 MB (Drive: 88 MB) for 141 photos.

What happens. This isn't the server upload, which sends scene.json alone. It's the bundle the team uses to get scans off the phone for analysis, and that a homeowner or installer would share. Run 1's bundle, unzipped:

• photos/: 99.5 MB, 206 JPEGs at 1920×1440, about 480 KB each;
• streams/: 19.7 MB of motion CSVs (device motion alone is 10 MB);
• manifest.json and scene.json: about 0.3 MB.

The CSVs compress well: gzip takes them from 19.7 MB to 8.0 MB. The zip stores everything uncompressed.

Cause.

• Photos are encoded at JPEG quality 0.8 at full sensor-image size (LiveCapture.swift#L494-L500).
• ZipWriter is store-only (method 0), on the assumption that the bundle is mostly JPEGs (ZipWriter.swift#L3-L6). The motion streams are text and would shrink by about 60%.
• The bundle is built in KeyframeStore.swift#L209-L230.

Fix direction.

• Deflate the text entries (streams, manifest, scene), and keep JPEGs stored. That saves about 12 MB on run 1.
• Consider a lower JPEG quality (0.6–0.7) or a smaller size for the shared copy only, if reconstruction doesn't need full quality. Measure that first.
• Optionally offer "Share without photos", or show the size before sharing.

Related.

• Report IDs A41-1-20 (run 1 report) and A41-2015-22 (run 2 report). PR docs: build 4.1 field-test analyses (three runs) #60 has the public reports.