# I Built an SMS-Reading Expense Tracker. Then I Learned Why Nobody Else Does That.

> Source: <https://dev.to/shadowmonarch9/i-built-an-sms-reading-expense-tracker-then-i-learned-why-nobody-else-does-that-309a>
> Published: 2026-07-27 16:11:33+00:00

*Cross-posted from the Spendlee repo, where the full technical postmortem lives in *

`docs/PIVOT-FROM-SMS-TO-VOICE-AI.md`

.Every UPI transaction in India comes with an SMS receipt. So the first version of what's now **Spendlee** skipped manual expense entry entirely — a `BroadcastReceiver`

would catch the bank text, regex out the amount and merchant, and fire a notification: *"New transaction detected — log it?"*

Zero typing. Zero friction. The single biggest reason expense trackers get abandoned, solved before the user even opened the app.

It worked. I built the whole thing — SMS receiver, bank-specific and generic UPI parsers, the notification flow, confirm/categorize screens, Room storage. Then I tried to actually ship it.

**Google Play Protect doesn't care that you're not malware.** The moment a signed APK requesting `RECEIVE_SMS`

/`READ_SMS`

was installed outside the Play Store, Play Protect blocked it on sight — the same heuristic that catches SMS-stealing malware doesn't stop to ask whether this particular app is a personal finance tool you wrote yourself. Getting around it meant disabling a security feature and enabling "install from unknown sources," which is a fine ask for a developer testing their own build and a hard no for handing the APK to a friend or spouse.

**Distribution was harder than the app.** You can't even email the thing to yourself — Gmail strips `.apk`

attachments outright. Every distribution path led back to the same trade: disable one protection, then another, for an app whose entire value proposition was supposed to be *effortless*.

**The Play Store isn't a clean escape hatch either.** Declaring `RECEIVE_SMS`

/`READ_SMS`

there requires a separate Permissions Declaration Form with strict, inconsistent review outcomes, plus a mandatory privacy policy — a reasonable cost for a company shipping an official banking app, a lot of process risk for a side project whose core feature is exactly the permission pair Google scrutinizes hardest.

**And then the wall that actually mattered: iOS.** No third-party iOS app has ever been allowed to read SMS content — not behind a permission dialog, not through a special entitlement, not at any App Store review tier. This isn't a policy form to fill out; it's OS-level sandboxing Apple enforces uniformly. Which meant the SMS-reading architecture could *never* have an iOS counterpart, full stop — any plan to eventually port this to iPhone was dead the moment SMS reading became the core mechanism, regardless of how much more Android engineering went into it.

I replaced automatic detection with **user-initiated voice/text logging**:

`SpeechRecognizer`

— no cloud speech API, no extra permission risk.`RECORD_AUDIO`

isn't in Android's Restricted Permissions bucket — no Play Protect flag, no special declaration form.Full writeup with more detail: [ docs/PIVOT-FROM-SMS-TO-VOICE-AI.md](https://github.com/shadow-monarch9/Spendlee/blob/main/docs/PIVOT-FROM-SMS-TO-VOICE-AI.md). Repo: