Summary

• Problem: iOS chat staged PhotosPicker image bytes directly, rejected raw files over 5 MB before resize, and sent raw EXIF/GPS-bearing bytes into chat.send.
• Why it matters: large iPhone camera photos can fail attachment delivery or spike memory during base64 encoding.
• What changed: image attachments now flow through a chat-specific JPEG processor that caps the long edge at 1600 px, compresses to a 3.5 MB payload budget, strips source metadata, and stages previews from the resized JPEG bytes.
• What did NOT change (scope boundary): gateway protocol, chat send schema, auth, permissions, and non-image attachment handling are unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug] iOS: large chat image attachments fail or blow up memory (48MP frames, no client-side resize) #68524
• Related [Bug]: RangeError: Maximum call stack size exceeded in isValidBase64 when sending large image attachments via webchat (mobile) #80679
• Related feat(chat/ios): inline image resize + EXIF metadata strip for attachments #73710
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: iOS app PhotosPicker attachments are processed client-side before staging/sending instead of using full-resolution raw image data.
• Real environment tested: local macOS SwiftPM build of apps/shared/OpenClawKit on the OpenClaw iOS shared package.
• Exact steps or command run after this patch:
  • swift test --package-path apps/shared/OpenClawKit --filter 'ChatImageProcessorTests|JPEGTranscoderTests|ChatViewModelAttachmentTests'
  • swiftformat --lint --config config/swiftformat apps/shared/OpenClawKit/Sources/OpenClawKit/ChatImageProcessor.swift apps/shared/OpenClawKit/Sources/OpenClawKit/JPEGTranscoder.swift apps/shared/OpenClawKit/Sources/OpenClawChatUI/ChatViewModel.swift apps/shared/OpenClawKit/Tests/OpenClawKitTests/ChatImageProcessorTests.swift apps/shared/OpenClawKit/Tests/OpenClawKitTests/ChatViewModelAttachmentTests.swift
  • swiftlint lint --config apps/ios/.swiftlint.yml apps/shared/OpenClawKit/Sources/OpenClawKit/ChatImageProcessor.swift apps/shared/OpenClawKit/Sources/OpenClawKit/JPEGTranscoder.swift apps/shared/OpenClawKit/Sources/OpenClawChatUI/ChatViewModel.swift apps/shared/OpenClawKit/Tests/OpenClawKitTests/ChatImageProcessorTests.swift apps/shared/OpenClawKit/Tests/OpenClawKitTests/ChatViewModelAttachmentTests.swift
  • git diff --check origin/main..HEAD
• Evidence after fix: the focused Swift test run passed the view-model attachment path, the chat image processor suite, and the existing JPEG transcoder suite on commit 65d3efe.
• Observed result after fix: synthetic large portrait and landscape images are staged as image/jpeg, renamed to .jpg, capped to the 1600 px long edge, kept within the 3.5 MB chat payload budget, and tested to avoid source metadata leakage.
• What was not tested: physical iPhone camera roll -> composer -> live gateway send. pnpm ios:build is currently blocked in this checkout by unrelated existing SwiftFormat failures in apps/ios/Sources/Settings/SettingsTab.swift.
• Before evidence: issue [Bug] iOS: large chat image attachments fail or blow up memory (48MP frames, no client-side resize) #68524 documents the full-resolution PhotosPicker path failing on large iPhone camera images; current code loaded raw Data and applied only a pre-resize 5 MB hard gate.

Root Cause (if applicable)

• Root cause: OpenClawChatViewModel.addImageAttachment accepted raw PhotosPicker image bytes, applied a 5 MB size check before any transformation, and staged the original bytes for later base64 send.
• Missing detection / guardrail: there was no chat attachment processing policy or regression test asserting pixel cap, byte budget, JPEG output, or metadata stripping for iOS chat attachments.
• Contributing context (if known): JPEGTranscoder already existed, but the chat composer path did not use it.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file:
  • apps/shared/OpenClawKit/Tests/OpenClawKitTests/ChatImageProcessorTests.swift
  • apps/shared/OpenClawKit/Tests/OpenClawKitTests/ChatViewModelAttachmentTests.swift
• Scenario the test should lock in: large images are resized to the upload policy, output is JPEG within budget, source metadata strings/GPS dictionaries are stripped, alpha sources flatten to opaque JPEG, non-images are rejected, and OpenClawChatViewModel stages resized JPEG bytes rather than the original file.
• Why this is the smallest reliable guardrail: it proves the attachment path at the shared iOS chat UI boundary without needing a physical Photos picker or live gateway.
• Existing test that already covers this (if any): existing JPEGTranscoderTests covered the shared transcoder; this PR adds chat-specific policy and view-model coverage.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• iOS chat image attachments are converted to JPEG before send.
• Large images are downscaled and compressed client-side before the 5 MB final gate.
• Source EXIF/GPS-style metadata is not forwarded into chat attachment bytes.
• Original filename extensions are normalized to .jpg for processed image attachments.

Diagram (if applicable)

Before:
PhotosPicker raw bytes -> 5 MB raw gate -> preview from raw bytes -> chat.send base64

After:
PhotosPicker raw bytes -> image type check -> JPEG resize/compress/strip metadata -> 5 MB final gate -> preview from processed JPEG -> chat.send base64

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? Yes
• If any Yes, explain risk + mitigation: the data scope is reduced because source image metadata is stripped before staging/sending. Tests assert planted source metadata strings and GPS dictionaries do not survive processing.

Repro + Verification

Environment

• OS: macOS host
• Runtime/container: SwiftPM for apps/shared/OpenClawKit
• Model/provider: N/A
• Integration/channel (if any): iOS chat composer shared UI path
• Relevant config (redacted): none

Steps

1. Process synthetic large JPEG/PNG image inputs through ChatImageProcessor.
2. Stage a synthetic 3000x4000 image through OpenClawChatViewModel.addImageAttachment.
3. Verify output dimensions, byte budget, MIME type, filename, metadata stripping, and absence of staging errors.

Expected

• Processed chat image attachments are bounded JPEGs and previews use the processed data.

Actual

• Focused Swift tests pass on the rebased branch head 65d3efe72f.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: long-edge resize for portrait/landscape/narrow images, no upscaling of small images, payload budget, non-image rejection, source metadata stripping, alpha flattening, and view-model staging of processed JPEG data.
• Edge cases checked: transparent PNG input, EXIF/GPS/TIFF strings planted in source bytes, camera-style large portrait attachment path.
• What you did not verify: physical iPhone picker and live gateway send; full iOS build remains blocked by unrelated SwiftFormat failures outside this PR.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

No review conversations exist on this PR at creation time.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: JPEG conversion drops original format and metadata.
  • Mitigation: this is intentional for chat transport safety and privacy; UI/test expectations name the JPEG normalization.
• Risk: pathological images may still fail the final 5 MB gate after processing.
  • Mitigation: the final gate remains and reports a clear post-resize size error instead of staging unsafe raw bytes.