SpenDrop

Most everyday payments in Malaysia now end with a confirmation screen: Touch 'n Go, a bank app, DuitNow QR, Apple Pay. SpenDrop turns that screen into an expense. Take a screenshot, share it to SpenDrop, check the form it fills in, and save. Cash spending goes in by hand with Quick Cash.

It is a native iOS app with a Share Extension, written in Swift and SwiftUI with SwiftData for storage and Apple's Vision framework for OCR. Reading and parsing run on the phone, and the app is local-first: it works offline with no account, and there is no third-party package. Version 1.4.0 adds optional sign-in with cloud backup to Supabase. It is verified on the simulator; it is not on the App Store.

Expense apps ask you to type what your phone already shows you. The payment screen has the amount, the merchant, the provider and a reference number, but copying them by hand is slow enough that most people stop doing it. And a payment confirmation is financial data: sending it to a server to be read is a poor trade for convenience.

The Share Extension receives the image from any app's share sheet. Vision reads the text on the phone, on an image downsampled to 1280 pixels to stay inside the extension's memory limit, and the lines are sorted into rows. A rule-based parser then works out what the screen is: which provider, which merchant, which category, the date and time, and the reference number. The extension shows the result as a review form; nothing is saved until the user confirms.

The app and the extension are two separate processes, so they share one SwiftData store through an App Group. An expense saved from the share sheet is on the dashboard the next time the app opens, and the duplicate check in the extension can see everything the app has saved.

A payment screen rarely has one number on it. A Touch 'n Go confirmation can carry an advert for an RM 450 air conditioner under an RM 18.50 payment; a receipt lists a subtotal, a service charge and a total; a bank screen shows the balance. The parser labels every RM value it finds (total, fee, balance, cashback, discount, advertisement) and chooses from the valid candidates only. When several remain, the review form shows them as one-tap alternatives; when one remains, the row is hidden.

Screens that are not payments at all, such as a balance, a credit limit or reward points, are recognised and are not saved as expenses, or are flagged for review. Sharing the same screenshot twice is caught by its reference number, or by the same merchant and amount on the same day within a 48-hour window, and the user decides whether to add it anyway.

A payment answers two separate questions, and the app keeps them separate. The Payment Channel is how it was paid: Apple Pay, QR payment, DuitNow QR, bank transfer, online banking, card, e-wallet or cash. The Funding Account is where the money came from, a bank, an e-wallet or cash. Detection is conservative: when the screen does not say, the channel stays Unknown rather than being guessed. Since 1.4.0 funding accounts are real records, with money recorded in and out per account, and deliberately no balance field, because the app records activity rather than reading a bank.

The same purchase often arrives twice: once as an Apple Pay tap and again, days later, as the bank's own record. Before saving, a reconciliation engine looks for an existing expense with the same amount within 48 hours. When it finds one it merges the two, filling in whatever the first record lacked (channel, funding account, merchant, reference) instead of adding a second expense. Separate duplicate checks warn on a repeated reference, or the same merchant and amount close together, for both expenses and money records, and never delete anything on their own.

Categories learn from use: saving or correcting an expense teaches the app, on the device, which category a merchant belongs to.

Around capture sits the rest of the app, in five tabs. Home shows today, week and month spending, with cash flow and balances when they apply. Transactions is one filterable timeline of expenses, money in, money out and transfers. PayBook holds people and their payment details, with calculated balances and recorded repayments. Breakdown, built with Swift Charts, splits spending and cash flow by category, payment channel, account and merchant. More holds accounts, settings and a self-test runner that executes the app's in-app checks on the device. A Shortcuts action, Log Apple Pay Purchase, lets the Wallet transaction automation hand an Apple Pay tap straight to SpenDrop.

Version 1.4.0 turns the expense log into a small personal-finance model without making normal entry any longer. Each number answers one question: an expense's amount is always the full bill, spending is my share of it, money in and money out cover income, refunds, loans and repayments, net cash flow is the difference, and a person's balance says who owes whom. A bill can be split equally, by parts or by exact amounts, whoever paid, and all of this arithmetic runs in integer sen so a split always adds up exactly. Balances are calculated when they are shown, never stored.

The data is protected before any of that ships. The SwiftData store moved to an explicit versioned schema with a migration plan, a copy is taken before every upgrade, and a store that cannot be opened puts the app into a safe mode that deletes nothing. Local backups keep a dated history and export to JSON. Sign-in is optional: Google through OAuth PKCE or email, with the session in the Keychain, and it adds an append-only cloud backup to Supabase, with Row Level Security policies written to restrict each row to its owner. A restore merges by record and takes a local safety copy first.

Adverts looked like payments. A Touch 'n Go confirmation can show an RM 450 air-conditioner banner under an RM 22.00 transfer, and any pattern for an RM amount matches both. The fix gives every amount a meaning before any is chosen: advertisement keywords, the words on neighbouring lines, and position, using Vision's bounding boxes, since adverts sit in the bottom of the screen. Layout turned out to be a stronger signal than the text alone.

Interbank transfers name two banks. A CIMB to Maybank receipt mentions both, and the expense belongs to CIMB. Keyword matching alone was ambiguous, so the parser now reads the screen as a document: it collects the banks named after a recipient label first, then reads the from-block, and never attributes a payment to a bank that only appears as the recipient. Apple Pay is treated the same way, as a wrapper around the bank behind it.

Column-aligned receipts still break it. On a synthetic receipt with the label and the amount far apart, Vision returned "TOTAL" and "RM 19.08" as separate observations, the total lost its label, and a line item won. The review screen correctly downgraded to "Possible Expense Detected", and the case is recorded as a known limitation rather than hidden.

The app carries its own test runner, run in memory or in temporary folders so the real database is never opened. It has grown to 274 checks across twelve suites: parsing, providers and real reference screenshots; data safety, from safe mode to frozen schemas and backups; the money model, splits and migrations; accounts and money in and out; shared expenses and PayBook balances; the unified timeline; and sign-in and cloud backup against a simulated Supabase server. Six XCUITest flows drive the app itself: tabs, adding an expense, a split with its PayBook balance, accounts with money in and a transfer, the cash-flow views and the account screen.

The repository records the run on 29 September 2026 on the iOS 27 simulator: 274 of 274 in-app checks and 6 of 6 UI tests passed, and both the app and the Share Extension built. The parser checks feed synthetic OCR text, so they test the parser, not Vision's recognition quality. There is no CI yet, and version 1.4.0 has not yet been verified on a physical iPhone.