On an iPhone, the method most Indian expense apps are built on simply does not exist. iOS has never given third-party apps a way to read incoming SMS, so an app cannot watch your bank alerts arrive the way an Android app once could. That leaves four realistic options, and only one of them produces a complete record without daily effort: reading the same alerts from email instead, which iOS does allow.
Apple provides MessageUI so an app can compose a message that you then choose to send. There is no counterpart for reading what arrives. No public framework exposes incoming SMS content to a third-party app, which means there is no permission dialog to accept and no setting buried in Preferences that unlocks it. The capability is absent by design, not withheld pending approval.
The one adjacent capability is message filtering. Apple's IdentityLookup framework lets an app classify messages from unknown senders as junk or not, via an ILMessageFilterExtension. It is deliberately built so the app learns nothing: the extension runs sandboxed, without network access in its basic form, and returns a verdict rather than the content. It exists to fight spam, and it cannot be repurposed into a transaction feed.
This is the fact that shapes the entire Indian market. An expense app that reads SMS is not a design choice that Apple disallows — it is a product that cannot be built on iOS at all. Any iPhone tracker you find is therefore using a different mechanism, and it is worth knowing which one.
| Approach | Captures | Ongoing effort | Main gap |
|---|---|---|---|
| Manual entry or a spreadsheet | Whatever you remember to record | Every transaction, every day | Decays the first busy week |
| Individual bank apps | One institution each | Open three or four apps, add it up | No combined view; no history across banks |
| Apple Wallet | Cards added to Wallet, on that device | None | Misses UPI, which is most Indian spending |
| Email alert parsing | Every account that emails alerts | One-time connection | Cash; occasional merchant naming |
Wallet deserves a specific note, because it is the option people assume covers them. It records transactions on cards you have added, on that device. In India the dominant everyday rail is UPI, and a UPI payment made in a payments app does not pass through Wallet. A Wallet-only view can therefore look reassuringly tidy while omitting the majority of what actually left the account.
Your bank sends the same transaction notice twice — once as SMS, once as email — and only one of those is readable by an app on both platforms. A mail API is a documented, user-authorised, revocable, read-only integration. Nothing about it depends on the operating system, which is why the same approach produces the same result on an iPhone and on an Android phone.
It also has a property SMS parsing never had: the archive already exists. Alerts sit in the mailbox from before the day you decided to start tracking, so the first month of history is readable immediately rather than accumulating forward. The mechanics of what those alerts contain and what a parser extracts are covered separately in how Gmail expense tracking actually works.
The sequence matters, because the most common failure is a silently missing account rather than a broken connection.
Step two is the one that gets skipped, and it is the only one that silently produces a wrong answer. A missing connection is obvious. An account whose email alerts were never enabled just quietly contributes nothing, and the monthly total looks plausible while being too low.
Assume a salaried professional in a metro with one salary account, one credit card used for most discretionary spending, a second card kept for a specific reward, and a UPI app linked to the salary account. Assume email alerts are enabled on both cards and the bank account, and that roughly a fifth of spending is cash withdrawn from an ATM.
What the record will show: every card transaction and every UPI payment, with exact amounts and dates, plus the salary credit and any refunds. What it will not show: how the withdrawn cash was spent. That appears as a single ATM debit under cash.
So the month's total outflow is exact — the withdrawal is real money leaving, counted once. The category breakdown is complete for four-fifths of it, with the remaining fifth sitting in one honest bucket labelled cash. That is a materially better answer than a spreadsheet abandoned in week two, and it is worth being clear that it is not a perfect one. Reducing the cash share is the only thing that improves it, and that is a behaviour change rather than a software feature.
One question separates the options quickly: where does its data come from? If the answer is the SMS inbox, there is no iPhone version and there is not going to be a good one. If the answer is manual entry, the app is a nicer keyboard for a spreadsheet, which is fine if you know that is what you are buying. If the answer is a bank login handed to a third party, the convenience is real and so is the credential exposure.
If the answer is read-only access to the alerts already in your mailbox, the mechanism is the same one that works on Android, which is the point — and it is the approach behind expense tracking on an iPhone more broadly.
No. Apple Wallet holds cards you have added to it and shows transactions made through those cards on that device. UPI payments made in a separate app do not pass through Wallet, and in India the large majority of everyday digital payments are UPI. Wallet is therefore a partial view of one payment method rather than a record of what you spent.
Only partially, and it will not read your messages. Shortcuts can prompt you to record a spend, log it to a note or sheet, and trigger on time or location — but it is still manual entry with fewer taps. Nothing in Shortcuts grants access to incoming SMS content, so the automation captures what you remember to tell it rather than what actually happened.
Each bank app shows only its own accounts, so using them alone means checking three or four apps and adding the results yourself. That is the problem an aggregated view solves. Email-based tracking avoids the split because every institution sends its alerts to the same mailbox, regardless of which bank issued the account or which app the payment was made in.
It is different rather than worse, and the gap has narrowed. Android apps could read the SMS inbox, which made automatic tracking easy to build there; Google Play has since restricted that permission to default messaging apps. Email-based tracking was never platform-dependent, so an iPhone using it gets the same completeness an Android phone does.
Because their core mechanism was reading SMS, and rebuilding for iOS means replacing that mechanism rather than porting it. An app whose entire data pipeline assumes an SMS inbox has no product on a platform that does not expose one. Apple’s share of India’s smartphone market has also been small in unit terms, which weakened the commercial case for doing that work.
TLDR Money reads the transaction alerts already in your Gmail, so an iPhone gets exactly what an Android phone gets. Read-only access, no SMS permission, no bank login.
Join the waitlistNo spam, ever.
This is an explanation, not advice about your money. TLDR Money is not a registered investment adviser and earns no commission on any product mentioned. Figures are illustrative; your own numbers, taxes and circumstances will differ.