SnapRight
Take a photo of a benefits letter and get it back in plain language. Then a short set of questions tells you what else you might qualify for, and the apply button sends you to your own state's portal rather than a federal page that cannot help you.
It is for seniors and low-income families dealing with SNAP, Medicaid, Medicare, WIC and TANF. It is not affiliated with any agency and it decides nothing. It explains a letter that was written to be hard to read.
What leaves the phone
The same rule runs through the rest of it. Nothing in the app is demo data, and nothing shown to a user was invented for the screenshot. Every result traces back to something that was actually read off their letter or answered by them. no placeholder numbers, anywhere
Degrading well
Eligibility could have been a spinner waiting on a model. It is not, because the people using this are on bad connections and the answer matters to them.
The rejection
App Review turned version one down under guideline 5.1.1(v). An app that lets you create an account has to let you delete it from inside the app, and mine did not.
There were three ways out. Delete the row from the client, which leaves the auth user behind. Send people to the website, which is what the guideline exists to stop. Or write a server function that actually removes the account and call it from the app.
I wrote the function. It was the most work of the three and the only one that makes the sentence in the settings screen true.
Where it is
Auth and data sit on Supabase with row-level security, so the only credential in the repo is the anon key, which is meant to be public and is useless without the policies letting it through. No service key, no model keys. Those are server-side secrets.
The web app is a single self-contained file with no build step and deploys by dragging a folder. That file is what sits at snapright.net. The iOS side is a native SwiftUI port with its own dependency-free client, tokens in the Keychain and an optional Face ID lock.
It is on the App Store.