Senior iOS / Swift Engineer — On-Device ML + Deterministic, Tested Systems

# Senior iOS / Swift Engineer — On-Device ML + Deterministic, Tested Systems We're building the on-device engine at the core of a consumer product, and we need a senior iOS engineer to own it. This is the technical heart of the system — a long-term, substantial engagement for the right person, and the most important hire on the project. ## What you'd build An engine that takes a stream of recognition readings and turns them into a reliable, live model of a changing state — then drives data-driven responses from that state. Three kinds of engineering meet here: - **On-device ML inference** — running trained Core ML models on a live input stream and building a robust pipeline around their imperfect outputs. - **Deterministic state & logic** — turning noisy, reading-by-reading inputs into a confidence-scored model over time, then applying provable, fully-tested rules on top of it. - **Data-driven content playback** — a templating engine that selects and fills pre-written content based on live state, without repeating itself. **The hard part — and the thing we're really hiring for:** individual readings are sometimes wrong. The engine must never trust a single reading. It builds confidence over many of them, treats disagreement between readings as uncertainty rather than guessing, and tracks state region-by-region so a gap in part of the input doesn't blind the whole system. If you've built something that stays reliable on top of unreliable inputs, that is exactly the experience we want. ## Hard requirements (non-negotiable) - **Senior Swift** — real depth: Codable, generics, async/await, Swift packages. Not someone learning Swift on the job. - **Core ML in production** — you have integrated and run trained models on a device and understand the memory and performance side. (Running models is the requirement; training them is a bonus.) - **Fully offline during a session** — zero network calls. This is both a privacy guarantee and a hard architectural rule. (Content updates happen between sessions, never during one.) - **Runs on modest hardware** — must perform on an iPhone 11 / 12 class device, for hours, with no thermal throttling and no battery drain. Real performance discipline required. - **Deterministic and tested** where it counts — the logic and playback layers must be reproducible and covered by tests. ## Please read before applying - There is **no large language model** anywhere in this system. The content is pre-written and played back by a deterministic templating engine — not generated live. If your instinct for the responses layer is to drop in an on-device or cloud LLM, this is not the right role for you. - This is **not** a cross-platform job. No Flutter, no React Native. Native Swift only. - This is **not** a "call a cloud AI API" job. Everything runs natively, on-device, deterministically. If your AI experience is entirely cloud API calls, this role is the opposite of that. ## Strong pluses - On-device computer vision familiarity (Vision framework, turning image data into structured readings). - Game development, simulation, robotics, or other serious deterministic-systems background. - Plugin systems, content pipelines, or data-driven engine architecture (you've built a system where non-engineers add content without touching engine code). - Dynamic text, dialogue, or localization-engine experience. ## How to apply — please answer these in your proposal Skip the generic pitch. I can tell, and it tells me nothing. Instead, answer these four questions **in your own words** — short and concrete is better than long and polished. Honest answers from real experience are what I'm reading for, so please write them yourself rather than having a tool do it; I'm hiring your thinking. **1.** You get one recognition reading every few seconds, and individual readings are sometimes wrong. How do you build a reliable picture of the overall state from unreliable readings over time? Tell me how you'd actually structure it. **2.** You need a recognition model plus a multi-hour, continuously-running inference loop to fit inside an iPhone 11's memory and heat budget. What do you measure first, and what do you cut first when it doesn't fit? **3.** Briefly: describe a real system you built where correctness *had* to be provable — or where you made something reliable on top of unreliable inputs. What was the problem, and what did you actually do? (One you can point to or talk through in a call is ideal.) **4.** Have you shipped an app that ran a Core ML model on-device? Name it (or describe it), and tell me in one or two sentences how you handled the model's memory and performance cost. A note on what good looks like: I'm looking for specifics — what you'd profile, where you'd cut, a time you got a CPU-vs-GPU or memory call *wrong* and how you knew. Vague reassurance that you "optimize for performance" is a pass-over. A short, plain, real answer beats a confident generic one every time. ## The shape of the engagement This starts with a **small, paid proof-of-concept** that tests the make-or-break skill on a modest device — nothing product-specific, just the core of the work — before any larger commitment. If that goes well, this becomes the most substantial and longest engineering relationship on the project. I'd rather pay for proven seniority and a track record of shipped, tested, on-device work than gamble on someone unproven. If this is the kind of careful, provable, on-device systems work you actually enjoy, I'd like to hear from you.