Mobile App (iOS + Android)

Status: Delivered (Phase 4 implementation deferred — see below) CAS: CAS-645
Delivered: 2026-04-28
PRs: #227 (Phase 1), #261 (Phase 2), #288 (Phase 3)

What’s new

Casaconomy now builds and runs on iOS and Android. You can view your transactions, run provider syncs, edit and categorize transactions, and capture receipts with on-device OCR — all on your phone. The same Rust core, the same React UI, the same encryption and sync stack; no separate mobile codebase.

Provider sync on mobile works identically to desktop: you drive an authenticated webview session (BankID QR, password), and the app extracts the data on your device. No credentials ever leave the device or pass through a server.

How to use it

The mobile app ships as the same Tauri project — the iOS and Android targets are part of the same build. Phase 1 through Phase 3 are activated by building against the mobile targets:

deno task tauri ios build    # or tauri android build

On device or simulator, the app presents the same transaction list and provider sync flow as desktop. Mobile-specific surfaces:

Provider sync — tap the sync trigger; the app opens a webview to your bank’s login page, exactly as on desktop. BankID app-switch is handled via Universal Link (iOS) / deep-link intent (Android).
Edit / categorize / tag — all write operations are available on mobile. Every write emits a changeset to the local DB, which the sync relay picks up on the next sync cycle.
Receipt capture — the backend (OCR pipeline, receipts table, Tauri commands) is in place. The camera UI is tracked in CAS-971 and is the only remaining Phase 3 surface.

What changed under the hood

Phase 0 (CAS-646): Tauri v2 mobile feasibility confirmed. The secondary-webview provider sync pattern transfers directly from desktop WKWebView / WebView2 to iOS WKWebView / Android WebView. BankID Universal Link round-trip validated.
Phase 1 (CAS-647): Three Rust compile blockers for iOS/Android targets resolved (src-tauri/). iOS + Android builds now pass cargo check clean.
Phase 2 (CAS-648): update_transaction_row, tag_transactions, untag_transactions, add_transaction, and set_transactions_settlement all emit best-effort changesets after each write. Migration 42 adds relay_sequence to the changesets table; count_unsynced_changesets() exposes queue depth to the sync coordinator.
Phase 3 (CAS-649): receipt_service.rs, receipts_db.rs, receipt_commands.rs, receipt_types.rs, and migration 44 (receipts table) added. OCR is wired through the existing src-tauri/src/invoices/ocr.rs pipeline. ts-rs bindings for Receipt and LinkReceiptInput generated.

Why we built it

The finance app people actually reach for is the one in their pocket. Casaconomy’s Rust core, provider sync model, and E2E encryption were designed to transfer to mobile from the start — Tauri v2’s mobile support made that practical without a separate codebase. Building mobile now, while the sync relay and encryption stack are fresh, keeps the architecture coherent and avoids a later rewrite.

Known limitations / follow-on work

CAS-971 — Camera UI for receipt capture. The backend (OCR pipeline, receipts table, commands) is shipped; the mobile camera UI surface is not yet built.
Phase 4 (CAS-650 sub-issues) — Invoice queue review, rule management, and import/export on mobile are scoped and in backlog. They activate when usage data from Phases 1–3 indicates demand.
Free tier policy — 2 devices, local-first; sync is a paid feature. Licensing and paywall implementation tracked in GH #31.
Distribution — Apple Developer Program ($99/yr) + Google Play ($25 once). TestFlight + Play Internal Testing for beta. Not yet submitted.

Phases delivered

Phase	Issue	PR	Merged
0 — Feasibility spike	CAS-646	—	spike only
1 — iOS/Android compile targets	CAS-647	#227	2026-04-26
2 — Mobile writes + changeset emit	CAS-648	#261	2026-04-26
3 — Receipt capture backend + OCR	CAS-649	#288	2026-04-28
4 — Desktop parity gaps (scope)	CAS-650	—	sub-issues in backlog