Mobile
Free across all tiers. Mobile uses the same widget inside a WebView. There is no native PoW reimplementation; Cap stays in the WebView. See ADR-0005.
The pattern
The customer's iOS / Android app embeds a WebView pointing at a small mobile-optimized embed page hosted on the Caputchin CDN. The user solves; the page bridges the resulting wrapped token back to the native app via the WebView's JavaScript bridge; the native app sends it to the customer's backend, which calls /siteverify like any web request.
sequenceDiagram
participant App as Native app (iOS/Android)
participant WV as WebView (Caputchin embed page)
participant FC as Caputchin platform
participant CB as Customer backend
App->>WV: open https://embed.caputchin.com/?sitekey=...&game=...
WV->>FC: widget loads, Cap challenge, game runs
FC-->>WV: wrappedToken
WV-->>App: postMessage / JS bridge: token
App->>CB: API call carrying token
CB->>FC: POST /siteverify with secret
FC-->>CB: verification result
What ships at MVP
- The WebView pattern, documented. See the mobile-webview guide.
- A mobile-optimized embed page on the Caputchin CDN — same widget, mobile-friendly defaults (full viewport, touch-tuned). The widget's sandboxed game iframe is supported across the iOS WKWebView and Android System WebView versions in the project's support matrix;
srcdoc+sandbox="allow-scripts"produces an opaque-origin document on both. See ADR-0015.
What's deferred
- Thin native SDKs (Swift / Kotlin). Convenience wrappers around the same WebView. Will be free when they ship — they're DX sugar, not new capability. Built when customer demand emerges. Listed in roadmap.
- Native PoW. Will not happen. Cap is a dependency, and Cap runs in browsers.
Why this posture
This matches Turnstile (WebView only, free) and Cap's own reality (browser-only PoW). Game authors don't write mobile-specific code; the same register() call powers both platforms. Customers pay nothing extra for mobile because there's nothing extra to maintain.