- Provide intraoperative technical support across 8 operating rooms, including Stryker endoscopy towers, cameras, instruments, video setup, troubleshooting, and equipment functionality.
- Work in the room with surgical teams through full procedures, keeping the endoscopy technology running so cases move without friction, and stepping in fast on configuration, escalation, or troubleshooting when it is needed.
- Support case readiness by making sure equipment, instruments, supplies, documentation, and account-specific needs are ready before procedures start.
- 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.
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.
Selected Work
OpenIntelligence
An open-source iOS/iPadOS/MacOS App with an agentic reasoning loop built around Apple's 3B-parameter foundation model. Shipped on the App Store with StoreKit, with paying users
Why: I wanted to see what Apple's 3B model was capable of. It became an obsessive engineering challenge to make it agentic and bypass the 4,096-token context window Apple's foundation model has, so I built a loop capable of ingesting and querying documents of any size or complexity. Honestly, it seemed impossible for a 3B parameter model to run a full reasoning and retrieval pipeline in airplane mode, but I wanted to prove it was possible, and I did.
Private Cloud Compute routing: Since the WWDC26 FoundationModels announcements, I built the routing layer for Private Cloud Compute, opening a 32K-token window for massive documents. Apple gates PCC behind a developer entitlement, and mine is pending approval. So I engineered runtime entitlement detection that keeps every query fully on-device until it is granted. Working inside that constraint made the local pipeline better.
Neural Retrieval & Local Embeddings: To keep files fully secure, I built a zero-dependency retrieval engine using SQLite FTS5 and Apple's Accelerate framework. To push performance further, I recently integrated SIMD4 and threadgroup-level Metal pipelines, driving a 4x speedup in local vector math across the CPU, GPU, and Apple Neural Engine (ANE) to ensure massive document matching feels instant and never leaves the app.
Smart Context: I built a filter that re-orders the retrieved document pieces so the most important info is placed at the very beginning or end where the model pays the most attention, preventing it from getting 'lost in the middle' of long documents.
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: Small, on-device models can do incredible work. The hard part was OCR, chunking, SQLite FTS5, vector search, context packing, citation checks, defining specific quality modes (Standard, Deep Think, and Maximum), preventing file corruption with atomic writes, building adaptive ingestion pipelines to scan page complexity, and an agentic recursive reasoning loop that stitches together multiple sessions to overcome the 4,096-token limit and answer exhaustively.
OpenClinic
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 hospital 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.
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 Completions 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 securely read and update Gmail, Google Calendar, Dropbox, Notion, and Apple reminders.
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.
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 OCR 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 and Vision OCR. It extracts text from PDFs, DOCX files, and raw photos, 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.
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.
What the Work Looks Like Over Time
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.
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.
iOS Mobile Systems
Building native Apple apps around files, data, auth, state, local storage, and release details.
Model APIs, Tools & Retrieval
Working across model APIs, local models, vector stores, tool calls, OCR, and source-backed answers.
Work Context
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.