Felt

Screens and views never build URLs. They go through ViewModels to Repositories and singleton Services, and those Services funnel HTTP through exactly one APIEndpoint enum and one NetworkService. The two deliberate exceptions are SSE chat, which gets its own SSEHandler, and multipart audio upload for transcription. Affirmation content itself never touches the network: it ships as bundled SQLite databases copied into the Documents directory on first launch, one database per language.

Sending a message to Mentora shows how the pieces connect: the ViewModel calls SSEHandler with a Firebase anonymous ID token, the device's Device-ID from the Keychain, and a P-ID header derived from RevenueCat's entitlement. The backend streams the response back over text/event-stream: token deltas render with a deliberate 50ms delay per chunk for a readable typing cadence, while the same stream carries credit-balance updates, gifted-credit events, emotion state, and follow-up suggestions in-band. An HTTP 403 with an out-of-credits body routes straight to the paywall; anything else retries up to three times before giving up.

The parts that fought back.

Stopping an attestation retry loop

A transient network or verification failure during App Attest could, naively, trigger endless re-registration. DeviceAttestationService branches on the specific error: network or verification failures return the already-stored device ID instead of retrying, and only a missing key or an invalid challenge triggers actual re-registration. Concurrent verification calls also coalesce into a single in-flight task, with two retries and a one-second backoff, instead of each caller kicking off its own.

A gifted-credits toast, firing twice

The backend's credit-gifting event shows up on two different chunks of the same SSE stream: an early gifted-credit event, and again on the stream's completion event. A naive handler fires the celebration toast twice for one gift. The fix is a per-stream guard: once the notification has posted for a given stream, it doesn't post again.

A SwiftUI layout feedback loop

Commit bd939fa, shipped 2026-04-23, fixed a real feedback loop in the calendar preferences and chat geometry. Self-referential geometry and preference updates were triggering re-layout based on their own output, thrashing the layout pass instead of settling. It's the kind of bug that's invisible in a code review and obvious the moment you watch the frame rate.

Automated test coverage is effectively zero: the test targets are Xcode's default empty stubs, with no coverage of the attestation, credits, or SSE-parsing logic that actually matters most. The operational defaults are more considered: image caching is capped at 200MB on disk and 100MB in memory; chat renders each streamed token with a deliberate 50ms delay and retries a failed request up to three times; network timeouts are 30 seconds for REST calls and 90 seconds for audio transcription upload; and the credits balance is fetched with in-flight coalescing and a 2-second snapshot cache so app launch doesn't fire duplicate requests. CI wraps builds and deploys in three retry attempts with a 60-minute timeout.

An account-less app's real threat model.

Every request carries a Firebase anonymous ID token and an Azure function key. Device integrity is the harder problem, and it's handled directly rather than assumed:

• Device integrity — answered by Apple App Attest: a challenge, a Secure-Enclave-generated non-exportable key, an attestation object, and a server-issued Device-ID; ongoing requests use fresh assertions over a hash of the request data, not a static token.
• Credential storage — the device ID and attestation credentials live in the Keychain, not UserDefaults; legacy device IDs that predate this design were migrated out of UserDefaults into the Keychain.
• Abuse and cost control — credits are metered server-side per device, a 403 with an out-of-credits body blocks further requests, and an idempotency key on chat and memory-update requests prevents duplicate charges from a retried request.
• Input validation — HTTP status handling is centralized into typed errors, including a dedicated goal-limit-reached case, and transcription rejects empty or unreadable audio before it reaches Whisper.
• Data deletion — a server-side endpoint deletes a device's conversations on request while keeping the device registration itself; the microphone permission string states plainly that audio isn't stored.

The honest gaps: there's no certificate or public-key pinning, so a trusted MITM proxy can still inspect traffic past the Firebase token and function key. The P-ID pro flag is asserted by the client; the server has to independently reconcile it against the actual subscription, or it's spoofable. On the Simulator, or on devices that don't support App Attest, the app falls back to a self-generated, non-attested device ID: functional, but without the hardware-rooted guarantee App Attest exists to provide. And the Azure function key and backend base URL both have hardcoded fallback values compiled into the binary as a Remote-Config-failure safety net, which makes them extractable by anyone who pulls the binary apart. That's a deliberate trade, not an oversight, but a real one.

What I'd tell myself at the start.

• Centralizing auth and headers in one enum and one service pays off as endpoints grow. Past 25 REST endpoints, having exactly one place that assembles the Bearer token, function key, Device-ID, and P-ID header was worth it. The two deliberate exceptions, SSE and multipart upload, show where a single abstraction stops fitting.
• Shipping a metered AI feature on an account-less app means identity and cost design come before UX. Device attestation and a credits ledger had to exist before the chat feature could safely ship at all.
• Near-zero test coverage on high-risk logic shows up later as a tail of same-day fix and revert commits. Attestation loops, credit accounting, and SSE parsing are exactly the paths I'd want targeted unit tests around first, not last.

Still under active development.

Felt was under active development as of its most recent commit, having grown from a simple offline affirmations app into an account-less iOS client with a server-metered AI chat companion. Over 416 commits and roughly three years, the architecture around identity (App Attest), cost control (credits), and configuration (Remote Config) hardened considerably.

Automated test coverage on that same high-risk logic remains thin, and the commit history shows it: a steady cadence of same-day fixes and reverts alongside the feature work. That's the kind of trade a small team makes to keep shipping, and the kind worth naming honestly rather than glossing over.