iOS Keychain Interview Questions: Accessibility Classes, Access Groups, and Migration

A refresh token works during foreground login but disappears from the app's point of view when a background job runs. After a release changes Keychain Sharing, an extension reports that the same account has no stored credential. Which problem would you investigate first?

For iOS Keychain interview questions, separate three contracts: when a secret is accessible, which signed targets can access it, and what survives a migration. Choosing a protection class does not configure sharing. Configuring sharing does not make an item portable to a new device. Neither choice proves that a server still accepts the token.

This article is for iOS engineers preparing storage and authentication discussions. Apple documentation supplies platform facts; the token scenarios and migration ledger are original exercises, not employer interview reports or physical-device test results. Start with Design A ChatGPT-Style Assistant Product and explain how its mobile client would recover credentials after backgrounding.

How should you answer an iOS Keychain accessibility question?

Ask what operation needs the secret, in which device state, and with which recovery expectations. A user-confirmed transfer and an unattended refresh do not have the same requirements. Avoid answering “use the most secure class” without explaining whether that class allows the product to function.

Official: Apple's accessibility guidance distinguishes access while unlocked from access after the first unlock following a restart. Its ThisDeviceOnly variants restrict restoration onto a different device. User-presence requirements are a separate access-control choice.

Use this original decision table as a starting point, not a universal storage policy:

Product requirement	Candidate choice	Question that must remain explicit
Foreground session secret, unlocked device	kSecAttrAccessibleWhenUnlocked	Should restoration to a different device be allowed?
Background refresh after the user has unlocked once	kSecAttrAccessibleAfterFirstUnlock	Is post-reboot, pre-unlock failure acceptable?
Device-bound foreground credential	kSecAttrAccessibleWhenUnlockedThisDeviceOnly	How will the user reauthenticate on a replacement phone?
Sensitive secret requiring a device passcode	kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly	What happens when the passcode is removed?

Official: Apple's Keychain data-protection overview describes the passcode-set class as unavailable for iCloud synchronization or backup. Removing or resetting the passcode makes its items unusable. It also identifies after-first-unlock accessibility as useful for background updates.

The preparation lesson is to connect storage to failure handling. If the background job cannot obtain its token, it should not silently downgrade protection or treat every storage failure as a logout. Decide whether it postpones work, requests foreground authentication, or reports a recoverable state.

Accessibility is not the same as an API permission on the backend. A readable refresh token can be expired, rotated, or revoked. Conversely, a valid server session does not make its locally stored material accessible before the device reaches the required state.

Trace a reboot, unlock, and background refresh

Here is an original device-state exercise. Assume a passcode-protected phone and a token stored with after-first-unlock accessibility, without an additional interactive access-control requirement.

At time A, the phone restarts and has not yet been unlocked. At time B, the user unlocks it. At time C, the screen locks again and a permitted background task tries to read the token. The expected accessibility answers are unavailable, available, and available respectively. Restarting again resets this sequence.

Now change only the class to when-unlocked. The read at C is no longer permitted by that accessibility rule. Change only the workload to an operation demanding user presence, and unattended execution has another obstacle. These are different failures, even if the application displays the same generic error.

For your answer, write the operation and device state next to each expected result. Do not infer that a background task will run merely because the credential could be accessible. Scheduling, network availability, application lifecycle, and secret access remain separate conditions.

An interviewer might ask whether you would put the token in UserDefaults to avoid the problem. Explain the trade-off in terms of the secret, not convenience: the storage mechanism should preserve its security requirements, while the application adapts its retry or authentication flow.

The same reasoning applies to tests. A foreground simulator read can exercise a wrapper's query construction and error mapping. It does not establish real-device reboot, passcode, backup, biometric, or restoration behavior. Keep those expected platform cases in a device test plan without claiming they were executed.

Why can another target fail to find the item?

Official: Apple's sharing documentation explains that an item belongs to one access group, while an app may belong to several. Signed entitlements determine the app's groups. An omitted group on add uses the default; an omitted group on search can search the app's accessible groups.

Consequently, “the service and account strings match” is insufficient evidence. Include the item class, access group, synchronizable setting where relevant, and other query attributes in the investigation. Inspect the entitlements of the built, signed targets rather than only the text in an Xcode project.

Suppose release 1 writes a generic-password token under the app's private group. Release 2 introduces a shared group for the main app and extension, and new writes explicitly target that shared group. The extension's inability to read release 1's item is not proof that the old secret was deleted.

This is an original namespace scenario: the old and new lookups name different storage locations. Record which released version wrote the item and which target is reading it. A fresh install that writes directly to the shared namespace cannot reproduce the upgrade path by itself.

Use the smallest sharing boundary consistent with the feature. Sharing a credential allows another signed target in the relevant group to use it; it is not merely a cosmetic naming convention. Separate secrets that do not need common access, and explain how logout affects shared versus private session state.

Also avoid saying an App Group is simply “the same thing” as a keychain group. Apple's sharing documentation describes overlapping capabilities, including additional non-keychain sharing through App Groups. State the capability you need and verify the signed target's actual group membership.

Design a namespace migration that can be interrupted

A migration should preserve at least one recoverable credential until the new representation is usable. This is an application-level invariant, not a claim that multiple Keychain calls form a transaction.

For this original exercise, the main app remains entitled to read both the old private namespace and the new shared namespace during the transition. The extension can read only the shared namespace. The server token is unchanged, and no concurrent token rotation occurs; a production design must handle that separately.

Define the intended sequence:

1. Read the new namespace first; validate its representation before using it.
2. If it is absent, read the exact old item when the device permits access.
3. Write or deliberately update the destination, preserving the required protection.
4. Read back the destination and confirm that the intended target can use it.
5. Retire the exact old item only after the rollout and rollback contract permits it.

The phrase “exact old item” matters. Official: Apple's update and deletion guidance warns that update and delete operations affect all matching items. A duplicate add is also not an update strategy for an existing item with the same primary attributes.

In your practice ledger, interrupt execution after each step. Before the destination write, the old item remains. After writing but before retiring the old item, both may exist. A retry should recognize the destination and avoid producing contradictory token state. After retirement, rollback must either understand the new namespace or require controlled reauthentication.

Do not resolve an unexpected destination item by overwriting it blindly. It could be newer than the source because another target refreshed the session. Explain ownership of credential refresh and how the migration compares versions or serializes access. “Read, then add” alone does not prevent a concurrent writer from changing the situation.

If the transition cannot preserve old-group access, this copy strategy is unavailable. State that limitation early. Your recovery may need a fresh login, server-mediated reenrollment, or a pre-transfer release strategy validated for the actual distribution path.

Which kind of migration is the interviewer asking about?

Distinguish a schema or namespace change, a backup restoration, synchronization, a new device, and an ownership transfer. They differ in who can read the source, what protection applies, and which signing identity owns the destination.

For a namespace upgrade under compatible signing, the practical question is whether the released app can read both locations and preserve rollback behavior. For a new device, ask whether the chosen protection permits the item to migrate and what the product does when it does not.

Official: Apple's app-transfer overview warns that keychain sharing continues only until an update after transfer and describes rebuilding sharing with the recipient's group. Do not promise seamless access-group continuity across development teams.

The original interview follow-up is an account-recovery decision: a transferred app starts, finds no usable local token, and the user cannot access the former device. Explain how the app distinguishes this from a server-side account deletion. Present a safe reauthentication flow and avoid making possession of an old local identifier sufficient proof of account ownership.

Do not promise that deleting and reinstalling an app is a supported universal credential-reset contract. A product should define explicit logout, revocation, and enrollment behavior, then test its supported installation and upgrade paths. Local secret deletion and backend session invalidation are different operations.

What evidence belongs in a Keychain failure report?

Capture the operation, status, target identity, query shape, protection expectation, and device-state category. Redact the value. A useful report can say that a specific generic-password read in the shared group failed after an upgrade; it should not contain a refresh token or a full credential dump.

Maintain distinct outcomes for absent item, unavailable access, invalid configuration, and a server rejecting a readable token. Do not assign every possible OSStatus the same recovery action. Consult the relevant operation's documented status behavior and preserve the raw status internally for diagnosis.

A test double can verify that a wrapper uses the intended service, account, and group, and that unsuccessful writes do not trigger deletion of the source. It cannot prove Apple's platform enforcement. For the original migration model, the useful local assertion is that interruption never removes the only recoverable copy before destination verification.

For physical-device testing, record the supported iOS version, signed build, device state, backup type, and destination device. A report saying “migration passed” without specifying which migration is difficult to evaluate and easy to overgeneralize.

Sources and Further Reading

Primary documentation checked October 1, 2026. Examples are synthetic reasoning exercises; physical-iOS access, backup, and transfer tests are not claimed.

• Apple: Restricting keychain item accessibility
• Apple Platform Security: Keychain data protection
• Apple: Sharing access to keychain items among a collection of apps
• Apple: Updating and deleting keychain items
• Apple App Store Connect: Overview of app transfer