- Provide intraoperative technical support across 8 operating rooms, including Stryker endoscopy towers, cameras, instruments, video setup, troubleshooting, and equipment functionality.
- Serve as the first on-site Stryker resource when a room needs fast troubleshooting, configuration help, escalation, or readiness support.
- 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.
Surgical Technology Support + iOS Development
Gunnar Hostetler
I work as a Stryker OnSite Specialist at the VA in Palo Alto, providing intraoperative technical support on Endoscopy systems for Stanford surgical teams.
In my free time, I build iOS apps
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 Flagship Project
An open-source iOS/iPadOS/MacOS App with an agentic reasoning loop built around Apple's 3B-parameter foundation model. Shipped globally with StoreKit, generating $450+ in in-app purchases
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. Since the WWDC26 FoundationModels announcements, I've re-architected the app to dynamically route to Private Cloud Compute—giving it a 32K token window for massive documents while keeping everyday queries local.
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
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.
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.
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.
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.
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.