legacy-webview-implementation

name	legacy-webview-implementation
description	Use when: implementing Objective-C changes in WKWebView/UIWebView flow, JavaScript bridge, and navigation behavior with minimal risk.

Legacy WebView Implementation

Purpose

Implement production-safe fixes and enhancements in this legacy iOS WebView project.

Phase 0 — Read (no edits)

1. Confirm target behavior from README and the current code path
2. If the runtime flow or bridge contract is unclear, run legacy-webview-analysis first

Gate

3. State the minimal file touch set before editing. If the request is ambiguous, stop and ask instead of guessing scope.

Phase 1 — Implement

4. Patch minimally in Objective-C and preserve existing conventions
5. Keep WKWebView and fallback expectations aligned
6. Preserve bridge contract (handler names, protocol queue semantics)
7. Add focused tests when behavior can be isolated

Phase 2 — Validate

8. Build with the canonical command from AGENTS.md:

xcodebuild -project ios-WK-UI-Webview.xcodeproj \
  -scheme ios-WK-UI-Webview \
  -destination 'generic/platform=iOS Simulator' \
  IPHONEOS_DEPLOYMENT_TARGET=12.0 build

9. If the build cannot run in your environment, state the limitation explicitly — never claim validation that did not happen

Quality Rules

• Keep architecture simple and focused on requested behavior
• Do not change unrelated files or flows
• Prefer centralized constants over duplicated literals
• Add comments only for non-obvious bridge/navigation edge cases

Anti-example (do not do)

"While fixing the redirect, I also modernized the delegate wiring and renamed two handlers for clarity."

Unrequested scope. Handler names are a public contract; renames are a migration, not a fix.

Definition of Done

• Change is scoped and understandable
• Core navigation/bridge flow remains stable
• Validation completed (build/test or explicit limitation note)
• No accidental API or contract breakage