The story
Why it exists and what building it taught me. Written for the homepage card, kept here in full.
Why: The reason is simple, I have this thing where I keep the manual to basically everything I buy, like if it’s a medical device or a household appliance, they typically come with a manual I save because I know at some point I’m gonna have a question about it and I want the actual document.
Identity first: If there’s a UDI on the label, AccessGUDID tells it the exact device. If there isn’t, it reads the plate, ranks the likely matches and asks you one question to narrow it down. The full UDI never leaves the phone, only the part that names the model does.
Finding the manual without a server: There’s no key for a search service inside the app, so it searches the maker’s own site, the Internet Archive and public search engines itself and falls back to a web search in Safari. And because it shows up as Open in OpenManual when you share a PDF, a manual you open yourself behind a manufacturer’s login can get in too, which no crawler ever could.
On-device from there: PDFKit reads the manual, it’s split up and searched right on the phone, and the answer is quoted from the manual with the page it’s on. A PDF it finds might be the one and might not, so you say yes before it’s saved to that device.
Medical boundary: It finds and quotes documentation. It doesn’t diagnose, recommend treatment or pick settings for a specific person. Medical devices got the strictest rules first, and it does the same job for appliances, tools and cars.
What I learned: I built a Python backend and a Cloudflare search proxy for this, then deleted both on purpose, because I didn’t want a server to keep running or a key inside the app. Reading a label all the way to the exact device works against the FDA’s live databases, and answering from a manual you kept was working before the first public build.
