India’s expense-tracking apps clustered on Android for one structural reason: Android let an app read the SMS inbox, and iOS never has. Bank alerts arrive by text, so on Android the entire product could be built on a permission prompt. On iPhone there was nothing equivalent to request. That single asymmetry — not developer preference, and not market size alone — explains why so many Indian trackers have no iOS version.
India built its banking notification layer on text messages. Regulation and practice pushed banks to alert customers on every transaction, mobile numbers were the one reliable identifier, and SMS reached every handset regardless of price or data connection. The result is that for most people the SMS inbox became, incidentally, the most complete transaction log they owned — more complete than any single bank app, because it aggregated every institution in one place.
For an Android developer that was an unusually convenient starting point. The data was already on the device, already aggregated, already timestamped, and available behind one permission prompt. No bank integration to negotiate, no aggregator to pay, no regulatory relationship required. An expense tracker could be built by a small team without a single institutional partnership.
That convenience shaped the category. When the cheapest path to a working product runs through one permission, most products take it — and inherit its constraints.
Apple has never shipped a public API for reading incoming messages. MessageUI lets an app compose a message the user then sends; there is no counterpart for reading what arrives. This is not a stricter version of Android's permission — it is the absence of the capability. There is no prompt an iOS user could accept even if they wanted to.
So the porting problem is not a porting problem. Moving an SMS-based tracker to iPhone does not mean rewriting a UI in a different language; it means replacing the mechanism that produces every row of data in the product. The screens are the easy part. The pipeline underneath them has to be built again from a different source, which is closer to starting a second product than shipping a second version.
This is why the gap persisted for years rather than closing as teams grew. It was never a backlog item that kept slipping. It was a different product, and most teams correctly judged that they were not going to build it.
The technical barrier explains why the work was large. Commercial arithmetic explains why it kept being deprioritised.
Apple's unit share of the Indian smartphone market has been small in a way that is easy to underestimate. Counterpoint Research's quarterly India tracker puts Apple at roughly 7% of shipments in the second quarter of 2026, after around 9% across 2025. So a team facing a substantial rebuild to reach under a tenth of handsets, at a moment when the Android build was already working, had a straightforward call to make.
It is worth being precise about what that share does and does not mean. Unit share is not spending share. iPhone users in India skew toward higher incomes, and a personal finance subscription is bought disproportionately by people with money to organise. The 7% figure describes handsets shipped, not the size of the addressable market for a paid tracker — which is one reason the neglect looks less rational in hindsight than it did at the time.
The Android advantage was not permanent, because it depended on a permission Google has since restricted. Google Play's policy on SMS and Call Log permission groups limits those permissions to apps that are the user's default handler for SMS, phone or assistant, with use confined to core functionality — the same constraint set out in Android's default-handler documentation.
An expense tracker is not a messaging app and does not become anyone's default SMS handler. The mechanism the whole Indian category was built on is therefore no longer generally available to new entrants on the platform where it originated.
| Data source | Android | iOS | Direction |
|---|---|---|---|
| SMS inbox | Restricted to default handlers | Never available | Closing |
| Bank credential sharing | Possible | Possible | Discouraged; credential exposure |
| Manual entry | Always available | Always available | Unchanged; decays in use |
| Email alerts, read-only | Available | Available | Stable on both |
Only one row behaves the same on both platforms and is not narrowing. That convergence is the actual story: the platform gap is closing, but by Android losing its shortcut rather than iOS gaining one.
Faced with a closing permission, part of the category moved sideways rather than rebuilding. Android exposes a separate capability that lets an app act as a notification listener — reading the notifications other apps post to the system tray. Since a bank’s SMS alert surfaces as a notification, and its app posts notifications of its own, an expense tracker granted that access can scrape much of the same information without ever touching the SMS permission.
It works, and it is worth understanding why it is a weaker foundation than it appears.
Notification access is at least as broad as the thing it replaced. A notification listener sees what every app on the phone posts, which includes messages from chat apps, email previews, and anything else that surfaces a heads-up alert. Trading SMS access for notification access does not reduce what an app can observe; in most cases it widens it.
It is also less reliable as a data source. A notification is transient by design. If it is dismissed before the listener processes it, cleared in a batch, or suppressed because the user muted that channel, the transaction is simply never seen — and nothing indicates that anything was missed. Where an email alert sits in a mailbox until deleted, a notification that was swiped away is gone. That is why a tracker built on notifications cannot backfill history: there is no archive to read, only a live stream that had to be watched at the time.
So the pivot preserved the Android product without addressing either of the two problems that mattered. It did not narrow the access being requested, and it did not produce anything on iOS, where third-party apps cannot read other apps’ notifications either.
The practical consequence is that an app's absence from the App Store tells you something specific about how it was built, and that is more useful than treating it as neglect. An Android-only Indian tracker is almost certainly SMS-based, which means it inherited a dependency now restricted on its own platform.
The question worth asking of any tracker, on either phone, is where its data comes from. If the answer is the SMS inbox, it is a product built on narrowing ground. If it is a bank login handed to a third party, the convenience is real and so is the credential exposure. If it is read-only access to the alerts already sitting in your mailbox, it works the same on both platforms — which is the reasoning behind expense tracking built for the iPhone, and the mechanics of it are set out in how Gmail expense tracking actually works.
None of this makes email parsing superior in the abstract. It has real limits — cash is invisible, and merchant names often arrive as raw payment identifiers. It is simply the only mechanism that produces the same result on both platforms without asking for more access than the job requires.
Some will, but not by porting. An app whose data pipeline assumes an SMS inbox has to replace that pipeline rather than translate it, which is closer to building a second product than shipping a second version. The ones that do arrive on iOS tend to be either newer apps designed around email or bank connections from the start, or older ones that rebuilt deliberately.
The policy governs what apps may be distributed and updated on Google Play, so an app already on your phone keeps whatever permission you previously granted until you revoke it. Restrictions bite at review and update time rather than retroactively on installed devices. You can withdraw the permission yourself at any point in Android’s permission manager.
They face the same permission policy, which is why most now use one-time-code flows that do not require reading the whole inbox. Google’s SMS Retriever API hands an app a single matching message without inbox access, and that is the sanctioned route for verification. Reading the message store was never the only way to confirm a code, only the easiest one to build.
No, provided the app reads email alerts rather than messages. Every bank that sends an SMS alert also sends the same notice by email, and mail access is a documented integration on both platforms. The result is the same completeness on either phone. What an iPhone user cannot use is the specific category of app built entirely around the SMS inbox.
TLDR Money reads transaction alerts from Gmail, so the iPhone build is not a reduced version of the Android one. 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.