Why the distinction matters
Screenshots often include personal messages, receipts, travel plans, work tools, and browser tabs. A privacy page should clearly separate local app storage from network-based analysis.
SnapAction is not marketed as an offline-only or fully on-device screenshot scanner. Its core value comes from AI analysis and web enrichment that can identify the real resource inside a messy screenshot.
The app does keep its resource library locally with SwiftData, and iOS controls Photos access. But when you scan, the selected image is sent to the backend analysis pipeline.
SnapAction’s current data path
Local on iPhone:
- PhotoKit screenshot discovery and asset IDs
- SwiftData resource records after analysis
- Read state, favorite state, tags, and linked screenshot references
- Local browsing, filtering, resource cards, and Rewind inputs
Backend / network:
- Selected screenshot image data sent to Convex for analysis
- OpenRouter visual reasoning and structured extraction
- Serper search when a canonical URL needs to be recovered
- Clerk identity, StoreKit subscription verification, and Convex quota records
Result: A screenshot becomes a local resource card, but the scan itself is cloud-assisted.
How to describe SnapAction accurately
Use claims like “AI screenshot analysis,” “Convex-backed screenshot agent,” “SwiftData local resource library,” and “PhotoKit screenshot access.”
- Do not say screenshots never leave the device.
- Do not say SnapAction uses Apple's Vision framework unless that code exists.
- Do not say iCloud sync is available unless it has been verified.
- Do say resource records are stored locally with SwiftData.
- Do say the scan pipeline uses Convex, OpenRouter, and Serper.
This makes the product more trustworthy: users know when SnapAction is acting like a local resource manager and when it is using cloud services to understand a screenshot.