Senior iOS Engineer

TL;DR

• We build Atlas: a brain-tracking wearable and the full software stack behind it. The iOS app is the product surface — it pairs the device, streams the brain data, and turns it into something a person understands.
• You'll own features end-to-end: from the BLE stream coming off someone's head, through the app architecture, to the SwiftUI screen they tap every morning.
• Stack: Swift 6, SwiftUI, TCA, Swift Concurrency, CoreBluetooth, a Tuist-modularised workspace, snapshot-tested, shipped through GitHub Actions.
• This is not a wrapper around a REST API. Real hardware, real signal, real BLE edge cases, DFU firmware updates in-app.
• If you also happen to be deep in BLE/Rust or iOS release engineering, you're the unicorn we don't dare hope for — read the section below.
• The bar is high. Small team, real ownership, no passengers.

Who we are

Atlas is a brain-computer interface you can actually wear. Real hardware streaming real brain activity, an iOS app people use every day, and a machine-learning pipeline that turns that signal into something meaningful.

This is not a CRUD app with a nice design system on top. The problems are harder, the stack is deeper, and the code you write talks to a physical device sitting on someone's head. We're a small software team moving fast across the whole system — firmware-adjacent BLE all the way up to the screens our users live in.

And here's the part that matters if you've watched thin software wrappers get commoditized by every new model drop: our moat is physical. Proprietary hardware, a real signal no one else has, and years of R&D you can't prompt your way around. An AI can rebuild a habit-tracker app in a weekend — it can't build a wearable that reads your brain. This is a hardware company shipping a genuinely new product. We're not a feature waiting to be absorbed. We're here to stay.

What you'll build

You'll own vertical slices of the app, not tickets. A typical piece of work runs the full depth of the client:

• The screen — SwiftUI, in a TCA feature module, snapshot-tested.
• The state — a reducer that survives a device disconnecting mid-recording, an app backgrounded halfway through, and a user who force-quits.
• The device — CoreBluetooth via our own async-stream BLE package: scan, connect, configure, record, push firmware over DFU.
• The data — recordings uploaded to the backend, results streamed back over SSE, insights rendered in charts.

Concretely: Benchmark, Insights, Rituals, Device Pairing, Positioning, Firmware Update.

Who we're looking for

• Senior. You've shipped iOS apps real people use, ideally at an early-stage startup where you owned a lot with little scaffolding. App Store and GitHub links beat CV bullets.
• Deep in modern Swift. Swift 6 and strict concurrency don't scare you — actors, Sendable, @MainActor, AsyncStream, and a data race you've debugged on a real device.
• Architecture-literate. You've worked in a unidirectional/reducer architecture in a modularised codebase, you model state so impossible states can't exist, and you inject dependencies instead of reaching for singletons. We're on TCA; if you come from another discipline, you'll pick it up fast.
• Comfortable near the hardware. Flaky connections, background modes, byte-level parsing — or an appetite for them. Half our hardest bugs have no local repro, just logs and a user who says "it stopped," and you're the person who reads them instead of guessing.
• You build products, not code. You care how the screen feels at 7am on a cold morning with a half-charged device, not just whether the diff is clean.
• High IQ, high energy, high integrity. You raise the bar and you're good to work with.

Our stack (so you can self-screen)

• App: Swift 6, SwiftUI, The Composable Architecture, swift-sharing, async/await + AsyncStream, iOS 17.6+.
• Modularisation: Tuist-generated workspace, ~50 SPM modules, mid-flight extraction out of a flat monolith.
• Device: CoreBluetooth through our in-house BLE package — async streams, a custom chunked transfer protocol, in-app DFU firmware updates, and hyperscanning across several headsets at once.
• Shared libraries: semver'd internal SPM packages we own and release ourselves — design system, charts, logging.
• Testing & CI: Swift Testing, snapshot testing on a pinned baseline, XCUITest E2E, Periphery as a dead-code gate, GitHub Actions on self-hosted Mac runners, TestFlight and Firebase App Distribution.
• Services: Stytch auth, Firebase, Mixpanel, Intercom, SSE against a FastAPI backend.
• Nearby, if you're curious: the device protocol also has a Rust core and an Android sibling app. You don't need to touch either — but people who want to, do.

If most of that makes you lean in rather than glaze over, we should talk.

The unicorn — if the stars align

We're not counting on this. But once in a while someone shows up carrying real depth in one of the two layers either side of the app. If that's you, you'd take a whole layer off our plate — lead with it.

• BLE, binary protocols and Rust. Production CoreBluetooth stacks, framing/checksums/bit-packed configs written against a C firmware source of truth, custom OTA with verification and resume, and Rust protocol logic shipped into Swift and Kotlin over UniFFI.
• iOS release and CI engineering. GitHub Actions end to end, manual signing and multi-environment builds, generated projects (Tuist), self-hosted macOS runners, and release automation written as tested Python rather than YAML.

Rare combo. If you have it, lead with it.

How we work

• Small team, real ownership. You own your slice end-to-end and are trusted to make calls.
• Ship with discipline. Every change goes through a PR, AI reviews, human reviews when needed, with tests, snapshots and CI green before it merges. Nobody steps on anyone.
• Bottom-up. Initiatives come from engineers, not a management layer. If you see it, you own it.

This role isn't for you if

• You want a narrow lane — "I only do UI" or "that's not my ticket."
• You need rigid structure and a manager assigning you work.
• You ship and walk away. Here you own the outcome, including when it breaks on a user's device at 6am.
• Hardware flakiness frustrates you more than it interests you.
• You're not up for a demanding pace. This is an early team building hard things.