| 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)
- Confirm target behavior from README and the current code path
- If the runtime flow or bridge contract is unclear, run
legacy-webview-analysis first
Gate
- State the minimal file touch set before editing. If the request is ambiguous, stop and ask instead of guessing scope.
Phase 1 — Implement
- Patch minimally in Objective-C and preserve existing conventions
- Keep WKWebView and fallback expectations aligned
- Preserve bridge contract (handler names, protocol queue semantics)
- Add focused tests when behavior can be isolated
Phase 2 — Validate
- 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
- 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
