Senior iOS Engineer

Ozyn is an AI assistant that does real work. It researches, drives a browser, fills spreadsheets, sends email, and pauses to ask permission before doing anything consequential. It runs today on web, Slack and Telegram.

It does not run properly on a phone. That is the single biggest gap in the product, and you would be the person who closes it.

THIS IS OUR FIRST MOBILE HIRE

You own iOS end to end: the architecture, the code, the App Store Connect account, releases, crash triage, and the decision about what stays web and what goes native. There is no mobile team above you or around you yet — you are the start of one.

WHY THE PHONE MATTERS MORE HERE THAN FOR MOST PRODUCTS

Ozyn's core interaction is an approval gate: the assistant works for several minutes, then stops and asks before it sends an email or spends money. Today that question arrives on a screen the user may not be looking at. A phone with a working, actionable notification isn't a nice-to-have for this product — it's the missing half of the core loop.

THE FIRST THIRTY DAYS

We want the app live on the App Store within your first month. That is a deliberately hard target and we would rather say so plainly than dress it up: it means shipping the shell we already have, well, rather than building the app you would design from scratch. The native rebuild comes after, informed by real usage.

• Week one — Revive the shell, decide which of our two web skins it wraps, and put a TestFlight build on every phone at Tipstat, rough edges included.
• Week two — Sign-in working on every path: phone OTP, Google and Microsoft native bridges, and Sign in with Apple, which App Store review requires of us because we offer third-party login. Safe areas and the Dynamic Island handled properly.
• Week three — APNs live end to end: approve or reject a pending agent action from the lock screen, exactly once. Live progress for twenty-minute runs that survives backgrounding.
• Week four — Through App Store review and publicly live, crash-free sessions above 99.5%, and a release process written down so it doesn't live only in your head.

THE PROBLEMS THAT MAKE THIS INTERESTING

• Runs that outlive the screen — showing live progress across twenty-minute agent tasks, surviving backgrounding and dropped connections, and reconciling state without ever showing an invented status.
• Approvals as a first-class mobile object — interactive notifications, idempotent actions, and the design question of how you give someone enough context on a lock screen to safely approve an email they haven't read.
• Handing control back to the human — when our browser agent hits a login wall it asks the user to take over the session. On a desktop that's a window. On a phone it's an open design problem, and yours to answer.
• Voice as a real input, on Indian mobile networks, with honest offline states and no silent data loss.

WHAT WE'RE LOOKING FOR

• 5+ years building iOS, with at least two apps you shipped to the App Store and then maintained — through review rejections, OS upgrades and crash reports, not just to a v1.
• Swift and SwiftUI in production, and enough UIKit to know when to reach for it.
• Push notifications done properly: APNs, notification service and content extensions, actionable notifications.
• Comfort with a web view and a JS bridge. Version one wraps our web app. If that offends you on principle we're not a fit; if you can make a hybrid app feel genuinely good and then argue for what should go native, we are.
• You've owned releases: certificates, provisioning, App Store Connect, and at least one rejection you talked your way through.
• You write clearly. You'll be specifying backend work for people who aren't mobile engineers, and that specification is most of the coordination this role needs.

Helpful, not required: real-time and WebSocket-heavy clients, Firebase Auth, accessibility as a habit rather than a retrofit, and a view on whether Android should be native or cross-platform next year.

Probably not a fit if you want a defined backlog and a mobile team around you, you won't touch the web codebase, or you want to work remotely. This role is on-site in Bengaluru because the coordination is the job.

HOW WE INTERVIEW

Four conversations — an intro call, a teardown of an app you built, a practical session where you tell us how you'd get our actual situation to the App Store in a month, and a team and founder conversation. No algorithm puzzles, no unpaid take-homes. We aim to decide within two weeks.

To apply, send a note with links to apps you've shipped — tell us which one you're proudest of and what you'd do differently now.