Gunnar Hostetler

I build AI-native iOS apps. Four are on the App Store.

The rest of my time, I'm in the operating room

I'm an OnSite Specialist at Stryker, supporting Stanford surgical teams on site at the VA Palo Alto.

1,500+Downloads
Since 2024iOS App Development
4+ YearsOperating Room experience
View Selected WorkGet In Touch

Try OpenIntelligence on its sample documents

Pick a question

A pipe burst in my kitchen. Am I covered?

  1. Added 10 sample documentsindexed on the iPhone · 5 min 6 s
  2. Searched by meaning and keyword127 candidates merged
  3. Wrote it with Apple's on-device model9.7 s from send to answer

Yes, sudden and accidental discharge of water from a plumbing system, such as a burst pipe, is covered under Coverages A and C subject to the all-perils deductible S1, S13. Damage from a leak that continued over weeks or months is not covered S1, S14.

In the document

Sudden and accidental discharge of water from a plumbing system, such as a burst pipe, is covered under Coverages A and C subject to the all-perils deductible. Damage from a leak that continued over weeks or months is not covered.
Home Insurance Declarations 2026 · Notes on water damage
How it found this
Library
Home: 10 made-up sample documents, read, split into 117 passages and indexed on the iPhone, kept Local Only. The import took 5 min 6 s in the Simulator on Oct 1.
Embeddings
all-MiniLM-L6-v2, 384 dimensions with mean pooling, run on the device through Core AI.
Search
Hybrid: vector search by meaning and BM25 by keyword, merged with reciprocal rank fusion. 127 candidates for this question.
Answer
Apple's on-device model, through the Foundation Models framework. This run took 9.7 s by the app's own timer.
Recorded
OpenIntelligence 5.5 (build 483) built for the Simulator with one change: the four switches that keep Apple's model off in the Simulator are flipped, so it runs there. iPhone 18 Pro Max Simulator on iOS 27.0, on my MacBook Pro (M3 Pro), Oct 1 (the import) and Oct 2, 2026 (the question).

Recorded in a demo build of OpenIntelligence 5.5 in the iPhone Simulator on my Mac, Oct 1 and 2, 2026 · made-up sample documents · Every question I asked it, misses included

Selected Work

OpenIntelligence

5.5 · Sep 30, 2026
Flagship

An open-source private document intelligence app for iPhone, iPad, and Mac. It turns files and media into searchable libraries, answers with inspectable citations, and shows which execution route actually ran.

Answers on your device, or on Apple Private Cloud Compute after you approve what is sent.

Why I built it

When Apple opened its on-device foundation model to developers at WWDC 25, I had to see how far I could push it. The first useful query ran straight into the model's tiny 4,096 context ceiling.

What makes it tick

  • I kept tearing at that problem until the app could carry evidence across fresh reasoning sessions, cite its sources, and refuse an answer when its critical checks fail.
  • Parsing, Vision OCR, indexing, SQLite FTS5 and vector search, reranking, evidence packing, citation checks, and abstention all run on-device.

What it runs on

Apple IntelligenceFoundation ModelsConsent-Gated PCCAgentic Reasoning LoopVision OCRSQLite FTS5

Why: I wanted private document search that did more than produce a confident paragraph. I wanted to ask a question, inspect the evidence behind the answer, and know whether it ran on my device or used an Apple-managed route. That became OpenIntelligence: a native document workspace built around retrieval, citations, verification, and explicit execution policy.

Private Cloud Compute routing: Version 5.5 decides where final synthesis runs only after retrieval, when the evidence and real context size are known. On iOS and macOS 27 a long evidence-heavy request uses Private Cloud Compute only after you have seen how much would be sent and why, and given permission; on older systems every route resolves on-device. Retrieval and verification stay local, and every answer carries a route badge.

Local retrieval & verification: Parsing, Vision OCR, indexing, SQLite FTS5 and vector search, reranking, evidence packing, citation checks, and abstention all run on-device. The app still works in airplane mode through its on-device answer path and does not require an account or API key.

More than PDFs: The ingestion pipeline handles Office documents, spreadsheets, presentations, notes, scans, code, images, audio, and video, then keeps those different sources searchable inside the same private library.

Building in the Open: Since releasing it, I’ve opened up the project to the public. To manage the workflow, I set up a single-source-of-truth Notion roadmap and built custom agentic skills, meaning AI assistants can now log bugs and add features to the roadmap directly from the terminal as I build.

What I learned: The model call is the easy part. The real work is getting the right evidence, preserving source structure, handling ugly files, refusing unsupported answers, and making the whole route visible enough that a user can verify what happened.

Deep DiveApp StoreGitHubMac App StoreInteractive ShowcaseProduct Site
The Atlas, in 3DMac
Straight from the recipeMac
There's no serverMac

OpenManual

1.4 · Oct 1, 2026

Scan or photograph a label, identify the device, review the public manuals and companion documents that may fit it, then keep only the useful PDFs locally with source-backed answers.

No OpenManual server. No account. No API key. Camera frames and imported PDFs stay on the device.

Why I built it

I literally save every single manual I get for any device I own, and finding the right one for the exact model in front of me has always sucked. So I built OpenManual.

What makes it tick

  • If there's a UDI on the label, AccessGUDID resolves it to the exact device. If there isn't, OCR reads the plate, the app ranks the likely candidates, and asks one question to narrow it down.
  • I built a Python backend and a Cloudflare search proxy for this, then deleted both on purpose. Shipping solo means no server and no key in the binary.

What it runs on

Foundation ModelsVision OCRVisionKitPDFKitAccessGUDIDopenFDA

Why: I’ve lost count of the times I’ve been standing in front of a piece of equipment, at work or at home, with no idea exactly what model it was or where its manual went. I’ve replaced things that probably still worked because figuring that out was more hassle than buying a new one. In the OR the same problem has real stakes: you need the instructions for that exact device and revision, not something close. So I built the step that comes before OpenIntelligence. Point the camera at the thing, figure out exactly what it is, find the document that actually applies to it, then ask that document your questions.

Identity first: If there’s a UDI on the label, AccessGUDID resolves it to the exact device. If there isn’t, OCR reads the plate, the app ranks the likely candidates, and asks one question to narrow it down. The full UDI carrier never leaves the phone, only its catalog-level identifier does.

Finding the manual without a server: I can’t ship a search API key inside an app, and I didn’t want a server to babysit. So the app searches public search engines itself, falls back to a web search in Safari, and because it registers as a PDF handler, “Open in OpenManual” shows up in the share sheet. That reaches documents sitting behind a manufacturer login that no crawler ever could.

On-device from there: PDFKit reads the document, chunking and retrieval stay local, and the answer is quoted from the document with page-level citations. A found PDF is a possible match, not a guarantee, so you confirm it before it’s saved to that device.

Medical boundary: It can locate and quote documentation. It does not diagnose, recommend treatment, or pick patient-specific settings. Medical devices are the first vertical and keep the strictest rules; appliances, tools, and vehicles start from the same job.

What I learned: I built a Python backend and a Cloudflare search proxy for this, then deleted both on purpose. Shipping solo means no server and no key in the binary, and honestly the app got simpler for it. Scan-to-identity works end to end against the live APIs; grounded answering over the bound document was in place before the first public build.

Deep DiveApp StoreProduct Site
OpenManual App Store screenshot 1OpenManual App Store screenshot 2OpenManual App Store screenshot 3OpenManual App Store screenshot 4
Arthrex AR-6480 pump, screen recording on my iPhone, serial blurred

OpenResponses

2.9 · Oct 2, 2026 · open source

An iOS/iPadOS App built around the OpenAI Responses API.

Native computer use and MCP connectors, passed App Review on the first try

Why I built it

OpenAI announced they were deprecating the Assistants API, and my immediate thought was "they're killing my first app!" (OpenAssistant), so I opened VSCode with OpenAssistant in one window and OpenResponses in another, using LLMs to help swap out all the endpoints and rebuild the flow on the new Responses endpoints.

What makes it tick

  • I built a custom streaming interface that translates browser tool-calls (clicking, typing, scrolling, screenshots) into a native Swift environment, letting the model navigate web pages in real time.
  • I integrated Model Context Protocol (MCP) connectors and Apple EventKit, allowing it to search and read Gmail, Google Calendar and Dropbox, connect to Notion, and create Apple Reminders and calendar events.

What it runs on

Responses APIMCP ConnectorsComputer UseEventKit ToolsSSE StreamingRealtime Voice

Why: OpenAI announced they were deprecating the Assistants API, and my immediate thought was “they’re killing my first app!” - OpenAssistant - so I opened VSCode with OpenAssistant in one window and OpenResponses in another, using LLMs to help swap out all the endpoints and rebuild the flow on the new Responses endpoints.

Computer Use: I built a custom streaming interface that translates browser tool-calls (clicking, typing, scrolling, screenshots) into a native Swift environment, letting the model navigate web pages in real time.

Connected Tools: To give the model access to the real world, I integrated Model Context Protocol (MCP) connectors and Apple EventKit, allowing it to search and read Gmail, Google Calendar and Dropbox, connect to Notion, and create Apple Reminders and calendar events.

Version 2.9 (October 2026): You can see what the assistant is doing while it uses its tools. Each tool step shows a spinner while it works and says Completed or Failed when it’s done, steps go by their real names, and the Code Interpreter step shows the Python it ran. A chart from Code Interpreter shows once, and each file it makes is listed once. It builds on 2.8’s GPT-6.1 Sol, new OpenAI models that show up in the menus on their own, Python that runs on the phone after you approve each run, which passed App Review on the first submission, and search by meaning with Apple’s on-device language model.

What I learned: Because of all the App Store Connect rejections on my first two apps, I learned exactly what reviewers looked for. I got this one passed through review without a single rejection on the first pass.

Deep DiveApp StoreGitHubProduct Site
OpenResponses App Store screenshot 1OpenResponses App Store screenshot 2OpenResponses App Store screenshot 3
A spending chart from Code Interpreter, the run at 12x

OpenCone

3.1 · Oct 2, 2026 · open source

An iOS App that meshes the OpenAI Completions API and the Pinecone API together to form a RAG client for testing multi-index document search, later updated to use the Responses API.

The Pinecone iOS client that didn't exist, with on-device PDF and OCR chunking

Why I built it

When I started getting into deeper development with OpenAssistant, the app would start losing context during large document queries. I looked up vector databases, found Pinecone was the standard, and realized they didn't have an iOS app, so I decided to build one.

What makes it tick

  • To feed documents into Pinecone, I built a local parser using Apple's PDFKit and Vision.
  • To prevent the app from lagging or getting stuck when a server fails, I built a network circuit breaker. If Pinecone fails twice in a row, the app automatically pauses requests and lets the user know immediately.

What it runs on

Responses APIPinecone REST APIPDFKitCircuit BreakerSpeech RecognitionSSE Streaming

Why: When I started getting into deeper development with OpenAssistant, the app would start losing context during large document queries. I looked up vector databases, found Pinecone was the standard, and realized they didn’t have an iOS app, so I decided to build one. I wanted to query multiple indexes and namespaces in a single chat thread, which was something the OpenAI Assistants playground was limited in doing.

On-Device File Reader: To feed documents into Pinecone, I built a local parser using Apple’s PDFKit and Vision. It extracts text from PDFs, text and code files, and reads the text in images with OCR, automatically chunking and converting them into embeddings on the fly.

Network Safety: To prevent the app from lagging or getting stuck when a server fails, I built a network circuit breaker. If Pinecone fails twice in a row, the app automatically pauses requests and lets the user know immediately.

What I learned: I took the backend from OpenAssistant and swapped out the storage layer for Pinecone. Honestly, in retrospect, the initial interface looked awful, but I later rebuilt it with the Responses API and clean embeddings. Getting this on the App Store was a personal milestone.

Deep DiveApp StoreGitHubProduct Site
OpenCone App Store screenshot 1OpenCone App Store screenshot 2
OpenCone 3.1, filmed in the iPhone Simulator on my Mac, sample documents

OpenClinic

Prototype

An EHR prototype iOS/iPadOS App for exploring local-first retrieval around chart-shaped patient data

SMART on FHIR over OAuth, pulled into on-device SwiftData, answered with citations

Why: I wanted to see what would happen if I applied the same OpenIntelligence engine to clinical information. OpenClinic is the prototype where I tested it against chart-shaped data (not production medical software).

Clinical Data Sync: I integrated the SMART on FHIR standard using secure OAuth flows (ASWebAuthenticationSession). This lets the app connect directly to SMART sandbox endpoints and securely download structured Patient, Condition, and Medication resources.

Local Storage: Instead of sending patient histories to a cloud database, the app parses and maps the incoming FHIR clinical resources directly into local SwiftData schemas, keeping health records private and offline.

Current State: I reused the same agentic reasoning loop from OpenIntelligence, wired up SMART on FHIR discovery and OAuth (ASWebAuthenticationSession) to pull demo Patient, Condition, and MedicationRequest resources into a local model. It’s surprisingly good at finding relevant information in the chart and answering questions with citations, but the current data is too limited to be more than a demo of the retrieval and reasoning patterns. The next step would be to connect it to real FHIR endpoints and see how it handles the messiness of real clinical data, which comes with a multitude of complexities.

Deep DiveGitHubProduct Site

OpenAssistant

Retired

My first shipped iOS App, built around the OpenAI Assistants v2 API. Engineered to handle vector stores, document uploads, active run polling, and strategy-driven local file preprocessing.

Where I learned to ship: App Store approval after 30 rejections taught me the reviews

Why: When ChatGPT-4 first came out, it BLEW my mind. I was working with tons of medical documentation at Stryker and using it to learn fast, but their official app was slow, crashed, and limited me to 5 files at a time. I got curious about their API, saw people making wrappers, and thought, why would I pay for someone else’s app when I can just build my own?

File Formatting: OpenAI, at the time, would reject standard iPhone files (like live HEIC photos or RTF documents) when uploaded. To fix this, I set up a local conversion system that automatically turns these files into standard JPEGs and plain text on the device before sending them off.

“Is it done yet?”: Since OpenAI’s Assistants API didn’t respond instantly, I built a timer system that checks in with OpenAI every 2 seconds to see if the assistant is done thinking, so the app can display the answer the second it’s ready.

What I learned: Making an iOS app isn’t easy. I built it by copying OpenAI API references into text files, uploading them to a playground vector store for context, and copying and pasting the red errors back in to get corrected code. I repeated this until it worked, spent $99 on a developer account, and finally got it on the store after being rejected upwards of 30 times because they kept telling me everything that was wrong with my app.

Where it stands: Archived. The Assistants API it was built on is shut down now, which is the whole reason OpenResponses exists. It’s no longer on the App Store, and I’m not developing it further. Everything I learned getting this one approved went into the four apps after it.

Deep DiveGitHubProduct Site

Repo History

What the Work Looks Like Over Time

Synced · Oct 3, 2026
Sep '24OctNovDecJan '25FebMarAprMayJunJulAugSepOctNovDecJan '26FebMarAprMayJunJulAugSep
Less
More
2419all-time commits
2060in the last year
12day current streak
38day longest streak
3.2average per day

How I Build

I operate with a childlike curiosity and high energy. I look for solutions to inefficiencies even when I don't consciously want to, and build tools to understand things that go beyond what I already know.

I've wanted to build software for a long time, but I didn't have a way to get from “I wonder if this could exist” to actually making it exist.

LLMs changed that for me. I leverage AI and RAG architectures to build the working foundations of my apps through the literal ingestion of complex API documentation. Once the core foundation is set, I build the real structure around it and just go nuts filling in the gaps.

Right now, I'm using Google Antigravity, Claude Code, and OpenAI Codex. Most nights are me building because I can't not. If it's something new, I feed them docs, test what comes back, and figure out how to make it work. Once it works, the sky is the limit.

My process is built on relentless, iteration-driven execution.

I use AI as an implementation partner to move through code, documentation, errors, and debugging fast enough to stay with the idea. I still decide what the thing should do, how it should feel, and whether it's actually useful. When models hand me something, it's hardly gold, and the whole job is knowing when plausible isn't true.

I've learned to just roll with the chaos of building, and because of that, I have created things I never thought I'd be able to.

At the end of the day, the things I make still have to work. They have to run, handle real inputs, survive weird edge cases, and function well for the reasons they were built in the first place. Honestly, I think that standard comes from the OR. I spend my days making sure technology holds up through a whole procedure, where there's no room for it to just break, and somewhere along the way that became my baseline for "done" everywhere else too.

Work Context

OnSite Specialist

Stryker | VA Palo Alto Health Care System

Aug 2022 to Present
8
Operating rooms
8
Surgical specialties
4,800+
Surgical cases supported
1,500+
Instruments integrated
  • I'm one of three specialists who run the account, with no Stryker management on site.
  • I take care of the endoscopy equipment across 8 ORs, the towers, the cameras and the instruments.
  • I work directly with Stanford surgeons from General, Urology, GYN, ENT, Neuro, Ortho, Thoracic and Cardiac.
  • I set up the rooms for them, positioning the towers and providing the surgical instruments, cameras and scopes.
  • I stay in the room with the surgical team for entire cases, on the device and instrument side of live surgery, keeping the endoscopy technology running from setup and configuration through the end of the procedure.
  • I keep the account healthy across procurement, vendor coordination, inventory, par levels, schedule-based forecasting, repairs, replacements, and equipment availability.
  • I integrated 1,500+ surgical instruments into the Censitrac instrument tracking system.
  • I coordinate daily with surgeons, nurses, scrub techs, anesthesiologists, sterile processing, biomedical engineering, vendors, and hospital staff.
  • I pushed for and got the team Government Contractor PIV clearance, which is how we have VA intranet access and va.gov accounts.

Get In Touch

Contact

I'm always open to connecting! Whether it's about my apps, what I used to build them, or just to chat about similar curiosities, reach out here or through the links below.

linkedin.com/in/gunnar-hostetler
x.com/Gunzeroni

Or email me directly at Gunnarguy@me.com.