WebView Test Page (Android / iOS)

1) Console / Error / Promise

※ WebView에서 console 출력이 실제로 보이는지(디버그 연결) 확인

2) Storage

3) Cookies

iOS WKWebView는 쿠키/스토리지 정책이 앱 설정에 따라 달라질 수 있어요.

4) Fetch / CORS / JSON

기본은 https://httpbin.org를 호출합니다(네트워크 허용 필요).

5) File / Input / Camera

카메라/앨범 호출은 WebView 설정(권한, file chooser 구현)에 영향 큼

6) Deep Link / 외부 앱 호출

iOS는 intent 스킴이 동작하지 않습니다. 앱에서 별도 처리 필요.

7) History / Navigation

SPA 라우팅/뒤로가기 이슈를 간단히 확인

8) Viewport / Keyboard

iOS는 키보드/viewport 동작이 특히 다릅니다(visualViewport 유무).

9) JS Dialogs (alert/confirm/prompt) & Notifications

dialog result

(n/a)

Notification

checking...

iOS WKWebView에서 alert/confirm/prompt가 안 뜨면 앱에서 WKUIDelegate 처리 필요.
Notification은 HTTPS/정책에 따라 차단될 수 있음.

iOS/Android 네이티브에서 처리해야 하는 경우 (힌트)

iOS(WKWebView):
- alert/confirm/prompt:
  WKUIDelegate 구현 (runJavaScriptAlertPanel..., runJavaScriptConfirmPanel..., runJavaScriptTextInputPanel...)
- Notification:
  보통 WKWebView 자체에서 웹 푸시가 제한적일 수 있고,
  Safari와 정책이 다를 수 있음(기기/OS/앱 설정에 영향)

Android(WebView):
- alert/confirm/prompt:
  WebChromeClient의 onJsAlert/onJsConfirm/onJsPrompt 구현

10) PostMessage / Bridge (샘플)

앱에서 JS bridge를 심어두면 여기서 호출 테스트 가능

11) Log

12) Download (attachment / 파일 저장)

/download/test.txt /download/test.bin

download hint


            서버 응답에 Content-Disposition: attachment 가 있어야 WebView가 다운로드로 인식하는 경우가 많음

※ GitHub Pages는 헤더 설정이 어려워 attachment 테스트가 불안정할 수 있어요.
Cloudflare Pages에서는 루트의 _headers 파일로 /download/*에 attachment 헤더를 붙여 테스트합니다.

WebView Test Page UA