SpendSmart: an open source iOS receipt scanner with an AI back end you supply

From a receipt photo to a spending dashboard

SpendSmart is described as AI-powered receipt tracking and expense intelligence for iOS, with the tagline Less clutter, more clarity, and it is published on the App Store.

The core interaction is short. You snap a photo of your receipts, or just say what you spent, and SpendSmart turns it into a clean dashboard, a spending map, an AI chat and smart insights. No bank connection needed, and that last point is the design decision that shapes the whole product. Most expense apps work by reading your bank feed, which means linking an account and trusting somebody with your statements. SpendSmart asks you to photograph the receipt or speak the amount instead, which is more work per entry and keeps the data on your own device and your own backend.

The features are grouped into three areas in the README. Scanning covers AI receipt scanning from the camera, from photos and from files, a batch mode, voice entry such as saying I spent $12 at Starbucks, and multi-page stitching for receipts that span several images. Intelligence covers smart spending insights, AI chat about your expenses, eight chart types and a store-location spending map. Experience covers shareable spending cards, haptics, animated micro-interactions and a ten-step onboarding with an interactive scan demo.

The voice entry example is the clearest statement of the product's bet: the cheapest data is the data you already have, and speaking a number costs less than finding and photographing a receipt.

Open source, but the author has stopped working on it

The project status section is the first thing after the header, and it is unambiguous. The author says he is no longer actively developing SpendSmart, that the app is live, and that the code is open source under the MIT license. Contributions are very welcome, and he invites people to fork it, fix something, add a feature, or build on top of it.

The last push to the repository was on 2026-05-31, and the repository is not archived, so the code is there and the tree has not been locked. There are no GitHub releases either, so there is no versioned history to point at and no changelog of user visible changes.

That combination of facts defines what this project is. It is a well documented, MIT licensed iOS codebase with an App Store build behind it, offered as a starting point rather than as a maintained dependency. For a company that wants to fork it and own the direction, that is a perfectly good deal: the structure, the SwiftUI views, the Supabase layer and the design tokens are all visible and reusable, and the absence of a maintainer is not a blocker as long as somebody on your side takes responsibility.

It is a different proposition if you were hoping for a project that would pick up your bug report. The README invites pull requests, and the contributing section says there is no formal CLA or process and asks for focused PRs, but a fork with no maintainer is a fork with no maintainer.

SwiftUI on Supabase, with RevenueCat and two model providers

The tech stack is listed in five lines, and each line tells you a dependency you inherit.

The app is Swift with SwiftUI, targeting iOS 18.0 or later, in an MVVM architecture. Database and authentication are Supabase, with Postgres and Apple Sign-In. Subscriptions go through RevenueCat with StoreKit 2. The AI pipeline is Gemini 2.5 Flash for validation and parsing plus Mistral OCR for text extraction, and the backend is an Express.js service on Vercel in a serverless deployment.

Two of those lines are commercial. RevenueCat implements a freemium model: a free tier with weekly scan limits, and a Plus tier with unlimited scanning, smart insights, cloud sync and data export. Apple Sign-In means the app authenticates through Supabase with an Apple identity, so there is no anonymous path into the data.

The split between Gemini and Mistral is worth noting because it is a two-stage design rather than one model doing everything. Mistral OCR handles text extraction from the photograph, and Gemini validates and parses the extracted text into structured data. A receipt photo is an image problem first and a language problem second, and using a dedicated OCR step for the first part keeps the vision model doing the part that needs reasoning.

Setting up keys and running the project

The requirements are macOS with Xcode 16 or later, and an iOS 18.0 or later device or simulator. The setup is three steps.

First, clone the repository and change into it.

   git clone https://github.com/madebyshaurya/SpendSmart.git
   cd SpendSmart

Second, create your API keys file from the template.

   cp SpendSmart/App/APIKeys.template.swift.example SpendSmart/App/APIKeys.swift

The template is checked in and your copy is not, because APIKeys.swift is gitignored, so your keys never get committed.

Third, fill in the keys. The template explains where to get each one, and the README lists them. The Supabase dashboard, under Project Settings and API, gives you supabaseURL and supabaseAnonKey, and they are required for auth and storage. The RevenueCat project API keys give you revenueCatAPIKey, required for subscriptions. The shared secret from your backend gives you secretKey, and the URL of your deployed backend gives you productionURL, and both are needed for the AI features. A Brandfetch key gives you brandfetchAPIKey, which is optional and only used for store logos.

Then open the project and run it.

   open SpendSmart.xcodeproj

The backend you have to bring yourself

The note about the backend is the most important paragraph in the README for anyone evaluating this project, so it is worth taking slowly.

AI receipt scanning, chat and insights call a small backend service, described as Express on Vercel using Gemini and Mistral OCR. That backend is not included in this repository. The app builds, runs and signs in without it, but you need to point productionURL, or a local http://localhost:3000, at your own backend that implements the same endpoints for the AI features to work.

That is a real engineering task, not a configuration step. You have to write a serverless Express service, deploy it to Vercel, give it the two model providers' credentials, implement the endpoint contract the app expects, and keep a shared secret in sync with secretKey on the device. Nothing in the repository tells you the endpoint shapes, because the server side was never in it.

The upside is that this is also where you can differentiate. The parsing and validation rules, the prompt design, the rate limiting and the cost controls all live in code you own. The downside is that the headline features of the app, the AI scanning, the chat and the insights, are inert until you write that service, and the App Store build you can see is running against somebody else's deployment of it.

It is worth being clear that the free tier's weekly scan limits are a RevenueCat product decision about your own build, not a limit imposed by the open source code.

The directory layout a SwiftUI team would expect

The project structure is the part you will actually read when you fork this, and it is a textbook MVVM split with a design system bolted on.

SpendSmart/
├── App/            # Entry point, API keys, app constants
├── Core/           # Supabase, backend API, local storage, Keychain
├── Services/       # AI, subscriptions, haptics, insights, batch processing
├── ViewModels/     # MVVM view models
├── Models/         # Receipt, Profile, AppState, ChatChart
├── Views/          # Auth, Dashboard, Scanner, Receipts, Chat, Map,
│                   #   Settings, Subscription, Onboarding, Statistics
├── Components/     # Reusable UI: buttons, cards, toasts, skeletons
├── Charts/         # 8 chart types
├── Extensions/     # Color, Font, Animation, UIImage helpers
└── Illustrations/  # Animated illustrations

Three things stand out for a fork. Core/ holds the Supabase integration, the backend API client, local storage and Keychain access, so the credential handling is in one place. Extensions/ carries the Color, Font, Animation and UIImage helpers, which is where the design tokens live, and the contributing guide tells you to reuse the components in Components/ and the design tokens in Extensions/ so that things stay visually consistent. And Charts/ is a separate directory for the eight chart types rather than a folder of view files, which is the sane way to build it.

At the repository root there is also SpendSmartShareExtension/, so the app can receive images shared from other apps, which is how a receipt photo from Photos or Safari reaches the scanner. The root also holds a .gitignore, CONTRIBUTING.md, LICENSE and the Xcode project.

Where this is the wrong project to adopt

The clearest case is a team that wants the AI features on day one. The scanner, the dashboard, the charts and the data model are all here, and the part that turns a photograph into structured receipt data is not. Budgeting a week for the app and a month for the server is the realistic plan.

The second case is anything that is not an iOS app. The whole thing is a SwiftUI application targeting iOS 18, with an Apple Sign-In flow, StoreKit 2 subscriptions and a share extension. There is no cross-platform path here, and the AI backend is only worth building if you have iOS clients.

The third case is a team that needs a supported dependency. With no maintainer, no releases and no versioned changelog, you are adopting a snapshot of someone's App Store app. If your roadmap depends on a receipt scanning bug being fixed upstream, that is not going to happen.

The alternative worth naming is not another app, it is a different approach to the same problem. A spreadsheet plus a receipt photo archive requires no server, no keys and no model providers, and for a handful of purchases a month it is entirely sufficient. SpendSmart earns its complexity when the volume is high enough that manual entry stops being reasonable, or when the map and the insights are the point rather than the record keeping.

Editorial conclusion

SpendSmart suits an iOS developer who wants a receipt scanning and expense tracking app they can read, fork and extend, and who is prepared to stand up their own backend for the AI features. It does not suit a non-Apple developer, and it does not suit anyone who expects a turnkey app, since the Express service that does the scanning, chat and insights is not in the repository. Verify first which parts work without a backend, since the README says the app builds, runs and signs in without it, and check the Supabase, RevenueCat and Brandfetch keys you need before starting.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. madebyshaurya/SpendSmart on GitHub
4. README