AI-Native iOS Developer + Surgical Technology Support

Gunnar Hostetler

I build AI-native iOS apps. Four are on the App Store, built around on-device AI, retrieval, and agentic reasoning loops.

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

I provide intraoperative technical support for Stryker at the VA in Palo Alto, in the room with Stanford surgical teams. Every app I've built started as an idea, which led to a question, which led to a doc or two, which led to a prototype, which led to more questions, and so on until it finally worked.

4 iOS AppsOn the App Store

Since 2024iOS App Development

4+ YearsOperating Room experience

View Selected Work Get In Touch

Selected Work

Flagship

OpenIntelligence

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.Version 5.4 on the App Store. Answers on your device, or on Apple Private Cloud Compute after you approve what is sent. Lifetime is 33% off in the US until September 29.

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.4 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.

Read the full story

Specs & Papers:

Apple Foundation Models SQLite FTS5 RAG Survey AIGC RAG Agentic RAG RAG Evaluation RAG Architectures vstash Hybrid RAGdb Edge RAG Engine Research

Apple IntelligenceFoundation ModelsConsent-Gated PCCSwiftUISwiftOn-Device RAGAgentic Reasoning LoopMetal SIMD4BNNS VectorsVision OCRSQLite FTS5

GitHub App Store Mac App Store Interactive Showcase Product Site Deep Dive

OpenManual

Point your phone at a device, appliance, tool, vehicle, or other documented thing. OpenManual identifies the exact unit, finds the manufacturer documentation that applies to that device and revision, and answers "How do I ___?" using only that document, with page-level citations.No OpenManual server. No account. No API key. Camera frames and imported PDFs stay on the device.

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 and Vision read 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.

Read the full story

API Specs:

AccessGUDID API openFDA Device UDI Apple Foundation Models VisionKit DataScanner Apple PDFKit

SwiftUIFoundation ModelsVision OCRVisionKitPDFKitOn-Device RetrievalAccessGUDIDopenFDAStoreKitSwift 6

App Store Product Site Deep Dive

OpenResponses

An iOS/iPadOS App built around the OpenAI Responses API.Native computer use and MCP connectors, passed App Review on the first try

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.6 (September 2026): an API Workbench for editing literal JSON and exploring HTTP, streaming and WebSocket responses, with invalid schemas rejected before sending; a Connections page where MCP providers sign in through the browser with OAuth, 44 catalog entries plus live registry search; voice that keeps listening after the assistant answers; and one shared model catalog for GPT-6 Astra and GPT-5.6 Sol, Terra and Luna, with GPT Image 2 partial previews.

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.

Read the full story

API Specs:

OpenAI Responses Model Context Protocol OpenAI Files Apple EventKit

SwiftUIResponses APIMCP ConnectorsComputer UseRequest InspectorEventKit ToolsFile SearchSSE StreamingAPI WorkbenchOAuth MCP ConnectionsRealtime Voice

GitHub App Store Product Site Deep Dive

OpenCone

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 text chunking

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. It extracts text from PDFs and text files, 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.

Read the full story

API Specs:

OpenAI Responses Pinecone REST API OpenAI Embeddings Apple PDFKit Apple Speech

SwiftUIResponses APIPinecone REST APIPDFKitCircuit BreakerSpeech RecognitionSSE Streaming

GitHub App Store Product Site Deep Dive

OpenClinic

An EHR prototype iOS/iPadOS App for exploring local-first retrieval around chart-shaped patient dataSMART 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.

Read the full story

API Specs:

SMART on FHIR HL7 FHIR Core SwiftData Core ML

SwiftUISwiftDataSMART on FHIRCore MLSQLite FTS5RRFOAuth

GitHub Product Site Deep Dive

archived

OpenAssistant

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 approved 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.

Read the full story

API Specs:

OpenAI Assistants OpenAI Vector Stores Code Interpreter File Search OpenAI Files

SwiftUIAssistants API (v2)Vector StoresRun PollingStrategy PatternNotificationCenterFirebase SDK

GitHub Product Site Deep Dive

What the Work Looks Like Over Time

Synced · Sep 25, 2026

Sep '24OctNovDecJan '25FebMarAprMayJunJulAugSepOctNovDecJan '26FebMarAprMayJunJulAugSep

Less

2159all-time commits

1802in the last year

4day current streak

38day longest streak

2.9average per day

Repo History

A quick visual of how the repos changed over time. Each ring comes from commits, grouped by the kind of work: features, fixes, refactors, and docs or config.

OpenClinic

6m old

59commits

10weeks active

GitHub

OpenIntelligence

11m old

1245commits

44weeks active

GitHub App Store Mac App Store

OpenManual

1m old

198commits

3weeks active

Private repository App Store

OpenResponses

1y 3m old

205commits

28weeks active

GitHub App Store

OpenCone

1y 6m old

227commits

23weeks active

GitHub App Store

OpenAssistant

2y 0m old

225commits

33weeks active

GitHub

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.

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.

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.

What I Use

Surgical Operations & Logistics

Working inside ORs where equipment, timing, sterile process, documentation, and relationships all matter.

Intraoperative SupportHIPAA CompliancePIV Security ClearanceCensitrac Instrument TrackingSurgical Workflow SupportEndoscopy Video SetupAccount-Level Operations

iOS Mobile Systems

Building native Apple apps around files, data, auth, state, local storage, and release details.

Swift / SwiftUISwiftData / CoreDataAppContainer DIKeychain Credentials StoreOAuth / ASWebAuthenticationSessionSecurity-Scoped BookmarksXcode Build ErrorsApp Store Release Flow

Model APIs, Tools & Retrieval

Working across model APIs, local models, vector stores, tool calls, OCR, and source-backed answers.

OpenAI Responses / Assistants APIsGemini APIApple Foundation ModelsCore ML / BNNS VectorsPinecone / Qdrant Vector StoresSQLite FTS5 / RRFMCP Tool ServersTool Calls / Function CallingCode Interpreter / File SearchVision OCR / PDFKit ParsingStreaming Event PayloadsSource & Citation ChecksRecursive Reasoning Loops

Work Context

OnSite Specialist

Stryker | VA Palo Alto Health Care System

Aug 2022 – Present

8
Operating rooms: 1,500+
Instruments integrated: 4+
Years on site

Provide intraoperative technical support across 8 operating rooms, including Stryker endoscopy towers, cameras, instruments, video setup, troubleshooting, and equipment functionality.
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.
Support eight surgical specialties — General, Urology, GYN, ENT, Neuro, Ortho, Thoracic, and Cardiac — working directly with the Stanford surgeons who operate at the VA.
Set the rooms up before cases start: tower positioning, surgical instruments, cameras, and scopes, alongside the supplies, documentation, and account-specific needs each procedure depends on.
Help keep the account healthy across procurement, vendor coordination, inventory, par levels, schedule-based forecasting, repairs, replacements, and equipment availability.
Integrated 1,500+ surgical instruments into the Censitrac instrument tracking system.
Coordinate daily with surgeons, nurses, scrub techs, anesthesiologists, sterile processing, biomedical engineering, vendors, and hospital staff.
Hold Government Contractor PIV clearance with VA intranet access for secure workflows, system changes, documentation, and account-related operational needs.
Work independently in a high-pressure surgical environment where priorities shift constantly and problems require fast, practical judgment.

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