Apple Software Engineer Interview Questions (2026): What They Actually Ask

Iterative approach with three pointers: prev, current, and next. Walk the list once, flipping each node's next pointer to point backward as you go. Time O(n), space O(1). A recursive version exists too, but it risks a stack overflow on a very long list, which matters for anything modeling a real linked structure such as an undo history.

Reported as a warm-up question before the main coding problem in Apple ICT2 phone screens (onsites.fyi, 2024). Interviewers use it to confirm pointer fluency before moving to something harder.

func reverseList(_ head: ListNode?) -> ListNode? {
    var prev: ListNode? = nil
    var current = head
    while current != nil {
        let next = current?.next
        current?.next = prev
        prev = current
        current = next
    }
    return prev
}

Structs are value types, copied on assignment and passed by value; classes are reference types, shared by reference and managed under ARC. Default to a struct for anything modeling data without identity, a point, a color, a model wrapping decoded API fields. Reach for a class when multiple owners need to share mutable state (a view controller's data source, a cache), when you need inheritance, or when bridging to an Objective-C API that expects object identity.

Reported as an opening domain question for iOS roles across levels (MentorCruise, 2026). The follow-up almost always asks for a bug caused by using a class out of habit; unexpected sharing, two variables silently mutating the same instance, is the answer interviewers are listening for.

Use guard let for early exit: when the rest of the function needs the value and there's no reasonable fallback, it unwraps once and keeps the value in scope for everything after it. Use if let for conditional branching, when the logic genuinely differs depending on whether the value exists and the unwrapped value is only needed inside that branch. Use nil-coalescing (??) to supply a default inline, appropriate when a sensible fallback exists and no branching is needed at all.

Reported as a fundamentals check early in Apple iOS phone screens (TechPrep, 2026). Force-unwrapping with ! during live coding reads as a mild red flag unless it's immediately justified, for instance right after a guard that already proved the value is non-nil.

guard let userID = session.userID else {
    return .unauthorized
}
// userID stays in scope for the rest of the function

Apple ICT3 and above are expected to multiply the team, not just ship their own work. Interviewers look for specifics: did you do code reviews with teaching intent (explaining why, not just what), pair programming, design review participation, or structured growth conversations? "I answer questions when they come to me" is not the answer for senior roles.

Good answer structure: one concrete example of a junior engineer you helped grow, what you did, and what the outcome was for them (a feature they owned, a skill they acquired, a role they moved into). Reported as standard ICT3+ behavioral (onsites.fyi, 2025).

Be concrete about what you cut, why, and what it cost. Apple's craftsmanship culture means interviewers want to see that you treat this as a real trade-off you take seriously, not a speed-vs-perfection binary. The candidate account from interviewing.io's Apple guide noted: "In behavioral, you gotta be a rockstar. If you can't code but you're good at system design and behavioral, they'll forgive subpar coding rounds." That signals how much behavioral performance matters here.

Follow-up: "Was that the right call?" Have a real answer. If the thing you deferred created a later incident, say so. Apple interviewers are more impressed by intellectual honesty than by stories where every decision worked out cleanly.

This isn't a trick question looking for false modesty. A concrete, specific mistake, what went wrong, why it happened, and what actually changed afterward, reads as more senior than a vague or hedge-everything answer. The weakest response is a "mistake" that isn't one, "I work too hard" in disguise, and Apple interviewers notice that dodge immediately.

Reported as a standard, lower-stakes behavioral warm-up across Apple levels (Glassdoor, 2025). It often opens the behavioral round precisely because it's low-stakes enough to see how a candidate talks about failure before the harder questions land.

Most candidates report 5 to 12 weeks, but the range is wider than at other FAANG companies. Some teams move in 3 to 4 weeks for urgent headcount; others take 3 to 4 months, particularly for specialized roles. The front-loaded screening (sometimes 3 phone rounds before the onsite) adds time that surprises candidates accustomed to faster loops at Meta or Amazon. Offer decisions typically happen within a week of the final onsite round.

Yes, more so than at any other major tech company. Apple explicitly does not run a standardized loop across teams. The iOS frameworks team runs a different set of questions than the iCloud infrastructure team, and both run a different loop than the Apple Silicon compilers team. Ask your recruiter what the technical focus is before you start preparing. "Will the coding rounds be LeetCode-style or domain-specific?" and "Is there a system design round in this loop?" are both fair questions and recruiters will answer them.

Swift is strongly preferred for iOS, macOS, and frameworks roles, and interviewers notice if you use Python or Java for a problem that has a natural Swift solution. For backend, infrastructure, or compiler roles, C++, Python, or Java are acceptable. If you're uncertain, ask your recruiter ahead of the coding round which language the team prefers. Interviewers will not penalize you for asking that question in advance.

Unlike Google, where you can be matched to a team after passing a central hiring committee, Apple's process is team-specific from the start. You interview for a specific team's open headcount. If that loop results in an offer, it's already tied to that team. You can interview with multiple Apple teams simultaneously (this is encouraged and there is no penalty for doing so), which improves your odds if you're flexible on team placement. Post-offer team switching is rare.

Apple's engineering levels are ICT2 (new grad or early career), ICT3 (mid-level, roughly 3-6 years of experience), ICT4 (senior, roughly 6-10 years), and ICT5 and above (staff and principal). ICT3 is the most common hiring target. ICT4 loops include a more rigorous system design round and a leadership behavioral component that ICT2/ICT3 loops may not. Level calibration is done by the hiring team based on your experience, not by a separate calibration committee.

Occasionally at ICT4 and above, but the median is Medium. The more reliable predictor of difficulty is the follow-up question pattern: Apple interviewers go deep on a medium problem rather than moving to a harder one. Expect follow-ups about edge cases, alternative approaches, time and space complexity analysis, and how your solution would change under different constraints (concurrent access, memory pressure, streaming input). A clean medium solution you can defend thoroughly is worth more than a hard solution you can barely explain.

Array is an ordered collection that keeps whatever order you insert things in and allows duplicates. Under the hood it's contiguous storage, so indexed access is O(1), but checking whether a value exists means walking the whole thing, O(n) unless it's sorted and you binary search. Set is backed by a hash table. There's no ordering guarantee, no duplicates are allowed, and membership checks, inserts, and removals are all O(1) on average, assuming a decent hash function and low collision rate.

In practice I reach for Set when the question is "have I seen this before" or "give me the unique items," like deduplicating a list of user IDs or checking tag membership in a loop. I reach for Array when order matters, when I need to iterate in a predictable sequence, or when I need positional access like "give me the third item." One gotcha worth mentioning in an interview: anything you put in a Set has to conform to Hashable, and if you're hashing a custom struct, make sure the hash and equality logic actually agree with each other, otherwise you get silent bugs where lookups fail even though the "equal" object is in the set.

var gives you a mutable binding, let gives you an immutable one. For value types, which is most of what you touch day to day, structs, enums, Int, String, Array, let freezes the entire value, including any properties that were declared var inside the struct's own definition. That trips people up early on: you can't call a mutating method on a struct instance that was declared with let, even if the method only touches one property, because from the compiler's view you're trying to mutate something you promised not to change.

For reference types it works differently. let on a class instance only locks the reference itself, you can't repoint that variable to a different object, but the object's own var properties can still change freely through that reference. That's a common interview gotcha and worth calling out explicitly if you get the question.

Swift nudges you toward let by default for a few real reasons: it documents intent so the next reader knows a value isn't supposed to change, it lets the compiler apply certain optimizations since it knows the binding is fixed, and it removes a whole class of bugs where a value gets mutated somewhere unexpected in a long function. Xcode will even warn you "variable was never mutated, consider changing to let" if you default to var out of habit, which is the compiler's polite way of telling you to tighten things up.

Expand-around-center approach. For each index, treat it as the center of an odd-length palindrome (one center) and an even-length palindrome (two centers), then expand outward while the characters match. Count each valid expansion. Time complexity O(n^2), space O(1).

Reported from a phone screen for an iOS frameworks role (onsites.fyi, 2024). The Apple-specific framing in the problem was around text editors like Notes, where finding palindromes relates to text parsing. Interviewers often follow up asking about DP approaches, which achieve the same O(n^2) time but with O(n^2) space for the table.

func countSubstrings(_ s: String) -> Int {
    let chars = Array(s)
    let n = chars.count
    var count = 0

    func expand(_ left: Int, _ right: Int) {
        var l = left, r = right
        while l >= 0 && r < n && chars[l] == chars[r] {
            count += 1
            l -= 1
            r += 1
        }
    }

    for i in 0..<n {
        expand(i, i)     // odd-length
        expand(i, i + 1) // even-length
    }
    return count
}

Sort by start time. Iterate and compare each interval's start to the last merged interval's end. If they overlap (start of current is less than or equal to end of last merged), extend the end. Otherwise append as a new interval.

Reported as an ICT2 phone screen question (onsites.fyi, Apple ICT2 guide). The Calendar framing is genuine, Apple interviewers contextualize DSA problems in Apple product terms. Edge cases interviewers watch for: single-interval input, fully nested intervals, and intervals that share only an endpoint.

func merge(_ intervals: [[Int]]) -> [[Int]] {
    guard intervals.count > 1 else { return intervals }
    let sorted = intervals.sorted { $0[0] < $1[0] }
    var result = [sorted[0]]

    for interval in sorted.dropFirst() {
        if interval[0] <= result.last![1] {
            result[result.count - 1][1] = max(result.last![1], interval[1])
        } else {
            result.append(interval)
        }
    }
    return result
}

Sort the array first. For each element at index i, use two pointers from i+1 and n-1 moving inward. If the three-way sum matches, return true. If too small, advance the left pointer. If too large, retreat the right pointer. Time O(n^2), space O(1) excluding sort.

Reported directly from a candidate Exponent documented in their Apple SWE guide (2025). Apple interviewers follow up with "what if the array is already sorted?" and "what if there are duplicates?" Have both answers ready.

Level-order serialization using a queue. Encode null children explicitly (e.g., as the string "null") so the structure can be reconstructed. Deserialization rebuilds the tree by processing nodes level by level, assigning left and right children from the queue of serialized values.

Reported as an ICT2 coding question with the iCloud syncing framing (onsites.fyi, 2024). The follow-up is usually about format choice: why level-order vs pre-order? Level-order is slightly more predictable for a human reading the serialized string, pre-order is marginally more compact. Either answer is defensible with a reason.

Maintain a second auxiliary stack that tracks the running minimum. On each push, push to the main stack and push the minimum of the new value and the current auxiliary stack top to the auxiliary stack. On pop, pop from both stacks. getMinimum() returns the top of the auxiliary stack.

Reported directly from an Apple onsite candidate account in Exponent's Apple guide (2025). The O(1) constraint is the point; a naive scan of the main stack is O(n) and interviewers will not accept it.

Floyd's tortoise and hare. Two pointers start at the head; the slow pointer moves one node at a time, the fast pointer moves two. If they meet, a cycle exists. To find where the cycle starts, reset one pointer to the head and leave the other at the meeting point, then advance both one node at a time; they converge exactly at the cycle's entry node. Time O(n), space O(1), no hash set required.

Reported as the follow-up to the plain reverse-linked-list warm-up in Apple ICT2 and ICT3 phone screens (onsites.fyi, 2024; Exponent Apple guide, 2025). The follow-up almost always specifies O(1) space, which rules out the hash-set approach candidates reach for first.

A common mistake is comparing each node only against its immediate children, which misses violations further up the tree. The correct approach passes down a valid (lower, upper) range as you recurse, narrowing that range on each left or right step. A node is valid only if its value falls strictly inside the range it inherited from its ancestors, not just relative to its parent.

Reported as an Apple ICT3 coding round question (onsites.fyi, 2025). Interviewers often ask for the buggy parent-only-comparison version first, then ask why it fails on a specific skewed tree, before asking for the corrected range-based solution.

func isValidBST(_ root: TreeNode?, _ lower: Int? = nil, _ upper: Int? = nil) -> Bool {
    guard let node = root else { return true }
    if let lower = lower, node.val <= lower { return false }
    if let upper = upper, node.val >= upper { return false }
    return isValidBST(node.left, lower, node.val) && isValidBST(node.right, node.val, upper)
}

Recursive post-order search. At each node, recurse into the left and right subtrees looking for the two target nodes. If both targets turn up in different subtrees of the current node, that node is the lowest common ancestor. If only one side finds something, propagate that result upward. The base case returns the node itself if it matches one of the two targets.

This one showed up in an Apple ICT2 loop framed literally around Finder: given two files, find the shared parent folder (Glassdoor submission, 2025). The framing isn't just flavor text since Finder's directory structure genuinely is a tree, and the interviewer expects you to map the abstract tree problem onto it directly.

Each trie node holds a dictionary of children keyed by character and a flag marking whether a complete word ends there. Insertion walks the trie one character at a time, creating nodes as needed. A prefix search walks down to the node matching the prefix, then a depth-first search from that node collects every complete word below it, which is exactly the shape autocomplete features like Spotlight or the Safari address bar need.

Reported as a domain-round question for a search infrastructure team (onsites.fyi, 2025). The near-universal follow-up is about memory: a plain trie storing full Unicode strings can bloat quickly, and interviewers want you to at least mention a compressed trie (radix tree) as the optimization.

final class TrieNode {
    var children: [Character: TrieNode] = [:]
    var isWord = false
}

final class Trie {
    private let root = TrieNode()

    func insert(_ word: String) {
        var node = root
        for char in word {
            if node.children[char] == nil { node.children[char] = TrieNode() }
            node = node.children[char]!
        }
        node.isWord = true
    }

    func wordsWithPrefix(_ prefix: String) -> [String] {
        var node = root
        for char in prefix {
            guard let next = node.children[char] else { return [] }
            node = next
        }
        var results: [String] = []
        collect(node, prefix, &results)
        return results
    }

    private func collect(_ node: TrieNode, _ path: String, _ results: inout [String]) {
        if node.isWord { results.append(path) }
        for (char, child) in node.children {
            collect(child, path + String(char), &results)
        }
    }
}

Standard flood-fill over a 2D grid. Iterate every cell; when an unvisited "land" cell turns up, run a depth-first or breadth-first search that marks every connected land cell as visited, and increment a counter once per new region found. Time and space are both O(rows times cols).

Reported in an Apple ICT2/ICT3 loop with a Photos framing: given a grid representing photo capture locations or timestamps clustered together, count the number of distinct clusters (onsites.fyi, 2024). The algorithm underneath is identical to the classic number-of-islands problem. The Photos framing is Apple checking whether you can map an abstract grid problem onto a real product feature, since Memories does actually group photos by time and location proximity.

def count_regions(grid):
    if not grid:
        return 0
    rows, cols = len(grid), len(grid[0])
    visited = set()

    def dfs(r, c):
        if (r < 0 or r >= rows or c < 0 or c >= cols
                or (r, c) in visited or grid[r][c] == 0):
            return
        visited.add((r, c))
        for dr, dc in [(1, 0), (-1, 0), (0, 1), (0, -1)]:
            dfs(r + dr, c + dc)

    count = 0
    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == 1 and (r, c) not in visited:
                dfs(r, c)
                count += 1
    return count

Maintain a min-heap of size k. Push each element; once the heap exceeds size k, pop the smallest. After the array is fully processed, the minimum still in the heap is the kth largest. Time O(n log k), space O(k), which beats a full sort's O(n log n) when k is small relative to n. The near-guaranteed follow-up is quickselect, a partition-based approach with average-case O(n) time, though its worst case degrades to O(n^2) without a randomized pivot.

Reported in Apple onsite loops framed around ranking, for example surfacing the kth most storage-heavy app in Settings, iPhone Storage (Glassdoor, 2025). Interviewers ask candidates to justify a heap sized to k rather than n, since a full n-sized heap defeats the point of the approach.

GCD operates on work items dispatched to queues (serial or concurrent). It's mature, well-understood, and still appropriate for callback-heavy code or when integrating with older Objective-C APIs. Swift Concurrency (async/await, actors, structured concurrency) introduced in Swift 5.5 provides safer concurrency primitives through the compiler's data race detection (enforced via Sendable protocol and actor isolation) and more readable sequential-looking async code.

Prefer async/await for new Swift code where the full call chain can be made async. GCD still makes sense when working at the boundary of a C or Objective-C API, or when you need fine-grained queue priority control that doesn't map cleanly to Swift task priorities. Reported as a standard domain-round question for iOS and frameworks roles (TechPrep, 2026; MentorCruise iOS guide, 2026).

A retain cycle occurs when two objects hold strong references to each other, preventing ARC from ever deallocating either. The reference count of each object never reaches zero. The standard fix: make one side of the reference weak (non-owning, automatically becomes nil when the referent deallocates) or unowned (non-owning, never becomes nil, crashes if accessed after deallocation). In closures, the common pattern is a capture list: [weak self] guards against the closure retaining self strongly.

Reported as a standard iOS domain question (TechPrep, 2026; MentorCruise, 2026). Interviewers follow up with: "how do you detect retain cycles in production?" The answer involves Xcode's Memory Graph Debugger and Instruments' Leaks template.

Define a protocol describing the capability, for example Cacheable with a cacheKey property, then write a protocol extension supplying a default implementation of whatever logic should be shared. Any type, struct, enum, or class, can conform without inheriting from a common base class, which sidesteps single inheritance and lets value types participate in shared behavior that would otherwise require a class hierarchy.

Reported as a domain question for frameworks and platform roles (TechPrep, 2026). Apple's own standard library leans on this pattern heavily (Sequence, Collection, and Equatable are protocols with extensive default implementations supplied via extensions), so interviewers expect you to recognize it as idiomatic Swift rather than a workaround for missing multiple inheritance.

Combine's publisher model fits continuous, potentially infinite streams naturally; CLLocationManager's delegate callbacks map cleanly onto a Publisher, and operators like debounce, throttle, and combineLatest were built for exactly this kind of event stream. Swift Concurrency's AsyncSequence covers similar ground and integrates more tightly with structured concurrency, a location stream consumed inside a Task gets cancelled automatically when that Task's scope ends, but its operator library is still thinner than Combine's.

In practice, teams that adopted Combine early tend to keep it for existing location and networking code, while new code increasingly reaches for AsyncSequence given tighter integration with async/await used elsewhere in the same codebase. Reported as a domain question for teams with heavy Core Location or real-time data usage (onsites.fyi, 2025). There's no single correct pick here; interviewers are evaluating whether you understand the actual trade-off, not whether you named their preferred framework.

The Secure Enclave is a dedicated security coprocessor on Apple silicon (A-series and M-series chips) that runs its own OS and is physically isolated from the application processor. Private keys stored in the Secure Enclave never leave it: the chip signs data on your behalf, your code never sees the private key bytes. Face ID and Touch ID biometric templates live exclusively in the Secure Enclave.

Use Secure Enclave for key material that must be tied to biometric authentication (kSecAttrTokenIDSecureEnclave) and for credentials that should be invalidated when the user's biometrics change. The standard Keychain is appropriate for passwords, tokens, and secrets that should survive biometric enrollment changes or device restore scenarios. Reported as a domain round question for iOS platform roles (TechPrep, 2026).

NSPersistentCloudKitContainer mirrors a Core Data store to a private CloudKit database. Syncing is asynchronous and operates through CloudKit's push-and-fetch model: local changes are uploaded when connectivity allows, remote changes are fetched via CKSubscription push notifications or periodic polling. The container handles conflict resolution using a last-writer-wins strategy based on record modification timestamps.

Failure modes: CloudKit quota exhaustion silently stops sync without user-visible errors (you need to monitor CKContainer.accountStatus). Partial sync states where one device has records the other doesn't can be persistent if the user's iCloud account is signed out and back in. Migration: changing the Core Data schema in a way that's incompatible with the CloudKit record type causes sync to fail until the schema mismatch is resolved. Reported in Apple frameworks interview prep materials (TechPrep, 2026).

Codable auto-synthesizes decoding when the model's property types and names match the JSON structure exactly, but real APIs rarely stay that clean. Optional properties handle missing keys for free, since Codable treats a missing key on an Optional property as nil instead of throwing. For fields that arrive as different types across API versions, a boolean sometimes sent as the string "true", or that need renaming, write a custom init(from decoder:) that reads through a keyed container and applies the conversion or fallback by hand rather than relying on synthesis.

Reported as a networking-layer question for backend-adjacent iOS roles (TechPrep, 2026). The most common follow-up: how do you stop an entire decode from failing because of one malformed field? The answer is decoding fields individually inside a custom initializer, catching per-field errors, and defaulting the one bad field instead of letting it throw for the whole object.

On backgrounding, iOS gives the app a short grace period, historically around 30 seconds under UIApplication's background task API, before suspending it entirely. A suspended app stops executing code but stays resident in memory until the system needs to reclaim it. To finish something critical, an upload, a database write, call beginBackgroundTask(expirationHandler:) before the transition completes, and call endBackgroundTask explicitly once the work is done; Apple's own documentation is explicit that failing to end the task wastes the app's remaining background budget and can get the process killed earlier on a future launch.

Reported as a lifecycle question in Apple frameworks interviews (onsites.fyi, 2025). The near-guaranteed follow-up: what's different about a BGProcessingTask versus a plain background task? BGProcessingTask, from the BackgroundTasks framework, is for longer, deferred work the system schedules opportunistically, overnight while the device charges, for example, rather than a short extension of the current session.

Root causes in order of frequency: cell reuse not being used correctly (creating new views instead of dequeuing), synchronous image loading on the main thread, layout calculations in cellForRowAt instead of being pre-computed, and non-opaque views forcing the compositor to blend layers. Diagnosis tools: Instruments' Core Animation template for frame timing, Xcode's View Debugger for blended layers, and Time Profiler to catch main-thread work.

Fix: move all image loading off main thread (URLSession, Kingfisher, or SDWebImage with background decoding), pre-calculate cell heights and cache them, make cell backgrounds and images opaque where possible. For modern code, UICollectionView with diffable data sources and UIHostingConfiguration (SwiftUI cells) reduce layout-related jitter because SwiftUI layout is declarative and doesn't require manual invalidation. Mentioned in Apple ICT3 interview guides and confirmed as a real question by multiple candidates (TechPrep, 2026).

Xcode uses a build graph (task dependency graph) that determines what can be compiled in parallel. Each source file is compiled independently when there are no header-level dependencies between them, enabling parallelism. Swift's whole-module optimization (WMO) compiles all files in a module together for better optimization but eliminates parallelism, so it's appropriate only for release builds. Slow builds commonly come from: circular dependencies between modules, type inference that's too complex for the compiler (leading to very long individual file compile times), or unnecessary recompilation triggered by touching a header that many files import.

Diagnose with Xcode's build timing data (Product > Perform Action > Build With Timing Summary). Fix with explicit type annotations to reduce inference cost, breaking circular dependencies, and splitting large modules. Reported as a domain question for Apple Developer Tools team roles (onsites.fyi, 2025).

The single highest-signal question in Apple's behavioral round, according to multiple interviewer accounts in the interviewing.io Apple guide. Generic answers ("I love Apple products," "Apple has the best ecosystem") are explicitly called out as red flags by Apple interviewers. The answer has to connect your engineering background to something specific about the team's technical work. Research what the team actually ships. Use the job description and LinkedIn to find team members' prior work. "I want to work on the push notification infrastructure because I spent two years dealing with unreliable delivery at my last job and I know exactly where the hard parts are" is the register of answer that lands.

Be specific about what made it a genuine risk: a decision you couldn't fully validate before shipping, something a colleague disagreed with, or a bet on a technology that wasn't proven yet. Apple's culture values craftsmanship and long-term quality, so the follow-up is almost always: "what would you have done differently?" Have an honest answer. Reported as a standard ICT3 behavioral question (onsites.fyi, Apple ICT3 guide).

The story structure that works: what the conventional approach was, why you departed from it, what data or reasoning justified the risk, and what you'd refine about that decision in hindsight. Candidates who claim perfect risk decisions are less credible than candidates who identify a real trade-off they made and stand behind it.

Apple's hardware-software integration means engineers work closely with design on a level that's unusual at most companies. Interviewers want to see that you can hold a technical position clearly and also engage genuinely with design constraints, not override them. The answer that doesn't work: "I explained the technical limitations and they accepted my approach." That's winning by authority. The answer that works: you found a middle path, you understood what the designer was trying to achieve at the user level, and you contributed a solution that served both constraints.

Reported as a standard behavioral question for roles that touch user-facing features (TechPrep, 2026).

Apple cares about reliability and ownership. Walk through the incident with the same specificity you'd bring to a system design question: what the symptom was, how you detected it (alert, user report, your own monitoring), how you triaged and scoped the blast radius, what the mitigation was, and what the permanent fix was. The post-mortem and blameless culture question often follows: "what process change prevented recurrence?"

Candidates who say they've never had a production incident are viewed skeptically. Candidates who describe an incident but didn't write a post-mortem are asked why. Reported as an ICT3 behavioral question (onsites.fyi, 2025).

At Apple, privacy is an engineering requirement embedded in the design process, not a compliance checkbox added at the end. Interviewers ask this to test whether you've actually worked in an environment where privacy drove technical decisions, or whether you've worked in environments where it was someone else's problem. Good answers involve on-device processing to avoid sending data to a server, minimal data collection by design, or anonymization strategies that preserved utility without exposing identity.

If your background is primarily enterprise or startup work where privacy wasn't prioritized, acknowledge that directly and describe what you'd do differently in Apple's environment. Authenticity lands better than constructing a story that doesn't ring true. Reported as a standard Apple behavioral question for platform and consumer app roles (TechPrep, 2026).

Apple's engineering culture expects you to push back with evidence, then commit fully once a decision is made, even one that didn't go your way. The weak answer sits at either extreme: capitulating immediately without making a real case, or relitigating the decision after it was final. Interviewers want a specific example, what your position was, what evidence or reasoning you brought, how the actual conversation went, and what you did once the call was made.

Reported as a common ICT3-plus behavioral question (onsites.fyi, 2025). A strong signal for interviewers is a candidate who can explain why the other person's reasoning made sense even where they still privately disagreed; that reads better than a story where the candidate turns out to have been right all along.

The answer should be specific about the technical concern itself, not "I told them to refactor it", and about how you delivered it in a way the person could actually hear. Apple's craftsmanship culture treats code review as a real quality gate, not a rubber stamp, so interviewers are checking whether you'll hold a bar with a peer, not just in your own code.

Reported as a peer-collaboration behavioral question in Apple ICT3 loops (TechPrep, 2026). Candidates who describe softening or skipping legitimate feedback to avoid friction read as a risk for a team shipping to a billion devices; the interviewer wants evidence you'll say the uncomfortable thing when the code actually warrants it.

Start with consistency requirements: photos must eventually appear on all devices, but they don't need to be available the instant they're taken (eventual consistency is acceptable; strong consistency would require expensive coordination). Key components: an upload queue on-device that handles offline scenarios (phone in airplane mode, low bandwidth), a metadata store that tracks photo identity across devices without duplicating full-resolution copies, and a CDN layer for download.

Privacy constraint: end-to-end encrypted photos mean the server cannot read content. Key management (device-held keys via Secure Enclave) is a required part of the answer. Conflict resolution (same photo edited on two devices) uses last-write-wins with a timestamp, with an edit history preserved for recovery. Reported from multiple Apple onsite accounts (TechPrep 2026; interviewquery.com Apple guide 2026). Interviewers push hard on: how do you handle low storage on a watch?

APNs delivers billions of notifications daily. Core design decisions: a persistent TCP connection per device (not polling) for low-latency delivery and battery efficiency. Device tokens are assigned by Apple, not by app developers, isolating app servers from device identity. The service needs: a gateway that accepts notifications from app servers, a router that maps device tokens to the active connection for that device, and a delivery guarantee mechanism (with configurable expiry for messages that cannot be delivered immediately).

Apple-specific constraints to mention: notification payload size limits (4 KB), silent push (background refresh with no visible alert), and critical alerts that bypass Do Not Disturb. The interviewer is likely testing whether you understand the persistent connection model vs polling, and why polling would drain battery unacceptably at scale. Mentioned in Apple system design interview guides (designgurus.io, 2026; interviewkickstart.com, 2026).

AirDrop uses Bluetooth Low Energy for device discovery (broadcasting a proximity hash derived from the contact hash, not full identity) and WiFi Direct for the actual transfer. Privacy is embedded in the discovery protocol: a device only reveals its identity to contacts, not to all nearby devices. The proximity hash is a one-way function of your Apple ID, so a non-contact device sees a hash they cannot reverse to an identity.

Interviewers want the privacy layer explained first, then the transfer protocol (TLS over WiFi Direct peer-to-peer, no internet required). The "everyone" mode (accept from all nearby devices) was restricted to 10-minute windows on Chinese market iPhones starting in 2022 due to regulatory pressure, which is the kind of real-world constraint that signals genuine Apple product knowledge. Mentioned in Apple ICT3 system design preparation materials (onsites.fyi, 2025).

The core insight: a lost device, or an AirTag, doesn't need its own internet connection to be findable. It broadcasts a rotating Bluetooth identifier derived from a public key only the owner holds. Any nearby Apple device, hundreds of millions of them collectively forming the Find My network, that overhears the broadcast anonymously reports its own GPS location plus the overheard identifier to Apple's servers, encrypted so only the owner's private key can decrypt which device that location belongs to. Apple's servers never learn the finder's identity or which device was found; they relay an encrypted blob and nothing else.

Rotating the broadcast identifier, roughly every 15 minutes, is what stops a stalker from tracking a device by its broadcast alone. Interviewers push on this rotation mechanism specifically, since without it the "anonymous" finder network would just be a tracking network with extra steps. Battery efficiency matters too: the whole scheme relies on Bluetooth Low Energy rather than on-device GPS, because a lost or dead AirTag still has to be locatable through nearby phones.

Reported in Apple ICT4 system design prep materials (designgurus.io, 2026; interviewkickstart.com, 2026). Candidates who lead with the privacy architecture, rather than the location math, tend to score higher, since that ordering matches how Apple's own engineers have described building it.

Each device a user owns holds its own key pair; a message sent to that user is encrypted separately once per registered device, not once per user, so the sender's device first looks up all of the recipient's active device keys from Apple's directory service before sending. APNs delivers the encrypted payload to whichever devices are online; a device that's offline picks the message up on its next connection through a queued-message mechanism, since APNs itself doesn't guarantee delivery to a device that's been offline for an extended stretch.

Read receipts need a per-device acknowledgment routed back to every one of the sender's devices, which is part of why toggling read receipts is a per-conversation setting rather than a device-wide one in practice: the receipt itself is just another small encrypted message routed the same way as the original text. The interesting failure case interviewers ask about is a newly added device: it has to backfill its key into the directory service before it can receive new messages, and messages sent before that device existed are never retroactively delivered to it.

Reported as an Apple ICT4 system design round for a messaging infrastructure team (interviewquery.com, 2026). The multi-device key fan-out is the detail that separates a strong answer from a generic chat-app design; candidates who describe iMessage as "a normal chat app with encryption" are missing the part Apple actually evaluates for.

Fixed-size array with read and write index pointers that wrap around using modulo. Write advances the write index; read advances the read index. The buffer is full when (write + 1) % capacity == read; empty when read == write. Thread safety requires either a mutex around read/write operations or atomic index updates.

Reported from Apple ICT2 onsite, domain round (onsites.fyi, 2024). The audio framing is not just flavor text. Interviewers expect you to recognize that audio buffers have strict latency requirements, so the implementation must be allocation-free at runtime (no dynamic memory in the hot path) and thread-safe for producer-consumer use.

class CircularBuffer<T> {
    private var buffer: [T?]
    private var readIndex = 0
    private var writeIndex = 0
    private let capacity: Int
    private let lock = NSLock()

    init(capacity: Int) {
        self.capacity = capacity
        self.buffer = Array(repeating: nil, count: capacity)
    }

    var isEmpty: Bool { readIndex == writeIndex }
    var isFull: Bool { (writeIndex + 1) % capacity == readIndex }

    func write(_ value: T) -> Bool {
        lock.lock(); defer { lock.unlock() }
        guard !isFull else { return false }
        buffer[writeIndex] = value
        writeIndex = (writeIndex + 1) % capacity
        return true
    }

    func read() -> T? {
        lock.lock(); defer { lock.unlock() }
        guard !isEmpty else { return nil }
        let value = buffer[readIndex]
        buffer[readIndex] = nil
        readIndex = (readIndex + 1) % capacity
        return value
    }
}

Dictionary for O(1) key lookup combined with a doubly linked list for O(1) recency tracking. Moving a node to the head on access and evicting the tail on capacity overflow are both O(1) given the node reference from the dictionary. Thread safety: wrap operations in a serial DispatchQueue (simple, effective) or use an actor (Swift Concurrency approach, preferred in modern Swift).

Reported as an ICT2 coding round question (onsites.fyi, 2024). The Safari framing means interviewers expect you to think about memory pressure: what happens when the device is under low-memory conditions? The correct answer mentions memory warnings triggering proactive eviction, not waiting for the capacity limit.

actor LRUCache<Key: Hashable, Value> {
    private let capacity: Int
    private var map: [Key: Node] = [:]
    private var head: Node = Node() // sentinel
    private var tail: Node = Node() // sentinel

    class Node {
        var key: Key?
        var value: Value?
        var prev: Node?
        var next: Node?
        init() {}
        init(key: Key, value: Value) { self.key = key; self.value = value }
    }

    init(capacity: Int) {
        self.capacity = capacity
        head.next = tail
        tail.prev = head
    }

    func get(_ key: Key) -> Value? {
        guard let node = map[key] else { return nil }
        moveToHead(node)
        return node.value
    }

    func put(_ key: Key, _ value: Value) {
        if let node = map[key] {
            node.value = value
            moveToHead(node)
        } else {
            let node = Node(key: key, value: value)
            map[key] = node
            addToHead(node)
            if map.count > capacity {
                if let removed = removeTail() {
                    map.removeValue(forKey: removed.key!)
                }
            }
        }
    }

    private func addToHead(_ node: Node) {
        node.prev = head; node.next = head.next
        head.next?.prev = node; head.next = node
    }
    private func removeNode(_ node: Node) {
        node.prev?.next = node.next; node.next?.prev = node.prev
    }
    private func moveToHead(_ node: Node) { removeNode(node); addToHead(node) }
    private func removeTail() -> Node? {
        guard let node = tail.prev, node !== head else { return nil }
        removeNode(node); return node
    }
}

Core requirements: items are retained for 30 days, recoverable within that window, then permanently deleted. Storage optimization is the real challenge: you don't want to duplicate full-resolution images. Use a soft-delete pattern where deletion sets a deleted_at timestamp and a recoverable flag; the actual binary is retained until the 30-day window passes. iCloud sync must propagate the soft-delete state, not just local state.

Privacy: auto-purge must also trigger when the device is under severe storage pressure (low-storage scenario), which means the purge policy has two triggers (time and storage threshold), not one. Reported as an Apple ICT2 system design question (onsites.fyi, 2024). Junior candidates often miss the iCloud sync conflict case: what if the user recovers a photo on one device and the 30-day window expires on another?

Swift uses Automatic Reference Counting (ARC) at compile time, not runtime. The compiler inserts retain and release calls at the appropriate points during compilation, so there is no garbage collection pause. Value types (struct, enum, tuple) are copied on assignment and do not participate in reference counting at all. Reference types (class) are reference-counted. The key difference from manual Objective-C retain-release: the compiler enforces the ownership rules, so you cannot forget to release an object. The programmer's remaining responsibility is preventing retain cycles (handled with weak/unowned references).

Interviewers follow up with: when does a struct copy not actually copy? The answer: copy-on-write semantics. Swift standard library types like Array and Dictionary use COW, so assignment shares the underlying storage until a mutation occurs, at which point the copy happens. Reported as a standard iOS domain question (MentorCruise, 2026; TechPrep, 2026).

Token bucket algorithm: each client gets a bucket that refills at a fixed rate (tokens per second). Requests consume tokens; requests with no tokens are rejected or queued. For distributed enforcement, the bucket state lives in Redis with atomic operations (INCR, EXPIRE). A sliding window log is more accurate but more expensive; a fixed window counter is cheapest but allows burst at window boundaries.

Apple's privacy stance affects this design: you cannot log full request content for abuse analysis. Rate limiting must be based on device token or account ID, not on payload inspection. Reported as an Apple ICT3 coding round question framed around Apple's Weather API (onsites.fyi, 2025). Follow-up: how do you handle a distributed system where the Redis node is temporarily unavailable?

import time
import redis

class TokenBucketRateLimiter:
    def __init__(self, redis_client: redis.Redis, rate: float, capacity: int):
        self.redis = redis_client
        self.rate = rate          # tokens per second
        self.capacity = capacity  # max burst size

    def allow_request(self, client_id: str) -> bool:
        key_tokens = f"rl:tokens:{client_id}"
        key_ts = f"rl:ts:{client_id}"
        now = time.time()

        pipe = self.redis.pipeline(True)
        try:
            pipe.watch(key_tokens, key_ts)
            tokens = float(pipe.get(key_tokens) or self.capacity)
            last_ts = float(pipe.get(key_ts) or now)

            # Refill tokens based on elapsed time
            elapsed = now - last_ts
            tokens = min(self.capacity, tokens + elapsed * self.rate)

            if tokens >= 1:
                pipe.multi()
                pipe.set(key_tokens, tokens - 1)
                pipe.set(key_ts, now)
                pipe.execute()
                return True
            return False
        except redis.WatchError:
            return False  # retry in caller