Engineering topic / Jeffrey Monica
iOS, Swift, and device trust
Client applications can report state, but the backend has to decide what it can verify. This collection focuses on how native iOS behavior interacts with authenticated APIs, device-bound keys, and deployment.
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.
Articles and reference guides
Device integrity is not authorization: an App Attest and Play Integrity decision modelHow to separate mobile attestation evidence from identity, request authorization, and server-side replay controls.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.
Try it yourself
Device trust & replay labChange challenge age, replay state, signature verification, request binding, and assertion counters to see which server-side checks fail.Authentication state machineTrigger sign-in, expiry, refresh, revocation, and recovery. See permitted transitions and why recovery must not silently bypass step-up.