Apple Already Reads Your Texts With AI. Let Developers Read One Line of Them.

A developer in our orbit built a personal finance tracker with one goal: make money management nearly effortless. The plan was simple and, on Android, ordinary, when your bank texts you "AED 240.00 debited at Carrefour," the app reads that alert, parses the amount and merchant, and logs the expense for you. No receipt-snapping, no manual entry, no Sunday-night spreadsheet guilt. On iPhone, that feature is impossible to build. Apple gives third-party apps no way to read your messages at all.

That asymmetry was defensible for years. It is getting harder to defend now that Apple itself ships an AI that reads your Messages on-device and summarizes them for you. The capability exists. The privacy hardware exists. What's missing is a scoped, user-permissioned door for developers, and Apple has already built three of those for other kinds of sensitive data. It should build one more.

The everyday friction is real#

Bank SMS and push alerts are structured data hiding in plain sight: amount, merchant, date, last four digits of the card. On Android, expense apps from Axio and Moneyview to the open-source PennyWise AI (85+ banks across 14 countries) read those alerts and turn them into ledger entries automatically. For users in markets where banks text every transaction (much of South Asia, the Gulf, Latin America), this is the difference between a finance app people actually keep using and one they abandon in a week.

On iOS, none of it works. Apple provides exactly one sanctioned path to message content: one-time-code AutoFill, where the keyboard surfaces a login code for you to tap. The app never sees the SMS; the OS does the reading. iOS 26 extends OTP AutoFill to third-party messaging apps, but it is still strictly scoped to login codes. There is no general "read my texts" API, and there never has been.

Steelman the block: Apple is right to be paranoid#

Here is the part too many "just open it up" arguments skip. Apple's caution is earned, and Google's experience proves it.

Android's SMS permission is a blunt instrument. The permission itself grants an app the ability to read every message in the inbox; responsible ones merely choose to filter by bank sender. That's a promise, not a guarantee, and predatory lenders weaponized exactly this, scraping entire inboxes and contact lists for shakedown collections. Google responded by restricting the SMS and Call Log permission groups to apps that are the user's default messaging handler, forcing everyone else to apply for narrow exceptions. Plenty get denied: the budgeting app Bluecoins was refused, with Google ruling SMS access wasn't essential to its core function. The crucial nuance is that Android's own platform owner has spent years walking this permission back. Any honest proposal has to start there.

So the question is not "should iOS copy Android's SMS permission?" The answer to that is no. The question is whether Apple can grant the outcome, auto-logged transactions, without granting the inbox. It can. And it already does, three times over.

What changed: Apple now reads Messages itself#

Since iOS 18.1, Apple Intelligence has summarized message threads and drafted Smart Replies, and Apple's loud, central marketing claim is that this happens on-device, on the Neural Engine, with nothing leaving the phone. The same private-ML stack powers Live Text and Visual Look Up, which pull text and meaning out of your photos locally, no cloud round-trip.

This reframes the entire debate. Apple's old answer was effectively "reading your messages with software is too dangerous to allow." Apple's own product now reads your messages with software, safely, because it runs in a sandbox that never ships raw content off the device. The capability is no longer hypothetical. It's a shipping feature with a privacy story Apple is proud of. The only question left is who's allowed to point it at a problem.

FinanceKit already proves scoped financial access works#

Apple doesn't even have to invent the permission model: it shipped it in 2024. FinanceKit lets approved finance apps read transactions and balances from Apple Card, Apple Cash, and Savings, and under the EU's Digital Markets Act it was extended to connect with real banks (in the UK, the likes of Barclays, HSBC, Monzo, and NatWest via open banking).

Look at how tightly it's fenced, because this is the template:

• The app must be in the Finance category and request a specific Apple entitlement, assigned to the developer account after review.
• It must declare an NSFinancialDataUsageDescription string explaining the use.
• The user explicitly authorizes access, picks which accounts to share, and even sets the time range.

That is precisely the architecture the developer above wanted: scoped, declared, user-granted, revocable, financial. FinanceKit just doesn't cover the bank that texts you instead of plugging into Apple Wallet, which is most of the world's banks.

The proposal: a "Transaction Intents" entitlement#

Apple should add a narrow, on-device permission (call it Transaction Intents) that closes exactly that gap. The design borrows from everything above:

1. The developer declares, up front, what they need: specific sender patterns (your bank's shortcode or push channel) and the transaction shape they parse. This declaration is part of the App Review entitlement request, the same gate FinanceKit and ATT already use.
2. The user explicitly approves, in an Apple-controlled prompt: the App Tracking Transparency model, which since iOS 14.5 has made "ask the user, plainly, before you touch sensitive data" the platform norm. The user sees exactly which senders are in scope.
3. The app receives only the parsed transaction event: amount, merchant, date, card tail, not the raw message. Parsing happens in Apple's on-device sandbox, the same machinery already summarizing your texts. The inbox never crosses the app boundary.
4. It's revocable and auditable. A Settings pane lists every granted sender, every transaction event delivered, and a one-tap revoke. "Questionable" in the literal sense: the user can always ask what it did.

How the safeguards defuse the abuse history#

Every objection Google's experience raises, this design answers:

• "Apps will scrape the whole inbox." They can't: they never receive raw messages, only structured transaction events Apple's parser emits. A predatory lender gets no contact list, no personal texts, nothing but the financial fields the user approved.
• "Users won't understand what they're granting." ATT already conditioned a billion users to a clear, OS-level opt-in; this prompt names the exact senders.
• "It'll be abused for marketing." Gate it like FinanceKit: Finance-category apps only, entitlement by review, rate-limited, with the same prohibition on exfiltrating non-financial data that Google's own policy spells out.
• "It's a privacy regression for Apple." The opposite. Today, iPhone users who want this feature either go without or screenshot every alert into a third-party OCR app: a worse privacy outcome. A sanctioned, sandboxed channel is strictly safer than the workarounds people already reach for.

The close#

Apple has spent a decade earning trust by saying no to the inbox. That was the right call when the only tools were blunt ones. But Apple has since built the precise instruments this needs: on-device AI that reads Messages privately, a FinanceKit permission model that scopes financial access to the account and the day, and an ATT prompt that makes consent legible. The pieces are all on the shelf, shipping, marketed as features.

Controlled, limited, on-device, revocable, never the raw inbox. Apple shouldn't open the door wide. It should cut a small, well-guarded one, and let the millions of iPhone users whose banks talk to them by text finally have an app that listens for them.

Frequently asked#

Can iPhone apps read your text messages to track expenses like Android apps do?#

No. iOS provides no general API for third-party apps to read SMS or iMessages. The only sanctioned access is one-time-code AutoFill, where the keyboard surfaces a login code for you to tap: the app never sees the message. On Android, finance apps like Moneyview, Axio, and the open-source PennyWise AI can read bank transaction texts and auto-log expenses, though Google has tightened that SMS permission significantly because of abuse by predatory lenders.

Does Apple Intelligence read your iMessages, and is it private?#

Yes. Since iOS 18.1, Apple Intelligence summarizes message threads and suggests Smart Replies, and Apple's central claim is that this runs on-device on the Neural Engine, with message content never leaving the phone: the same private on-device ML stack behind Live Text and Visual Look Up. That existing capability is the core of the argument that Apple could safely extend scoped, parsed transaction access to developers.

What is FinanceKit and why does it matter to this proposal?#

FinanceKit is Apple's 2024 API that lets approved Finance-category apps read transactions and balances from Apple Card, Apple Cash, Savings, and, under the EU's Digital Markets Act, connected banks via open banking. It requires a per-app entitlement granted after review, an Info.plist usage description, and explicit user consent down to which accounts and time range are shared. It proves Apple already runs a tightly scoped, user-permissioned financial-data model; the proposed 'Transaction Intents' permission would extend that to banks that notify customers by text rather than through Apple Wallet.