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

A developer built an SMS-reading expense tracker for Android, but abandoned the approach after discovering that Google Play Protect blocks apps requesting SMS permissions, distribution is nearly impossible, and iOS never allows third-party SMS access. The project, Spendlee, pivoted to a voice/text logging system using Android's SpeechRecognizer to avoid restricted permissions.

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: