Ios on Lessons learned

Offline login in an iOS or Android app: design it as offline unlock

Tue, 03 Nov 2026 18:00:00 +0100

A product request for “offline login” in a mobile app with a cache of sensitive data (customer invoices, HR records, patient notes, credentials) sounds like one feature. On a phone with no network, nothing can check the password against the server, apply MFA, or learn that the device was revoked yesterday. What the app can do is prove a local factor to a device that was enrolled earlier and release keys for ciphertext already on it:

offline login: authenticate the user, apply policy, authorize data (impossible offline)
offline unlock: prove a local factor, release keys for cached data (what you can build)

I researched how to build the second one on iOS and Android. This post collects the parts that are easy to get wrong: where the password path needs a hardware key, why a biometric prompt without a CryptoObject is only a boolean check, which clock keeps counting while the phone sleeps, and what changes for users who have no password at all. It is longer than a usual post here, because the traps sit in different layers.

What an offline unlock can and cannot prove

A connected sign-in lets the server authenticate the user and the device, require MFA, evaluate current policy and revocation, and send newly authorized data. An offline unlock does none of that. So it must never renew a server session, refresh authorization, or make cached data look current. Label the action “Unlock” in the UI and keep “Sign in” for the server. Show “Last checked” (policy) and “Last synchronized” (data) separately, because a recent local unlock is neither.

The trade-off between availability and revocation is unavoidable. While the device is disconnected, a revocation event cannot reach it, and plaintext it already showed cannot be recalled. A long offline window helps users during outages and travel. It also lets a lost or deauthorized device keep unlocking its cache until the window expires or the device reconnects. Pick a maximum offline age per threat model, make it visible, and apply revocation before any sync or key release at the next connection. Managed users should get an administrator-set finite limit. If you offer an unlimited consumer mode, tell the user that remote revocation and policy changes wait for the next reconnect.

First use of a device is always a connected sign-in. It enrolls the device, downloads the encrypted state, and creates the local unlock material. A device that was never provisioned online must never create offline capability, and a network error must never let you skip a required connected step.

A state machine where a stale device never prompts

Write the states down, so a missing transition shows up in review:

UNENROLLED
 └─ connected sign-in + MFA + policy + initial sync ─▶ LOCKED_CURRENT

LOCKED_CURRENT
 ├─ freshness valid, then valid local factor ────────▶ UNLOCKED
 ├─ successful check-in ─────────────────────────────▶ LOCKED_CURRENT (freshness renewed)
 ├─ freshness expires ───────────────────────────────▶ LOCKED_STALE
 ├─ check-in reports device/user revocation ─────────▶ UNENROLLED
 └─ logout/user removal ─────────────────────────────▶ UNENROLLED

UNLOCKED
 ├─ timeout/background/device lock/manual lock ──────▶ LOCKED_CURRENT
 ├─ successful check-in ─────────────────────────────▶ UNLOCKED (freshness renewed)
 ├─ freshness expires ───────────────────────────────▶ LOCKED_STALE
 ├─ check-in reports device/user revocation ─────────▶ UNENROLLED
 └─ logout/user removal ─────────────────────────────▶ UNENROLLED

LOCKED_STALE
 ├─ successful connected reauthentication/check-in ──▶ LOCKED_CURRENT
 ├─ check-in reports device/user revocation ─────────▶ UNENROLLED
 └─ logout/user removal ─────────────────────────────▶ UNENROLLED

A check-in is any authenticated server call that returns current policy, revocation state, and server time. A background call with a refresh token is enough. If policy also wants full reauthentication with MFA after some maximum age, put that in the policy record, not in app logic.

Evaluate freshness before asking for a factor. A stale device shows the reconnect screen and never runs the password KDF, a PIN check, or a biometric prompt. When the window has expired, a biometric prompt that is bound to fail, followed by a generic “wrong password” error, tells the user nothing about the fix.

Losing one local factor does not change state. When a biometric wrapper is invalidated, or the PIN hits its threshold, delete that wrapper and continue with the others.

Wrap keys; never encrypt data with the password

Use envelope encryption:

Generate a random 256-bit account data key (ADK).
Generate a random key per record and per file and wrap each under the ADK. Do not derive them from the ADK. A derived key can always be derived again, so you cannot destroy or rotate it for one object without rotating the ADK.
Encrypt record fields, search indexes, file metadata, thumbnails, and file content with an AEAD: AES-256-GCM or ChaCha20-Poly1305.
Wrap the ADK once per unlock method: password, biometric, optional PIN, recovery key.
Encrypt the password and PIN wrappers a second time under a non-exportable hardware key that needs no user authentication: Secure Enclave on iOS, Android Keystore on Android.
Put version, algorithm, KDF parameters, key ID, account, object ID, field ID, and purpose into the authenticated data.

The field ID in step 6 looks like overkill until a field moves. If an attacker can swap the bank-account field of supplier record A with that of record B and the AEAD still verifies, the app shows a payment destination nobody entered for that supplier. In an autofill provider, the same swap between URL fields offers entry A’s password to site B.

A whole-database encryption layer can hide metadata and WAL contents. It does not replace per-field AEAD, because it usually protects only while the database is closed.

Why the password path needs the device too

The threat model that changes the design is the attacker with a copied sandbox or backup. Assume they hold the database, salts, KDF parameters, wrapped keys, and preferences. If the password wrapper is only KDF(password), they can run the KDF on GPUs, away from the device, for as long as they like.

Step 5 fixes that. With the wrapper sealed by a device key that never leaves the Secure Enclave or Keystore, every guess has to run on the original phone, at its speed. The KDF becomes the second barrier, not the only one. A secret stored in plaintext next to the copied files is not a second factor and does not count as one.

For the KDF itself:

Prefer Argon2id with a random salt and versioned parameters, benchmarked on the weakest supported device. It is not part of CryptoKit, CommonCrypto, or the standard Android crypto APIs, so it is a third-party dependency with its own review, pinning, and update process.
If you have to use PBKDF2, both platforms ship it: CCKeyDerivationPBKDF and SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"). Calibrate the iteration count on real devices instead of copying one from another project.
Store the parameters with the envelope and migrate them after a successful unlock.
Derive separate keys for local wrapping and for any protocol authentication, with domain separation.
On iOS, hold keys in CryptoKit SymmetricKey, which zeroes its storage on release, not in Data that the runtime may copy. A password captured as a Swift String cannot be wiped; turn it into bytes for the KDF right away.

KDF cost does not stop a patient person typing guesses into the unmodified app, so add an increasing delay and a persisted failure counter, and require a connected sign-in after a threshold.

A six-digit PIN is a million candidates

An app PIN is a convenience secret in front of the password. It unlocks its own envelope, and that envelope has to be bound to a non-exportable platform key. Six digits are 10^6 candidates. An unbound PIN envelope falls to offline search, whatever the KDF costs.

The rest of the PIN rules:

At least six digits; off by default for high-assurance or managed profiles.
Never store a PIN verifier that is cheaper to attack than the envelope.
A failure counter scoped to the user that survives process death and reboot, with increasing delay and at most 10 consecutive failures, the upper bound NIST SP 800-63B sets for activation secrets.
At the threshold, delete the PIN wrapper and ask for the password. Wiping the local data would destroy the only copy of anything not yet synced.

The catch: neither iOS nor Android enforces a retry limit in hardware for an app-defined PIN. NIST’s limit assumes the authenticator enforces it, and here the app does. The counter stops the user and a thief using the unmodified app. On a rooted or jailbroken device, an attacker can query the platform key directly at hardware speed, and only PIN length helps against that.

The biometric prompt must unlock a key

Biometric success has to authorize the cryptographic operation that unwraps the ADK. If it only flips an isAuthenticated flag, a hooked callback on a rooted device skips it.

Android: pass a `CryptoObject`

Generate the key inside Keystore and require authentication for every use:

val spec = KeyGenParameterSpec.Builder(
 "offline-data-wrap",
 KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT,
)
 .setKeySize(256)
 .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
 .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
 .setUserAuthenticationRequired(true)
 .setUserAuthenticationParameters(0, KeyProperties.AUTH_BIOMETRIC_STRONG) // API 30+: every use prompts
 .setInvalidatedByBiometricEnrollment(true)
 .setUnlockedDeviceRequired(true) // API 28+
 .setIsStrongBoxBacked(true) // API 28+; on StrongBoxUnavailableException, retry in the TEE
 .build()

KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
 .apply { init(spec) }
 .generateKey()

Then hand the initialized cipher to BiometricPrompt, and decrypt only with the cipher you get back:

val cipher = Cipher.getInstance("AES/GCM/NoPadding")
try {
 cipher.init(Cipher.DECRYPT_MODE, wrappingKey, GCMParameterSpec(128, envelope.iv))
} catch (e: KeyPermanentlyInvalidatedException) {
 deleteBiometricWrapper() // enrolled biometrics changed: fall back to the password
 return
}

val prompt = BiometricPrompt(activity, executor, object : BiometricPrompt.AuthenticationCallback() {
 override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
 val unlocked = result.cryptoObject!!.cipher!!
 unlocked.updateAAD(envelope.aad)
 val adk = unlocked.doFinal(envelope.ciphertext)
 // ...
 }
})

prompt.authenticate(
 BiometricPrompt.PromptInfo.Builder()
 .setTitle("Unlock offline data")
 .setAllowedAuthenticators(BiometricManager.Authenticators.BIOMETRIC_STRONG)
 .setNegativeButtonText("Use password")
 .build(),
 BiometricPrompt.CryptoObject(cipher),
)

Set the accepted authenticators explicitly. A default that includes DEVICE_CREDENTIAL means the device PIN opens the offline data, and so does anyone who watched the owner type it. If you want that fallback, make it a written product decision. Since this is a symmetric key with authentication required, creating the wrapper at enrollment also needs a prompt; ask for the password first, as with any new factor.

iOS: a Secure Enclave key and ECIES

Generate the wrapping key in the Secure Enclave with biometric access control, and wrap the ADK with ECIES:

var error: Unmanaged<CFError>?
let access = SecAccessControlCreateWithFlags(
 nil,
 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, // the OS deletes it if the passcode is removed
 [.privateKeyUsage, .biometryCurrentSet], // no passcode fallback
 &error
)!

let attributes: [String: Any] = [
 kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom,
 kSecAttrKeySizeInBits as String: 256,
 kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave,
 kSecPrivateKeyAttrs as String: [
 kSecAttrIsPermanent as String: true,
 kSecAttrApplicationTag as String: Data("offline-data-wrap".utf8),
 kSecAttrAccessControl as String: access,
 ],
]
let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error)!

let wrapped = SecKeyCreateEncryptedData(
 SecKeyCopyPublicKey(privateKey)!,
 .eciesEncryptionCofactorX963SHA256AESGCM,
 adk as CFData,
 &error
)

To unwrap, fetch the key with a fresh LAContext passed as kSecUseAuthenticationContext, with touchIDAuthenticationAllowableReuseDuration left at 0, and call SecKeyCreateDecryptedData. The prompt the user sees then authorizes this key use. That is the iOS counterpart of Android’s per-use authentication.

Two details to get right:

The accessibility class goes into SecAccessControlCreateWithFlags. It cannot be combined with a separate kSecAttrAccessible attribute on the same item.
.biometryCurrentSet invalidates the key when Face ID or Touch ID enrollment changes. Handle that by deleting the wrapper and requiring the password. A .devicePasscode or .userPresence fallback lets anyone who knows the device passcode into the offline data.

Data Protection classes that fail after lock

Set a Data Protection class per store instead of relying on container defaults. The complete class key is discarded about 10 seconds after the device locks, which bites in three places:

Plaintext temporaries should use complete.
Background downloads of offline files need completeUnlessOpen.
A SQLite database in WAL mode under complete fails when anything touches it after lock. Either stop database access on protectedDataWillBecomeUnavailable, or use completeUntilFirstUserAuthentication for the database and rely on field-level AEAD.

Files in tmp/ and elsewhere in the container default to completeUntilFirstUserAuthentication unless you set otherwise.

Offline expiry needs a clock that counts sleep

Enforcing maximum offline age with wall-clock time alone fails the moment someone sets the clock back. I covered that half in An offline cache TTL needs a clock-rollback policy . The research added three things.

The freshness record has two parts. A server-signed part (check-in time, policy version, expiry duration), verified with the server’s public key. A local part (wall time at check-in, monotonic time at check-in, boot reference, accumulated elapsed time), authenticated with a keystore device key. Do not protect it with the ADK: freshness is evaluated before accepting any factor, so the record must verify while the app is locked.

The monotonic clock must keep counting while the phone sleeps, because a phone is asleep most of the time:

Platform	Use	Stops during sleep
iOS	`mach_continuous_time()`, `clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW)`	`mach_absolute_time()`, `ProcessInfo.systemUptime`
Android	`SystemClock.elapsedRealtime()`	`SystemClock.uptimeMillis()`

Verify the chosen clock on a device by letting it sleep.

Reboots reset the monotonic clock. Android has Settings.Global.BOOT_COUNT. iOS has no documented boot identifier: kern.boottime moves when the user changes the wall clock, so it detects clock changes, not boots. On iOS, detect a reboot by a monotonic reading lower than the stored one. Then:

update accumulated elapsed time on every foreground, unlock, and lock

same boot: elapsed from the monotonic clock, cross-checked against wall time
after reboot: elapsed = max(accumulated + monotonic_since_boot,
 wall_now - wall_at_checkin)
wall_now < last stored wall time → rollback → stale

A rollback across a reboot can then hide at most the time between the last update and the reboot.

Fail closed on a missing, rolled-back, or inconsistent record, and exclude it from backup. A restore, to another device or to the same one, then leaves the record missing and forces a check-in. Otherwise, a same-device restore brings back an older valid record together with the ThisDeviceOnly Keychain items it belongs to.

These controls resist clock rollback, not state rollback. Nothing stops someone from replacing the current record with an older valid copy, and the expiry is application logic. Like the PIN counter, it binds the unmodified app, not an attacker running their own code against the device keys.

Documents: chunked AEAD and plaintext that outlives the app

Offline documents, such as invoice PDFs or scanned contracts, need more than per-record encryption. CryptoKit’s AES.GCM and ChaChaPoly seal a whole message in memory. Streaming playback and seeking viewers need chunks, and naive chunking lets an attacker truncate, reorder, or drop chunks without failing authentication. Use a format in the style of the STREAM construction:

fixed-size chunks (say 64 KiB), each sealed separately;
a nonce built from a random per-file prefix and the chunk index;
file ID, format version, chunk index, and a final-chunk flag in each chunk’s authenticated data;
an authenticated header with the prefix, chunk size and version;
a new per-file key or nonce prefix whenever the file changes, so no key and nonce pair is ever reused.

Prefer decrypting into memory or a pipe for an in-app viewer. QLPreviewController wants a file URL, so some formats force a plaintext file. When one is unavoidable, put it in a dedicated private directory under complete, with an unpredictable name, excluded from backup and indexing, shared only through a narrow, non-exported FileProvider grant on Android.

The trap is cleanup. A suspended iOS app runs no code, so no timer deletes the file on schedule, and cancellation, render errors, crashes, process death, and reboot all skip view-level cleanup. Make the launch path enumerate and delete expired temporaries before it allows an unlock.

Lock, logout, and Keychain items that survive uninstall

Lock keeps the encrypted state and destroys the usable keys: release the ADK and derived keys, close plaintext streams, blank the app-switcher snapshot, invalidate decrypted caches, and stop background jobs from quietly recreating an unlocked session. A suspended app cannot clear the clipboard later, so set the expiry when you copy:

UIPasteboard.general.setItems(
 [[UTType.utf8PlainText.identifier: secret]],
 options: [.localOnly: true, .expirationDate: Date().addingTimeInterval(60)]
)

.localOnly keeps it off Universal Clipboard. On Android, mark the clip with ClipDescription.EXTRA_IS_SENSITIVE (API 33+) and clear it with ClipboardManager.clearPrimaryClip().

Logout makes the state permanently unusable. Physical overwrite on flash is unreliable, so the primary boundary is cryptographic erasure: destroy every usable wrapping key, then delete tokens, databases with their WAL and journal files, indexes, cached files, temporaries, pending operations, and shared-container state.

On iOS, uninstalling the app deletes its container but leaves its Keychain items, and no app code runs during uninstall. Keep a marker file in the container. When it is missing at launch, delete every Keychain item the app owns, shared access groups included, before doing anything else. Otherwise, a reinstall can find the previous install’s wrappers.

Autofill is offline unlock under another name

If the cached data includes credentials and the app offers an autofill provider, that provider releases secrets from the local cache with no server call, so every rule above applies to it. The platforms constrain it differently.

On iOS, the Credential Provider extension is a separate process with its own unlock session. It sees the app’s state only through a shared Keychain access group and an App Group container, so every key and wrapper it needs, including the Secure Enclave device key and the freshness record, must live in the shared group. It runs under a memory limit Apple describes as only slightly lower than an app’s. That limit caps the Argon2id memory parameter, so benchmark inside the extension on the weakest device. Do not give the extension a cheaper copy of the password envelope: the weakest wrapper sets the strength of all the data it protects. If parameters that fit are too weak, let the extension offer biometrics only and send password users to the app.

An LAContext evaluated in the app does not carry over to the extension. Within one request, the extension can pass one evaluated context to several Keychain reads, so a single prompt covers a list. The system may reuse the extension process for the next request, so nothing decrypted may stay in a static.

On Android, the AutofillService runs in the app’s own process unless the manifest says otherwise. Its authentication activity still needs a CryptoObject, and it should accept the same authenticators as the app.

Rules for both:

Give the provider its own key that wraps only what a fill needs (username, password, URL), so a faulty extension cannot decrypt documents, notes, or indexes.
Share the failure counter between app and provider. Otherwise, an attacker doubles the allowed attempts by alternating between them.
The provider reads freshness and never checks it itself. When stale, it fills nothing and says which app to open.
On iOS, the identity store shows registered usernames next to their domains in the QuickType bar to anyone holding the unlocked phone, with the app locked. Replace the whole identity set after each sync instead of removing and re-adding the current ones, so deleted entries disappear, and consider a managed policy that registers none.

Verify who is asking

The requester check is where autofill phishing happens (Aonzo et al., Phishing Attacks on Modern Android, CCS 2018 ). iOS identifies websites and apps through associated domains. On Android, the provider has to do it:

Verify the requesting app’s signing certificate against the domain’s Digital Asset Links , not its package name. An app named com.examplebank.evil is not Example Bank.
Trust browsers by package name and certificate digest together. On a device without a listed browser, a sideloaded app can take that browser’s package name and report any web domain.
Derive registrable domains from the Public Suffix List , not a hand-written list of suffixes. Otherwise, an entry saved for victim.github.io collapses to github.io and fills in attacker.github.io.

Users without a password

Everything above assumes every user has a password. Users who sign in through enterprise SSO or a partner’s authenticator app do not. In this design, the password has five jobs:

the baseline wrapper of the ADK;
the fallback when a biometric wrapper is invalidated;
the authorization for a new biometric wrapper;
the replacement when the PIN hits its threshold;
the recent password entry that sensitive actions require.

Each job needs a new owner. The options I found:

Connected sign-in takes every fallback role. This one always applies. A user who loses their last local factor while offline has no offline access until they reconnect.
A mandatory app passcode becomes the baseline factor. Set it during connected provisioning and wrap the ADK with it like the password (KDF, then device key). Three PIN rules change. Six digits stop being enough, because nothing stands behind the passcode: at 0.5 seconds per guess on a compromised device, 10^6 candidates take under six days. Allow alphanumeric passcodes with a real minimum length. The threshold sends the user to connected sign-in, and choosing a new passcode needs one too. The user gets a second secret to remember; that is the price of an offline knowledge factor.
The device passcode can back up the biometric wrapper. It avoids losing offline access at the first biometric change and reopens the “watched the owner type it” risk. Make it explicit, let administrators forbid it, and check on a device whether iOS still releases a biometryCurrentSet or devicePasscode item through the passcode after enrollment changes.
A recovery key can have enough entropy that a copied wrapper is safe even without device binding. Users lose these, and nobody can reset one, so offer it only where a lost factor can cost data.

What does not work is anything the identity provider issued. A cached refresh token or ID token proves the device holds a token, not that the user is holding the device. Don’t wrap the ADK under it, and delete the identity provider’s token cache after the server exchange.

Check one thing in your own protocol. If the server opens a passwordless user’s data without any secret from the user, it can provision the ADK again at the next sign-in. A lost factor then costs offline access, not data, as long as offline records stay read-only. Unsynced offline edits are the exception, because they exist only on the device.

Decide the factor set at provisioning from the login method, and store it with the policy. If the same user later provisions through a password login, re-enroll; don’t bolt a password wrapper onto a passwordless enrollment.

Caveats

The ADK’s scope is a protocol decision. If the ADK only protects this device’s cache, logout and revocation destroy it. If it is the user’s end-to-end key shared with the server and other devices, a device revoked while offline keeps a copy that decrypts future data, and revoking it means rotating the key.
Offline edits are a separate project. Ship read-only offline records first. Editable mode needs an encrypted operation log separate from server-confirmed state, conflict rules that keep both versions when a merge could lose data, and an authorization recheck for each operation on reconnect.
On rooted and jailbroken devices, hardware-backed keys and integrity signals raise the cost. Retry counters and expiry are app logic and don’t bind an attacker who runs their own code against the keys. Don’t claim otherwise.

Test the failure paths

Happy-path testing says nothing about whether keys and plaintext stay contained. The release gates I would not skip:

Area	Test
Provisioning	A never-enrolled device fails offline; restoring a backup to another device, or an older backup to the same one, forces a check-in
Crypto	Copied password and PIN wrappers cannot be opened off the device; ciphertext swapped between records or between fields of one record fails authentication
Biometrics	Add and remove enrolled biometrics, change and remove the passcode, reboot, process death
Retries	Counters survive relaunch and reboot; the PIN threshold removes only the PIN wrapper
Freshness	Clock forward and back, time zone change, reboot, a long sleep counted toward expiry, a replayed older record, the exact boundary; a stale device never prompts
Documents	Truncated, reordered, and dropped chunks fail; kill the app mid-preview and confirm the temporary is gone before the next unlock
Deletion	Uninstall and reinstall leave no usable Keychain state; removing one user leaves another intact
Autofill origin	A look-alike package name gets no match; `victim.github.io` is not offered on `attacker.github.io`

OWASP MASVS and MASTG , NIST SP 800-63B , NIST SP 800-132 for PBKDF2, and RFC 9106 for Argon2id set the baseline. They don’t decide where your keys live or what happens when a preview crashes.

Takeaway

Offline, the app can only answer “is this the enrolled user, on the enrolled device, within the allowed window?” Every unlock path, including the password, should require the device’s hardware key; every biometric prompt should gate a key operation; and the window should be measured by a clock that keeps counting while the phone sleeps.

If your app already has an offline mode, copy its sandbox to another machine and try to open the password wrapper there. If that attempt gets as far as a KDF, the password path is missing its device key.

A shared Swift timeout left an earlier task without a deadline

Fri, 30 Oct 2026 17:37:00 +0100

A Swift service had a timeout, but waiting for its in-flight work could still hang. A held-fetch regression test reached Swift Testing’s outer limit:

Time limit was exceeded: 60.000 seconds

Starting another check replaced the shared timer while the earlier fetch kept running. The fix was to give each tracked operation its own cancellation deadline and cancel that deadline when the operation ended. That still depends on the fetch cooperating with cancellation.

One timer could not cover overlapping fetches

The service could start another asynchronous check before the previous one finished. A separate tracker retained the in-flight tasks so a caller could wait for their completion. Its waiter took a snapshot of those tasks and awaited their results.

The mistaken assumption was that the service’s existing timeout covered everything in that snapshot. Review found that starting a check reset the shared timer without canceling the previous fetch. Finishing a check also reset the timer so that an older completion could interfere with a newer check’s deadline.

An illustrative sequence makes the ownership mismatch visible:

start A tracked: A shared timer: A
start B tracked: A, B shared timer: B; A's timer reset
finish B tracked: A shared timer: reset
wait for A A still running no cancellation deadline for A

The tracker remembered more work than the timer covered. Making that timer longer would leave the same mismatch.

Put the deadline beside the operation

The correction belonged where the tracker created each fetch task. That scope already knew which task it owned and when it finished.

For each operation, create a separate deadline task that sleeps for the configured duration, then calls cancel() on that operation’s task handle. Keep the deadline handle local. On exit, cancel the deadline and remove the operation from tracking. Forward cancellation from the caller to the fetch as well.

The resulting ownership is:

operation A owns deadline A; completion A cancels deadline A
operation B owns deadline B; completion B cancels deadline B

Canceling a deadline’s sleep must end the deadline task. Swallowing the sleep’s cancellation error and continuing to cancel() would turn normal cleanup into an unintended cancellation request.

Keeping the handles local also means A’s cleanup cannot accidentally cancel B’s deadline through a shared slot.

Prove that the waiter needs this deadline

The regression test used a fetch held until cancellation, a short injected operation timeout, and a signal confirming that the fetch had started. Nothing outside the tracker canceled it. The test then awaited completion and checked that the fetch ended before the waiting caller continued.

Before the implementation used the injected timeout, the test failed at the one-minute limit. After adding the operation-local deadline, the archived test output reports the held-fetch test passing and the focused test target exiting successfully.

That establishes the missing-deadline behavior for a cooperative fake. It does not reproduce the entire overlapping-check sequence live. For your own tracker, also hold A open while B starts and finishes, then confirm that A still receives its own cancellation request.

A cancellation deadline is not a hard timeout

Swift’s Task.cancel() documentation explicitly says cancellation is cooperative. Calling it flags the task and runs cancellation handlers; arbitrary work does not automatically stop. A fetch that ignores cancellation can outlive this deadline and keep a completion waiter suspended.

Later work therefore separated the operation’s cancellation deadline from the caller’s user-facing wait budget. It also added recovery after an unsuccessful check. Giving every operation a deadline did not settle how long a caller should wait or whether continuing after failure was safe.

Before relying on a service timeout, start two operations and finish the newer one first. Check that the older operation still has its own cancellation deadline.

SwiftUI large title disappears after tapping the selected tab again

Fri, 30 Oct 2026 14:38:00 +0100

The Settings large title disappeared after tapping the already-selected tab again. Its space stayed empty; the small title still appeared when scrolling, and the accessibility check passed:

titleBefore=true titleAfter=true

An opaque navigation-bar background was painting over the title. The eventual repair removed a screen modifier’s writes to UINavigationBar.appearance(). Hiding the affected screen’s bar background was an intermediate workaround that introduced a font regression.

The title still existed

The prototype varied the tab view, loading state, scroll-view wrapper, and swipe-back helper. Its accessibility existence checks stayed green. Adding the app’s opaque navigation-bar appearance also produced green checks, even though the title vanished visually.

Counting dark pixels in the prototype’s title region exposed the difference:

Appearance	After first tap	After re-tap
Default	12955	12955
Opaque	12955	0

Those are diagnostic counts from one fixed light-background rendering, not a portable visibility threshold. They contradicted the existence assertion directly.

Before-and-after hierarchy dumps from the running app showed the same title view moving from the navigation bar into the scroll view. The bar’s opaque background then covered it. Initially, the screen displayed a loader without a scroll view, so UIKit built the title inside the bar. Re-tapping the selected tab triggered the transition that exposed the problem on the investigated simulator.

This establishes a rendering mechanism in that environment. It does not establish identical title placement on every supported runtime.

The offending modifier intended to remove a divider and set one screen’s background. Its essential mistake looked like this generalized fragment inside a SwiftUI .onAppear closure:

let appearance = UINavigationBarAppearance()
appearance.configureWithOpaqueBackground()
appearance.backgroundColor = .secondarySystemBackground
appearance.shadowColor = .clear

UINavigationBar.appearance().standardAppearance = appearance
UINavigationBar.appearance().scrollEdgeAppearance = appearance

The closure belongs to a screen; the appearance proxy configures all instances of that class. UIKit applies appearance changes when a view enters a window. A different tab’s later navigation bar can inherit those settings, so screen order becomes part of the bug’s setup.

The repair deleted this global writer. The calling screens already declared their backgrounds through SwiftUI’s per-screen toolbar styling; the investigated runtimes did not need a replacement divider-hiding implementation. Their existing snapshots passed without re-recording. Appearance save-and-restore workarounds around a system-presented screen went away with the leak.

A focused test supplied stronger evidence than the original title lookup: show a styled screen, then create another navigation bar and check its background. It failed before the deletion because the next bar inherited a background, then passed afterward. Separate checks guarded the calling screen’s color and the next large title’s font.

Why the one-line hotfix was reversed

The initial workaround used .toolbarBackground(.hidden, for: .navigationBar) on Settings. It kept the prototype’s title visible under the opaque appearance.

The attempted app snapshot never reproduced the original disappearance. The real screen reloaded into a spinner first, unlike the prototype’s scroll-view-first case. Capturing the loaded window still showed the title without the fix. We dropped that test; it couldn’t serve as a regression guard.

Later checks found that hiding the background also made the large title use the system font instead of the intended custom font. A snapshot cropped to the bar failed with that modifier present and passed after its removal. Once the global opaque write was gone, the workaround no longer had a reason to stay.

Verify the interaction, not just the label

Builds and broad test plans passed after the cleanup. Final manual checks in the running app remained open, and older supported runtimes were untested. The font snapshot and next-bar test do not close that gap.

For release verification:

Visit the screens that previously wrote global appearance, then open Settings. Repeat with a different screen order.
Tap the selected Settings tab again. Capture the title before and after, then scroll through its large-to-inline transition.
Check actual title pixels and contrast against the background. Use the hierarchy to explain occlusion; accessibility existence, or isHittable alone, is not universal proof that text is painted visibly.
Repeat on supported runtimes, checking pushed screens’ bar styling too.

Audit screen-level UINavigationBar.appearance() writes before adding another visibility workaround.

Xcode Archive can ship the wrong display name despite correct source settings

Thu, 29 Oct 2026 14:22:00 +0100

A production iOS archive had the production bundle ID and backend environment, but its CFBundleDisplayName was the beta name. The tagged source said otherwise, and App Store Connect never shows that name, so only an installed build revealed it. Add a Run Script phase that checks the processed app Info.plist, so a manual Product > Archive also rejects the wrong identity.

Using synthetic names, the mismatch was:

CFBundleIdentifier = com.example.notebook
CFBundleDisplayName = NotebookBeta

Source checks missed the artifact

The investigation initially ruled out the mismatch from project settings and runtime configuration checks. That conclusion was too strong. The runtime check validated the product variant against the backend environment; it did not validate the display name. A production bundle with a beta display name could satisfy it.

Reading the archived app’s plist settled the question. Its name disagreed with the committed production settings. An uncommitted local edit was the likely explanation, but the archive alone could not establish exactly how the value changed.

The release flow had no step that showed the name either. App Store Connect metadata covers the store listing’s app name, not the bundle’s CFBundleDisplayName, which only appears under the home screen icon. The only check is to install the production build from TestFlight, or from the App Store after release, and read that label by hand. It is easy to overlook when the bundle ID and backend already look right.

Source-level regression tests still help, but manual Archive does not run the scheme’s Test action. A check confined to a deployment lane also misses someone archiving directly in Xcode.

Check the processed plist during the build

Add a Run Script phase named Verify App Identity to the app target, after its existing phases. Use /bin/sh. Leave Run script only when installing unchecked.

Declare this Input File:

$(TARGET_BUILD_DIR)/$(INFOPLIST_PATH)

Declare this Output File:

$(DERIVED_FILE_DIR)/verified-app-identity.stamp

Uncheck Based on dependency analysis for this small guard. It should validate every build, including repeated archives. The input declaration still establishes the dependency on plist processing; visual phase order alone is insufficient. Apple’s Run Script documentation explains how declared inputs and outputs determine task ordering.

Paste this script, adapting the explicit configuration allowlist:

set -eu
: "${SCRIPT_OUTPUT_FILE_0:?Declare the stamp Output File}"
stamp="$SCRIPT_OUTPUT_FILE_0"
rm -f "$stamp"
: "${TARGET_BUILD_DIR:?}" "${INFOPLIST_PATH:?}" "${CONFIGURATION:?}"
plist="$TARGET_BUILD_DIR/$INFOPLIST_PATH"
fail() {
 printf 'error: %s\n' "$*" >&2
 exit 1
}
case "$CONFIGURATION" in
 Release)
 expected_id=com.example.notebook
 expected_name=Notebook
 ;;
 Debug)
 expected_id=com.example.notebook.beta
 expected_name=NotebookBeta
 ;;
 *) fail "No identity policy for configuration $CONFIGURATION" ;;
esac
[ -f "$plist" ] || fail "Missing processed Info.plist: $plist"
id=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' "$plist") ||
 fail 'Cannot read CFBundleIdentifier'
name=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleDisplayName' "$plist") ||
 fail 'Cannot read CFBundleDisplayName'
[ "$id" = "$expected_id" ] && [ "$name" = "$expected_name" ] ||
 fail "$CONFIGURATION requires $expected_id / $expected_name; got $id / $name"
printf 'Verified app identity: %s / %s\n' "$id" "$name"
: > "$stamp"

Do not substitute the source INFOPLIST_FILE: generated keys and build-setting expansion can change the packaged values. Keep the expected identity independent of the settings under test.

The declared paths also describe the script’s file access for user-script sandboxing. Keep sandboxing enabled where possible and test these declarations with your Xcode version. The original target had it disabled. The stamp lives outside the signed app and is created only after validation. Removing it first, failing on missing values, and running unconditionally prevent an old stamp from becoming a false success after a failed check.

Prove that wrong builds fail

The historical implementation passed normal builds across all four original configurations. Four deliberate mutations failed: the production ID, production name, beta ID, and beta name, changed separately. Each failure reported the mismatched identity; the project file was restored afterward. These were build checks, not evidence of a fresh Archive after the fix.

For your project, repeat those negative controls, then restore the settings and archive twice without cleaning. Confirm the guard runs both times and inspect the resulting archive’s app plist. Also test a missing key and an unrecognized configuration.

This checks the app’s base plist only. Localized InfoPlist.strings can affect the displayed name, and extensions need separate policies. Check the Archive action’s selected configuration in your scheme, then deliberately break its display name and confirm Archive fails before trusting the guard.

An offline cache TTL needs a clock-rollback policy

Tue, 27 Oct 2026 15:44:00 +0100

AAn offline cache can pass its age check after the device clock moves backward. A timestamp later than “now” produces a negative age, and a check that only asks whether age is below the TTL accepts it. Reject future timestamps and remember the latest wall-clock time observed, while recognizing that neither check provides trusted elapsed time.

A negative age passed the upper-bound check

The feature reused a biometric-protected Keychain cache shared with a companion extension. Its initial eligibility rule was effectively:

now - lastWritten <= maxAge

That has two problems. Moving the clock before the write makes the age negative. Moving it backward after a previous access can also make an expired cache look young again without crossing the write timestamp.

The cache contained independently written items. Using the newest item’s date would make an older item appear refreshed, so eligibility used the oldest modification date. A separate check rejected any item dated in the future. Checking only the oldest date would miss a newer, future-dated item.

Retain the latest observed time

The repair added a clock mark in a separate Keychain item. Each eligibility read retained max(previousMark, now). If now preceded the previous mark, access was refused. Writing the rolled-back time into the mark would let the next read pass, so repeated reads were part of the regression test.

This Python model isolates the arithmetic from Keychain storage. Inputs are timestamps in the same unit and a nonnegative maximum age. None represents initial mark creation; it does not distinguish first use from a failed storage read.

def cache_status(written_at, now, mark, max_age):
 if not written_at:
 return "unavailable", mark

 previous = now if mark is None else mark
 updated = max(previous, now)
 fresh = (
 now >= previous
 and max(written_at) <= now
 and now - min(written_at) <= max_age
 )
 return ("fresh" if fresh else "expired"), updated

Persist the returned mark reliably. Define separate behavior for a missing mark, failed reads, and failed writes. Serialize the read/advance/write operation across its writers: two callers storing independently calculated maxima can otherwise overwrite a newer mark with an older one. This function does not implement those storage guarantees.

A successful online sign-in reset the mark to the current time, allowing recovery after a fast clock was legitimately corrected. That reset belonged to the authenticated online path, not to an offline retry.

Refusing access did not mean deleting the cache

The main app’s expiry policy could not delete data the companion extension still needed. An expired result blocked that entry point and requested an online sign-in; it left the shared cache intact.

Offline use also had to stay separate from an ordinary signed-in state. Otherwise, the normal cache writer could rewrite cached data, advance its modification dates, and renew its apparent freshness without server contact. A timestamp is useful evidence of synchronization only while that write invariant holds.

Eligibility was checked again when opening the cache. A login screen left visible across the deadline could not reuse the earlier “fresh” result.

Test the rollback twice

The original implementation’s red run reported four failed clock-mark assertions, including rollback refusal, repeated refusal, mark advancement, and online-sign-in reset. After the repair, the recorded core-target run passed 184 tests in 31 suites. Those are historical Xcode results, not a new Keychain integration run.

A separate run of the function above passed 15 synthetic-timestamp tests, covering expiry boundaries, future-dated items, repeated rollback refusal, and rechecking at open without mutating the cache. It did not exercise Keychain persistence. For example, two reads with these synthetic inputs must preserve the higher mark:

result, mark = cache_status([100], 190, 200, 1000)
assert (result, mark) == ("expired", 200)
assert cache_status([100], 190, mark, 1000) == ("expired", 200)

A high-water mark cannot establish time that was never observed

A device can spend real time offline while its wall clock never exceeds the saved mark. These checks cannot prove how much time passed, guarantee remote revocation, or withstand a compromised device that can alter the protected state. Biometric access control does not authenticate the clock.

Test your cache by expiring it, moving the injected clock backward, and reading eligibility twice. Both reads should refuse access, and the second must not inherit a lowered mark.

iOS jailbreak protection in 2026: detection is a risk signal, not a security boundary

Mon, 26 Oct 2026 23:20:00 +0100

An iOS app had jailbreak detection, passed an external pentest, and still spent more than a year accepting every jailbroken device because an asynchronous result was discarded. After that bug was fixed, the checks were still a 2025 list of Cydia-era paths that missed current rootless and hidden jailbreaks.

If the requirement says “the app must not run on a jailbroken phone,” the useful answer in 2026 is not a longer path list. Treat jailbreak detection as a bypassable risk signal, decide what sensitive operation the signal protects, enforce that decision at the server where possible, and test the whole policy against current jailbreak and bypass tools.

The short version

A defensible implementation today has five parts:

Write a threat model that explains why a compromised device materially changes this app’s risk.
Combine independent local signals and run them near sensitive operations, not only at launch.
Apply a proportional policy: observe, step up, restrict sensitive data, or refuse service according to confidence and impact.
Put the final authorization decision on a server and use App Attest to protect app-to-server requests. Do not call App Attest to prove that a device is not jailbroken.
Test the release binary statically, dynamically, and by trying to bypass it on representative clean and jailbroken devices.

This is also the difference between “the code contains a jailbreak check” and an engineering conclusion that can survive review.

How a working check silently stopped working

The first implementation was conventional:

sysctl checked P_TRACED and terminated a release build under a debugger;
known paths such as /Applications/Cydia.app, /bin/bash, /usr/sbin/sshd, and /etc/apt were checked;
the app tried to write /private/jailbreak.txt outside its sandbox;
cydia:// was passed to canOpenURL;
loaded Mach-O images were searched for MobileSubstrate.

It ran only in non-Debug builds on physical devices. That was sensible, and the pentest team verified it.

One probe had never worked in the affected app targets: canOpenURL returns false for schemes that are not declared under LSApplicationQueriesSchemes, and cydia was not declared. An app extension could not use UIApplication.shared at all. Current IOSSecuritySuite also removed the cydia:// check because an App Store app registered the scheme and caused false positives. URL-scheme probes are weak evidence even when configured correctly.

Then the check moved behind a function that started a Task, returned from the function immediately, and ignored the task’s Bool. The user interface always received true. The debugger check still appeared to work because fatalError happened inside the task, masking the control-flow bug. Later refactors moved the broken call without changing its behavior.

The eventual fix was not another jailbreak signature. It was to make validation genuinely asynchronous, await it, and test the production call site as well as the checker.

That history produced three reusable lessons:

Test enforcement, not just detection. A perfect signal whose result is ignored protects nothing.
Test every app entry point and extension. The main app, credential provider, widget, and background path do not necessarily share a process or API surface.
Test the release configuration on hardware. A Debug simulator test proves code structure, not production behavior when the checks are compiled out there.

When OWASP says to implement jailbreak detection

OWASP MASTG 2.0, released in July 2026 , makes the trade-off unusually explicit. MASTG-BEST-0030 is currently tagged Android and says “root detection,” but its risk principle applies directly to the equivalent iOS control: it is a bypassable, cost-raising environment signal. It should be used only when compromised-device risk materially affects the app. The selection and response should follow the threat model and risk tolerance.

That points toward jailbreak protection when a compromised platform makes a concrete abuse case easier, for example:

extracting high-value secrets or regulated data from the app process or local cache;
instrumenting transactions, credential filling, cryptographic operations, or fraud controls;
changing a game, licensing, payment, or content-access decision made locally;
automating a protected API through a modified client;
defeating controls that depend on the sandbox, Keychain access policy, or trusted user interaction.

It does not make jailbreak detection a universal mobile-app baseline. A low-risk public-content app may gain little while inheriting false positives, support work, accessibility problems, and an exclusion policy it cannot reliably enforce.

MASVS-RESILIENCE-1 states the security concern: many other controls assume that the platform’s sandboxing, secure storage, and biometrics can be trusted. But the wider MASVS resilience guidance treats anti-tampering and runtime self-protection as defense in depth, never a replacement for the baseline security architecture.

The current techniques are rootless and designed to hide

The old signature list described rootful Cydia and MobileSubstrate installations. Current jailbreaks changed the filesystem layout and then added explicit concealment.

Dopamine is a rootless jailbreak. Its bootstrap commonly appears below /var/jb, with ElleKit providing tweak injection. Dopamine 1.1 introduced JB_ROOT_PATH in the environment of processes with tweaks enabled, while noting that /var/jb might become optional to impede detection. Palera1n has its own loader and helper artifacts. Frida may appear as frida-server, Frida Gadget, a loaded image, or merely runtime behavior after its obvious names have been changed.

At the time of this review, Dopamine’s current upstream release was 3.0.12, published October 20, 2026 . A signature inventory that stops at Cydia or even Dopamine 2 is already historical.

Dopamine 2.4’s release notes are the more important evidence: “Hide Jailbreak” was changed specifically to hide the jailbreak to the point where it should be undetectable. RootHide’s Dopamine integration randomizes the jailbreak root and selectively keeps jailbreak changes away from blacklisted apps. Its purpose is jailbreak-detection bypass.

A 2026 local detector should therefore look across different classes of evidence, for example:

rootful and rootless files, directories, symlinks, package-manager state, and randomized .jbroot-* roots;
whether the sandbox permits a collision-safe write to a protected path;
debugger state and failure of the debugger-status query itself;
suspicious environment keys such as DYLD_INSERT_LIBRARIES and JB_ROOT_PATH;
loaded images associated with Frida, ElleKit, Substrate, Substitute, libhooker, RootHide, or Dopamine’s system hook;
behavior that should be prohibited by the sandbox, where the API is appropriate for App Store software;
server-side anomalies and app-integrity assertions.

Use more than one API for important filesystem evidence. A FileManager.fileExists check, a POSIX lstat, and directory enumeration do not create certainty, but an attacker now has more hooks to maintain consistently.

Do not equate more signatures with “state of the art.” Public signature lists are useful coverage for unsophisticated and accidentally exposed jailbreaks. RootHide, renamed Frida components, or a patch to the function that aggregates all checks can make every local answer say “clean.” OWASP’s jailbreak detection knowledge article says the same thing: these defenses are not effective by themselves, although distributing them through the app increases the cost of bypassing them.

The response matters more than the Boolean

“Jailbroken: yes or no” is too weak a model for a fallible set of signals. Record an internal risk result with the evidence and confidence, then map it to a product policy.

Situation	Reasonable response
One weak or ambiguous signal	Telemetry, retry, or step-up authentication
Several independent local signals	Block sensitive operations; avoid disclosing the exact failed probe
Debugger or injected runtime tool in a high-risk flow	Refuse the operation and invalidate relevant server state
Unsupported App Attest on an otherwise supported device	Treat as a risk signal according to the documented policy
Enterprise-managed fleet with a strict posture requirement	Evaluate Managed Device Attestation at the relying service

OWASP recommends proportional responses and warns that aggressive lockout can affect legitimate users. For an app that stores documents and credentials, a useful soft block can allow login and folder metadata while refusing document bodies, downloads, offline queues, and credential release.

That restriction must be in application logic, not just a screen with a Close button. Better still, the server should not return the sensitive payload. Otherwise, a hook can dismiss the screen or call the same API directly.

A hard process exit is appropriate only if the threat model justifies denial of all functionality and the product accepts false positives. Crashing also gives poor observability and can turn an operational failure into a permanent lockout. A generic refusal with server-side telemetry is usually easier to operate.

App Attest authenticates app instances, not clean devices

Apple’s WWDC26 App Attest session describes the current protocol:

the server initiates enrollment and issues a challenge;
the app creates a Secure Enclave-bound key and attests it;
the server validates and stores the attestation and public key;
sensitive requests include a fresh server challenge in an assertion over the payload;
the server validates the signature and requires a strictly increasing counter to reject replays.

This is valuable. It lets the server distinguish a valid published app instance, detect unexpected signing or launch categories, and bind authorization to a payload that has not been altered in transit.

It is not a jailbreak oracle. The same 2026 session says that a compromised device can still pass attestations and broker valid attestations for modified clients. Apple provides the fraud metric to help detect that pattern. Use App Attest as another server-verified signal, with retry and onboarding policy for legitimate failures.

For managed organizational devices, Managed Device Attestation provides Secure Enclave-backed evidence about device identity and security posture. That is stronger input for a managed-fleet trust decision, but it is not a general capability that a consumer app can require from every unmanaged phone.

Test implementation, behavior, and bypass resistance

OWASP MASTG 2 separates two questions that teams often collapse into one.

MASTG-TEST-0240 is static: extract the shipped app package and inspect the binaries for jailbreak-detection mechanisms. This catches missing code, build flags that compiled it away, or a check that never reached a target. OWASP warns that automated static analysis is not exhaustive; manual reverse engineering may be necessary.

MASTG-TEST-0241 is dynamic: run the app, identify the checks, and try to bypass them. A test fails when detection is absent, but passing a single predefined bypass tool doesn’t prove resilience because its scripts may be incomplete or outdated.

For a real release, I would keep this matrix with the evidence from each run:

Test	Expected evidence
Clean supported iPhones and iOS versions	No false refusal; all sensitive flows work
Release build on physical hardware	Checks execute; Debug/simulator exclusions do not leak into the archive
Rootful and current rootless jailbreaks	Each applicable signal fires; policy is enforced
Dopamine Hide Jailbreak and RootHide blacklist	Document what remains visible and what becomes undetectable
Frida server and embedded/renamed Gadget	Known artifacts are detected; renamed forms challenge bypass resistance; outcomes are recorded
Hook the aggregate result and individual APIs	Sensitive server operation still requires valid authorization and assertions
Main app, extensions, background entry points	Each entry point validates before releasing its protected capability
Async and error paths	Results are awaited; query failures follow the documented fail-open or fail-closed policy
Pentest bypass configuration	It cannot enter a production archive; CI tests that invariant

Unit-test injected signals, cleanup failures, query failures, and clean-device results. Then add integration tests around the call site: the protected operation must not run after validation fails. Finally, let a tester attack the binary rather than merely demonstrating a known file on a jailbroken test phone.

A reviewable 2026 “lege artis” baseline

“State of the art” is not established by citing one library or by counting checks. For an engineering review, the conclusion should be reproducible, dated, scoped, and explicit about uncertainty. This is the practical baseline I would use when assessing whether an iOS app’s jailbreak protection was implemented with professional care in October 2026:

Define the question and date. State which app version, release configuration, iOS range, device classes, sensitive operations, and attacker capabilities are in scope. Practice changes as jailbreaks and iOS change.
Identify the risk before prescribing the control. Connect compromised-platform capabilities to actual assets and abuse cases. Explain why jailbreak detection materially affects this app.
Select authoritative and current sources. Record versions and access dates for OWASP MASVS/MASTG, Apple platform documentation, relevant jailbreak release notes, and the implementation under review. Treat public detection libraries as examples, not normative standards.
Preserve and identify the evidence. Record the source commit, archive hash, build settings, entitlements, tool versions, device/iOS versions, jailbreak version, and test logs. Work from a reproducible copy.
Separate facts from interpretation. “The production binary contains /var/jb and JB_ROOT_PATH checks” is a fact. “Those checks make bypass harder but cannot establish a clean device” is the interpretation supported by OWASP and current bypass projects.
Analyze the whole control path. Review signal collection, aggregation, async propagation, every entry point, the product response, server authorization, telemetry, and release-lane exceptions. Include negative findings and dead code.
Test both presence and effectiveness. Perform static inspection, clean-device compatibility tests, dynamic execution on relevant jailbreaks, and bypass attempts. A unit test or a pentest on one jailbreak version is not enough.
Consider alternatives and false positives. Explain why a detected artifact could be benign, why a missing artifact does not establish cleanliness, and why the chosen response is proportional.
State limitations. Local checks can be hooked or patched; hidden jailbreaks may expose no artifact; App Attest can succeed on a compromised device; the tested device set is finite.
Make a bounded conclusion. Say whether the examined implementation follows the documented risk policy and raises attacker cost for the tested scenarios. Do not conclude that it guarantees a non-jailbroken device.

This structure mirrors a sound software expert analysis: sources and methods are identified, observations remain distinguishable from interpretation, contrary evidence is not hidden, limitations reduce the stated certainty, and the conclusion answers only the technical question examined. It is guidance for an engineering assessment, not a legal conclusion about liability, contractual compliance, or negligence.

Takeaway

The old implementation failed twice: first because application control flow discarded a valid result, then because its threat model had aged past its Cydia-era signatures. The durable fix is a process—current layered signals, proportional server-enforced policy, and repeated adversarial testing—not a permanent isJailbroken function.

Take one sensitive operation in your app and trace it today from device signal to server authorization. If any step can ignore, hide, or locally override the result, that is the next protection to fix.

References

OWASP MASVS: Resilience against reverse engineering and tampering , accessed October 26, 2026.
OWASP MASTG 2.0.0 release announcement , July 4, 2026.
OWASP MASVS-RESILIENCE-1: Platform integrity , accessed October 26, 2026.
OWASP MASTG-BEST-0030: Implementing Root Detection , accessed October 26, 2026.
OWASP MASTG-KNOW-0084: Jailbreak Detection , accessed October 26, 2026.
OWASP MASTG-TEST-0240: Jailbreak Detection in Code , accessed October 26, 2026.
OWASP MASTG-TEST-0241: Runtime Use of Jailbreak Detection Techniques , accessed October 26, 2026.
Apple: Secure your apps with App Attest, WWDC26 , accessed October 26, 2026.
Apple Platform Security: Managed Device Attestation , accessed October 26, 2026.
Dopamine 2.4 release notes: Hide Jailbreak , February 16, 2025.
Dopamine 1.1 release notes: JB_ROOT_PATH , June 16, 2023.
Dopamine releases , accessed October 26, 2026.
Dopamine 3.0.12 release , October 20, 2026.
RootHide integration for Dopamine 3 , accessed October 26, 2026.
IOSSecuritySuite jailbreak checker , accessed October 26, 2026.

A five-second Swift Testing wait timed out after its loop had run five times

Thu, 22 Oct 2026 16:12:00 +0200

Five concurrency tests passed on their own in 0.086 seconds. In the full target, they failed together at about 6.8 seconds:

✘ Test fetch_threeSources_asksForEverySourceAtOnce() recorded an issue at FetcherConcurrencyTests.swift:21:30:
 Expectation failed: ContinuousClock.now < deadline
✘ Test fetch_threeSources_asksForEverySourceAtOnce() failed after 6.816 seconds with 1 issue.

It looked like a deadlock in the code under test. It was a test helper measuring the wrong thing.

Setup

Swift Testing, an Xcode test target that mixes @MainActor unit suites with snapshot suites.
Two test plans run the same target. One sets "parallelizable": false for it, and the other doesn’t. Only the parallel plan failed.
A small polling helper that the concurrent-fetch tests use to wait for a gated fake service to see requests:

static func until(
 sourceLocation: SourceLocation = #_sourceLocation,
 _ condition: () -> Bool
) async throws {
 let deadline = ContinuousClock.now.advanced(by: .seconds(5))
 while !condition() {
 try #require(ContinuousClock.now < deadline, "Timed out waiting for the condition to hold",
 sourceLocation: sourceLocation)
 await Task.yield()
 }
}

The helper runs on the main actor. Each Task.yield() lets the queued work, in this case the fetcher opening its requests, run before the condition is checked again.

Reproduce before guessing

Running the target alone under the parallel plan with -test-iterations and -run-tests-until-failure failed 3 out of 3 times, always in the same tests and always at the wall-clock deadline. So it wasn’t a rare flake. It failed every time under that plan.

To check whether the waits were stuck or just slow, I temporarily replaced the deadline with a counter and printed what each wait used:

let start = ContinuousClock.now
var turns = 0
while !condition() {
 turns += 1
 await Task.yield()
}
print("WAITPROBE turns=\(turns) elapsed=\(ContinuousClock.now - start) at \(sourceLocation.line)")

5 5.766 FetcherConcurrencyTests.swift:54
5 5.712 FetcherConcurrencyTests.swift:21
4 6.411 FetcherConcurrencyTests.swift:37
3 5.704 SyncLoggingTests.swift:25
3 5.338 InFlightTests.swift:20

Every wait finished, but the slowest needed only 3 to 5 turns and took more than 5 seconds of wall time. The condition was met on almost the first chance the fetcher got to run. It just didn’t get that chance for seconds.

The reason showed up when I sorted tests by duration. In the parallel plan, snapshot suites share the process and the main actor, and each render holds the actor synchronously, some of them for over 7 seconds. While a render ran, the waiting test’s next turn just sat in the queue, and the clock kept running.

Dead end: a longer timeout

I tried a 60-second deadline as an experiment. Both runs passed, with the concurrency tests taking about 7.9 seconds each.

That shows the cause, but it isn’t a fix. 60 is no more principled than 5. A heavier snapshot suite brings the failure back, and a test that really hangs now takes a minute to report it. I reverted it.

Fix: spend both budgets before failing

The wait should fail only once it has had enough chances to make progress and enough time has passed:

static func until(
 sourceLocation: SourceLocation = #_sourceLocation,
 timeBudget: Duration = .seconds(5),
 _ condition: () -> Bool
) async throws {
 let deadline = ContinuousClock.now.advanced(by: timeBudget)
 var turns = 0
 while !condition() {
 let hasBudgetLeft = turns < Constants.turnBudget || ContinuousClock.now < deadline
 try #require(hasBudgetLeft, "Timed out waiting for the condition to hold",
 sourceLocation: sourceLocation)
 turns += 1
 await Task.yield()
 }
}

enum Constants {
 /// A wait under a fully loaded run of this target took at most 5 turns.
 static let turnBudget = 100
}

On an idle main actor, 100 turns go by in milliseconds, so a condition that never holds still fails just after the time budget. On a starved actor, the wait keeps going until it has had real chances to run.

Pin it with a controlled starvation test

The full target is a slow, noisy reproduction, so I wrote a test that intentionally causes starvation. It makes timeBudget a parameter, holds the main actor for longer than that budget, and makes the condition true only afterward:

@MainActor
@Suite
struct WaitTests {
 @Test
 func until_whenTheMainActorIsHeldPastTheTimeBudget_waitsForTheCondition() async throws {
 let holds = LockIsolated(false)
 Task { @MainActor in
 Thread.sleep(forTimeInterval: 0.3) // stands in for a snapshot render
 Task { @MainActor in holds.setValue(true) }
 }
 try await Wait.until(timeBudget: .milliseconds(100)) { holds.value }
 }

 @Test
 func until_whenTheConditionNeverHolds_fails() async {
 await withKnownIssue {
 try await Wait.until(timeBudget: .zero) { false }
 }
 }
}

Before the fix, it failed after 0.335 seconds with the same ContinuousClock.now < deadline error. After the fix, it passed in 0.303 seconds. The second test makes sure the helper can still fail.

Verify both directions

Check	Result
Parallel plan, before the fix	0 of 3 passed
Parallel plan, after the fix	5 of 5 passed
Serial plan, whole target	690 tests passed
Mutant: fetcher limited to one request at a time	all 5 concurrency tests failed, each at 5.0 s

The last row matters most. A longer timeout would also have made the parallel runs pass. What it wouldn’t keep is fast failure for a real bug. I changed the fetcher’s concurrency limit from 4 to 1, so the “all three requests are open at once” condition could never be true. All five tests caught it, each at the 5-second time budget, and I reverted the mutation.

One caveat: that mutant ran under the serial plan. Under heavy parallel load, a real hang fails after 100 turns, which takes longer than 5 seconds. That’s the trade-off I chose, and it applies to this helper and this workload. It isn’t a general fairness guarantee for Task.yield().

A second guess hiding in the same tests

Three tests waited for the first request and then gave the scheduler “five settling turns” before asserting that all three were open. That turn count was another guess, and it could fail under load the same way. The fix was to wait for the exact condition:

// before
try await Wait.until { service.pendingCount > 0 }
await Wait.untilSettled()
#expect(service.pendingCount == 3)

// after
try await Wait.until { service.pendingCount == 3 }

Takeaway

A wall-clock timeout in a polling helper measures how busy the process is, not whether your code is stuck. When a wait times out only in the big parallel run, count its turns before you suspect a deadlock. If it got only a handful of turns, the actor was starved. Make the helper fail only after both a time budget and a turn budget run out. Then check the fix with a mutation that should hang and make sure it still fails quickly.

Try it on your own polling helper: add a turn counter and run the full target in parallel once. If the worst wait used single-digit turns but took seconds, the timeout is measuring main-actor contention.

Snapshot precision 0.99 let a wrong text line pass all seven screen tests

Tue, 13 Oct 2026 17:04:00 +0200

A code review claimed that a list screen’s snapshot tests couldn’t fail on the very line they were written to pin: a small gray “Location” line under each search result. To check, I broke that line on purpose. The rows got the container’s short name instead of its full name, so every location line rendered the wrong text. Then I ran the suite:

✔ Test listScreenDeletedItemsShowTheirOrigin() passed after 0.296 seconds.
✔ Test listScreenSearchResultsShowTheirLocation() passed after 0.708 seconds.
...
✔ Test run with 7 tests in 1 suite passed after 0.793 seconds.

All seven passed against the broken code. If your snapshot tests record a whole screen at .device layout with a precision below 1.0, they may be just as blind.

Setup

The project used swift-snapshot-testing 1.19.2, with Swift Testing on the iOS simulator. A shared defaults file sets both tolerances:

public static let perceptualPrecision: Float = 0.90
public static let precision: Float = 0.99

The two gates do different jobs:

perceptualPrecision decides whether a single pixel counts as different. 0.90 absorbs anti-aliasing drift between developer Macs.
precision decides what fraction of pixels must match. 0.99 lets 1% of the image differ by any amount.

The 0.99 was there to unblock CI: one render drifted by about 3,600 pixels between machines. The comment next to it even warned that it was “wide enough to hide a small real regression”. Every screen test used it anyway.

The arithmetic

An iPhone 17 Pro device frame is 1179×2556 pixels.

1179 × 2556 = 3,013,524 px
1% of that = 30,135 px may differ freely
wrong location = ~900 px actually differed

A 1% budget sounds strict. On a full screen it’s about a 58-point square of arbitrary change, more than all the location lines on the screen combined. The test was recorded correctly and passed honestly. It just had no way to fail on the thing in its name.

Measuring the mutation

To size the gate, record the mutated renders, diff them against the committed references, then restore the references. A few lines of Pillow give a rough count (a pixel counts if any channel moves by more than 25):

import sys
from PIL import Image

a = Image.open(sys.argv[1]).convert("RGB")
b = Image.open(sys.argv[2]).convert("RGB")
pa, pb = a.load(), b.load()
w, h = a.size
n = sum(1 for y in range(h) for x in range(w)
 if max(abs(c1 - c2) for c1, c2 in zip(pa[x, y], pb[x, y])) > 25)
print(f"{n / (w * h):.2%} of {w}x{h}")

TEST_RUNNER_SNAPSHOT_TESTING_RECORD=all xcodebuild test ... -only-testing:MyTests/ListScreenSnapshotTests
git show HEAD:path/to/reference.png > /tmp/head.png
python3 pxdiff.py /tmp/head.png path/to/reference.png
git checkout -- path/to/__Snapshots__ # put the real references back

...DarkAppearance...: 0.03% of 1179x2556
...SearchResultsAtTheDynamicTypeCap...: 0.14% of 1179x2556
...SearchResultsShowTheirLocation...: 0.03% of 1179x2556
...DeletedItemsShowTheirOrigin...: 0.03% of 1179x2556

The smallest real defect was 0.03%, about 900 pixels, so the budget had to sit well below that. 0.9999 allows 301.

The fix

Give the screen suite its own precision and write the numbers down where the next person will see them:

as: .image(
 precision: Constants.precision,
 perceptualPrecision: SnapshotDefaults.perceptualPrecision,
 layout: .device(config: config)
)

private enum Constants {
 /// A device frame is 1179×2556 px, so the default 1% budget is 30,135 px: wider than every
 /// Location line on the screen together. The wrong name moves about 900 px; this leaves a
 /// 301 px budget, while `perceptualPrecision` still absorbs anti-aliasing drift per pixel.
 static let precision: Float = 0.9999
}

Then rerun with the mutation still in place. It has to go red:

✘ Test listScreenDeletedItemsShowTheirOrigin() failed after 0.594 seconds with 1 issue.
✔ Test listScreenSortMenuOpen() passed after 0.751 seconds.
✔ Test listScreenBrowsingTheRoot() passed after 0.807 seconds.
✘ Test listScreenSearchResultsAtTheDynamicTypeCap() failed after 1.220 seconds with 1 issue.
✘ Test listScreenSearchResultsShowTheirLocation() failed after 1.618 seconds with 1 issue.
✔ Test listScreenSearchWithNoResults() passed after 1.659 seconds.
✘ Test listScreenDarkAppearance() failed after 2.036 seconds with 1 issue.

The four cases that draw location or origin lines failed. The three cases without them passed, which is also correct. After reverting the mutation, all seven passed again at 0.9999.

A 301-pixel budget is tight, and I verified it on one machine. If cross-machine drift trips it, look at the drift before you loosen the number.

Shrink the frame when you can

For a single component, a tight frame beats a tight precision. The same project measured a toolbar button’s enabled-to-disabled color change at 1,808 pixels, or 0.06% of a device frame. Rendered at 140×60 with layout: .fixed(width:height:), those 1,808 pixels became 2.4% of the image, well past a 1% budget. Keep .device for tests that are really about the whole screen, and size their precision from the smallest change they claim to catch.

Takeaway

precision is a fraction of the image, so a fixed value forgives more pixels as the frame grows. Before you trust a green snapshot, break the thing it’s named after, count the changed pixels, and compare that with (1 - precision) × width × height.

Pick one snapshot test in your suite, break its subject on purpose, and see whether it goes red.

xcodebuild says TEST SUCCEEDED, the xcresult says "Issues recorded without an associated test or suite"

Mon, 28 Sep 2026 12:16:00 +0200

A branch passed locally. xcodebuild test exited 0 and printed:

** TEST SUCCEEDED **

The fastlane coverage lane on the same branch failed with Tests have failed and didn’t name a test. Scan’s xcpretty output doesn’t show Swift Testing results, so the log didn’t include any failing tests. The result bundle had the answer:

xcrun xcresulttool get test-results summary --path Test.xcresult

{'result': 'Failed', 'totalTestCount': 2320, 'passedTests': 2317, 'failedTests': 1, ...}
testName: Issues recorded without an associated test or suite
failureText: Issue recorded: failed - Unimplemented: Unimplemented AppVersionClient.currentVersion …
 This issue was emitted from tests running in a host application.
 This can lead to false positives, where failures could have emitted from live application code at launch time, and not from the current test.

If your console is green and fastlane, Xcode Cloud or anything else that reads the .xcresult is red, check the summary for that pseudo-test before you go looking for a flaky test.

Setup

Xcode 26, Swift Testing, an app-hosted unit test target (tests run inside the real app process).
swift-dependencies 1.14, with a client whose testValue calls IssueReporting.unimplemented(...). That’s the usual way to make sure a test sets every dependency it uses.
The app’s root view is a login screen. On appear, it asks a backend for the minimum supported version and compares it with currentVersion().

What happened

Because the app hosts the tests, it launches as it does for a user, and its login screen sends the version request. When the response arrives, the screen reads the version client inside a test process, which resolves to the unimplemented test value and records an issue. No test is running on that code path, so the issue gets attached to no test.

The console run only shows it as a warning:

⚠︎ Test «unknown» recorded a warning at VersionClient.swift:24:1: Issue recorded
↳ failed - Unimplemented: Unimplemented AppVersionClient.currentVersion …

The result bundle counts it as a failure, though, and fastlane reads it.

Main didn’t fail, and the new branch didn’t touch any of this code. Its only addition was a new app-hosted suite that took about seven seconds. That extra time let the response arrive while tests were still running. On main, the run was over before the response came back. This is timing-dependent, so a faster backend or a slower one can hide the failure or bring it back.

Reproduce one target and compare the result bundle summaries:

Run	Total	Failed
Hosted target, as is	21	1
Same, new suite skipped (`-skip-testing`)	16	0
Same, with the fix	20	0

The 21 in the first row is 20 real tests plus the pseudo-test.

Dead end: set the dependency at launch

The obvious fix is to give the app a live value in its entry point:

prepareDependencies {
 $0.appVersion = AppVersionClient { Bundle.main.shortVersion }
}

It built and changed nothing. The same failure showed up again. In a test process, swift-dependencies resets its cached values for each test: it registers an XCTest observer that clears the cache whenever a test case starts. The value you prepare at app launch is gone once the tests start, and the later response reads the test value again.

Fix: don’t show the app UI while hosting tests

isTesting from IssueReporting (re-exported by Dependencies) is true inside a test process. Gate the scene’s content on it:

import Dependencies
import SwiftUI

@main
struct MyApp: App {
 var body: some Scene {
 WindowGroup {
 // Unit tests run inside this app. Its login screen would start a
 // network request whose response reads an unimplemented test dependency.
 if !isTesting {
 RootView()
 }
 }
 }
}

This is the workaround in the library’s Testing gotchas docs. Before applying it, check that no hosted test needs the app’s window or a view in the scene. Here, none did, because the tests only needed a real UIApplication, which still exists with an empty WindowGroup. The shipping app is unchanged, since isTesting is false outside a test run.

With the fix, the hosted target passed 20 of 20, the whole coverage lane reported 0 failures on both schemes, and the test run stopped sending requests to the dev backend.

That last part is a nice bonus. A test host that shows its real UI talks to real servers from your CI, and anything it logs (request and response bodies, anti-forgery tokens) ends up in your test logs.

Takeaway

An app-hosted test run also runs your app. Anything the app starts on its own at launch can record a failure that belongs to no test and shows up only in the .xcresult. Keep the UI out of the test host with if !isTesting, and when the console and the lane disagree, read xcresulttool get test-results summary first.

Try it on your own app-hosted target: grep a recent test log for Test «unknown» recorded. Each hit is an issue recorded outside any test, and the result bundle may already count it as a failure.

Waiting for logout before login still left a race inside the handshake

Mon, 21 Sep 2026 14:49:00 +0200

Correction 2026-10-31: The earlier version attributed the reported failure to an idle timer. Later source review ruled out that timer for this app. The injected-teardown reproduction and exclusion-gate fix remain valid; the production trigger is unknown.

Users authenticated with Face ID, and the login failed anyway with a generic “login failed” error. The password was right, and the biometric enrollment was fine. The server’s log for the affected user showed the last handshake step arriving on a session in its initial state, with no user bound to it.

The app waited for any teardown already running before starting login. A dedicated test injected a new teardown after that wait and reproduced the same server-state signature. Holding an exclusion gate for the whole handshake fixed that reproduction, but did not establish the cause of the reported incident.

Setup

A stateful, multi-step login (SRP-style): start a session, send the identity, send the proof, finish. The server tracks progress per session cookie.
A session teardown: sign out on the server, then clear the local cookie jar. begin() returns immediately, and concurrent begin() calls join one teardown.
An earlier fix for a related bug: before its handshake, login called waitForCompletion() so a sign-out still in flight couldn’t destroy the new session.
The reproduction explicitly calls begin() during the handshake. It does not rely on an idle timer.

login: { credential in
 await sessionTeardown.waitForCompletion() // once, before the handshake
 return await client.login(credential) // four round trips
}

Reproduce with the real stack

A dedicated live test drove the production login code against a development server and fired begin() at a fixed delay into the handshake. At 500 ms:

start -> {"state":"new"}
send identity -> {"state":"identified", "salt":...}
send proof (M1) -> {"state":"proof-verified", "M2":...}
logout() <- the teardown fires here
POST /logout
finish (keys sent)
Logout success
Session teardown: cookie jar cleared
Error: state "new"
-> failed(.other)

This matched the server-state signature logged for the user. In the reproduction, the one-time wait had nothing to wait for: no teardown was running when login started. The test started one between two round trips.

The trap inside the trap: which effect does the damage

The code comments blamed the cookie-jar clear: the concluding step would go out without a session cookie and land on an anonymous session. That would suggest a small fix: defer only the local cleanup.

In the reproduction’s trace, the cookie jar was cleared after the finish step had already gone out with valid cookies. The server sign-out reset the half-authenticated session, and the concluding step then arrived at a session the server had put back to new. Deferring only the jar clear would still fail this exact trace.

Before you choose what to defer, read the ordering on the wire. The local effect you can see easily may not be the one that broke things.

Fix: hold exclusion for the whole protocol

The teardown gets a gate. Login holds it from the first round trip to the last. A begin() that arrives while the gate is held is honored but deferred—neither its sign-out nor its cookie clear runs until the handshake releases the gate.

private struct TeardownState {
 var inFlight: Task<Void, Never>?
 var handshakes = 0 // a count, so overlapping logins can't release each other's gate
 var isHeldBack = false
}

begin: {
 state.withValue { s in
 guard s.inFlight == nil else { return } // join the running one
 guard s.handshakes == 0 else { s.isHeldBack = true; return }
 s.inFlight = Task { await runTeardown() } // clears inFlight when done
 }
},
beginHandshake: {
 // Wait out a running teardown, then claim the gate. Loop, because the slot
 // is only free on a later pass.
 while let running = state.withValue({ s -> Task<Void, Never>? in
 guard let t = s.inFlight else { s.handshakes += 1; return nil }
 return t
 }) {
 await running.value
 }
},
endHandshake: {
 state.withValue { s in
 s.handshakes -= 1
 guard s.handshakes == 0, s.isHeldBack else { return }
 s.isHeldBack = false
 s.inFlight = Task { await runTeardown() }
 }
}

func excludingTeardown<T>(_ body: () async -> T) async -> T {
 await beginHandshake()
 defer { endHandshake() }
 return await body()
}

login: { credential in
 await sessionTeardown.excludingTeardown {
 await client.login(credential)
 }
}

The other properties stayed the same. begin() still returns immediately. A second begin() still means one teardown, whether that teardown is running or held back. A teardown whose sign-out throws still releases its waiters. Logout still happens: it runs right after login, which then ends in a signed-out state on purpose.

Later source review found that this app created its idle timer only after the full login completed and dropped it when the login screen appeared. The shipped revision had the same wiring. The earlier claim that this timer disproved a signed-in-only assumption was withdrawn. The gate provides exclusion without depending on that reachability argument.

A sibling app did retain its timer after logout and needed a signed-in guard. That was a separate timer-lifetime defect, not evidence that the timer caused this app’s reported failure.

Verification

Unit test for the new direction. A teardown begun inside excludingTeardown runs neither effect until the body returns. The expected order is [handshake, signOut, clearCookieJar]. Inside the body, the test awaits waitForCompletion() rather than Task.yield(), so a buggy teardown is guaranteed a chance to run. A yield would leave that to the scheduler.
Unit test for the old direction. A teardown already running still finishes before the handshake starts. That is the guarantee the earlier fix provided.
Injected-teardown sweep. The reproduction fires the teardown at 100, 200, 300, 400, 500 and 700 ms. It had been marked XCTExpectFailure. After the fix, every delay logged in:

teardown at 100ms -> loggedIn
teardown at 200ms -> loggedIn
...
teardown at 700ms -> loggedIn

The expected-failure marker was removed in the same commit.

What this doesn’t prove

The reproduction establishes a failure mechanism and verifies the exclusion fix. It does not prove that this mechanism caused the reported incident or identify its triggering call. We ruled out the idle timer for this app; the field trigger remained unknown.
The dedicated reproduction and the unit tests verify the fix. The live test class still exited with failures. They came from a separate host-app dependency problem in the test process, and another test in that class still tracks an unrelated second-login bug. Don’t read “the sweep passes” as “the live suite is green”.
The ordinary test plan passed, but live tests are opt-in there, so it says nothing about the server interaction.
Which delays hit the window depends on latency to the server. A sweep is better than a single delay, but it is still a sample.

Takeaways

Waiting once for cleanup before a multi-step protocol protects only that instant. If cleanup can start during the protocol, exclude it for the whole protocol.
Defer cleanup, don’t drop it. Queue the request and run it when the gate is released.
Count holders instead of using a flag, so two overlapping logins can’t release the gate from under each other.
Read the wire ordering before you choose what to defer. Here, the server sign-out did the damage, not the local cookie clear that everyone suspected.
A matching reproduction does not identify the production trigger. Trace the initiating call in the affected build before naming it as the cause of an incident.

Ios on Lessons learned

Offline login in an iOS or Android app: design it as offline unlock

What an offline unlock can and cannot prove

A state machine where a stale device never prompts

Wrap keys; never encrypt data with the password

Why the password path needs the device too

A six-digit PIN is a million candidates

The biometric prompt must unlock a key

Android: pass a CryptoObject

iOS: a Secure Enclave key and ECIES

Data Protection classes that fail after lock

Offline expiry needs a clock that counts sleep

Documents: chunked AEAD and plaintext that outlives the app

Lock, logout, and Keychain items that survive uninstall

Autofill is offline unlock under another name

Verify who is asking

Users without a password

Caveats

Test the failure paths

Takeaway

A shared Swift timeout left an earlier task without a deadline

One timer could not cover overlapping fetches

Put the deadline beside the operation

Prove that the waiter needs this deadline

A cancellation deadline is not a hard timeout

SwiftUI large title disappears after tapping the selected tab again

The title still existed

A local modifier changed later navigation bars

Why the one-line hotfix was reversed

Verify the interaction, not just the label

Xcode Archive can ship the wrong display name despite correct source settings

Source checks missed the artifact

Check the processed plist during the build

Prove that wrong builds fail

An offline cache TTL needs a clock-rollback policy

A negative age passed the upper-bound check

Retain the latest observed time

Refusing access did not mean deleting the cache

Test the rollback twice

A high-water mark cannot establish time that was never observed

iOS jailbreak protection in 2026: detection is a risk signal, not a security boundary

The short version

How a working check silently stopped working

When OWASP says to implement jailbreak detection

The current techniques are rootless and designed to hide

The response matters more than the Boolean

App Attest authenticates app instances, not clean devices

Test implementation, behavior, and bypass resistance

A reviewable 2026 “lege artis” baseline

Takeaway

References

A five-second Swift Testing wait timed out after its loop had run five times

Setup

Reproduce before guessing

Dead end: a longer timeout

Fix: spend both budgets before failing

Pin it with a controlled starvation test

Verify both directions

A second guess hiding in the same tests

Takeaway

Snapshot precision 0.99 let a wrong text line pass all seven screen tests

Setup

The arithmetic

Measuring the mutation

The fix

Shrink the frame when you can

Takeaway

xcodebuild says TEST SUCCEEDED, the xcresult says "Issues recorded without an associated test or suite"

Setup

What happened

Dead end: set the dependency at launch

Fix: don’t show the app UI while hosting tests

Takeaway

Waiting for logout before login still left a race inside the handshake

Setup

Reproduce with the real stack

The trap inside the trap: which effect does the damage

Fix: hold exclusion for the whole protocol

Verification

What this doesn’t prove

Android: pass a `CryptoObject`