Engineering topic / Jeffrey Monica
iOS, Swift, and device trust
I keep coming back to the gap between what an iOS app says about itself and what the backend can actually prove. These notes explore keys, authentication, and the behavior around that boundary.
Key engineering considerations
Client versus server
Which evidence is signed, what the backend can verify, and why a rooted or instrumented client can still send requests.
Credential lifecycle
Provisioning, key rotation, device migration, recovery and what should happen when proof is unavailable.
Release behavior
Different signing environments, networking conditions, state restoration and failure observability.
Field guides and review checklists
Articles and reference guides
Mobile voice agents: keep the backend in chargeHow I connected Swift and Kotlin clients to agent workflows, built Core ML and TensorFlow Lite integration boundaries, and kept authorization on the backend.Device integrity is not authorization: an App Attest and Play Integrity decision modelA valid App Attest or Play Integrity result cannot authorize a user. I walk through the server decisions separately and test them with synthetic inputs.Mobile session recovery as an explicit state machineModel sign-in, refresh rotation, expiry, step-up recovery, and revocation without creating a hidden authentication bypass.Swift concurrency cancellation is cooperative, not an automatic rollbackHow Task.checkCancellation, child tasks, stale results, and server-side effects interact in an iOS app.Hardening iOS Device Trust Signals Against Hostile ClientsA practical look at building and evaluating device trust signals under jailbreaks, instrumentation, replay, and tampered clients, with emphasis on server-side verification and failure-aware design.