Apple iOS Engineer Interview: 4-Round Complete Record with Swift and Low-Level Principles Deep Dive

Background

Let me start with my situation: 3 years of iOS development experience, previously working at an ed-tech company on the iOS side, mainly responsible for two core modules — live course streaming and assignment grading. Honestly, after three years there, I hit a technical plateau. The business was stable with no new challenges, so I started looking for opportunities elsewhere. Apple had always been a company I wanted to join — after all, the intersection of their ecosystem and iOS development offers incredible depth, and their engineering culture is something I deeply respect. I applied directly through Apple's careers page, waited about two weeks, and then received a call from HR to schedule the first round.

The entire interview process consisted of 4 rounds: Round 1 on technical fundamentals, Round 2 on advanced principles and performance optimization, Round 3 on architecture design and algorithms, and finally the HR round. From the first interview to receiving the offer took about three weeks overall. The pace was fairly tight. Let me break it down round by round.

Round 1: Swift Fundamentals and Memory Management

Interviewer Style

The Round 1 interviewer was a young-looking guy who turned out to be a technical lead on the iOS team. His style was pragmatic — not much small talk, straight to questions — but he'd give hints when probing deeper, so you wouldn't get completely stuck.

Swift Value Types vs Reference Types

The first question was about the difference between value types and reference types in Swift. I'd prepared for this one, so I answered fluently: value types are stored on the stack with deep copy on assignment; reference types are stored on the heap with shallow copy, where multiple variables point to the same memory. The interviewer then asked something I hadn't anticipated: the difference in method dispatch between struct and class. Struct method dispatch is static, determined at compile time; class method dispatch is dynamic, determined at runtime through vtable. I hadn't thought deeply about this before, but the interviewer gave me a hint and I worked through it.

ARC Principles and Retain Cycles

Next up was how ARC works. I explained the reference counting mechanism — the compiler automatically inserts retain/release/autorelease calls at compile time, and objects are deallocated when the reference count drops to zero. The interviewer then asked when retain cycles occur. I gave the classic example of closures capturing self, and the issue with delegates declared as strong. He followed up: besides closures and delegates, what other scenarios cause retain cycles? I thought for a moment and mentioned Timer's target-action pattern, since Timer holds a strong reference to its target. He nodded at that.

weak vs unowned

This is a must-know topic. weak is optional — it automatically becomes nil when the object is deallocated; unowned is non-optional — accessing it after deallocation causes a crash. I added usage scenarios: weak for cases where lifecycles may differ (like delegates), unowned for cases where lifecycles are guaranteed to be the same (like closures that live and die with self). The interviewer drilled into a detail: the difference between unowned and unowned(safe). I honestly said I wasn't sure. He briefly explained that in Debug mode, unowned(safe) performs checks, while in Release mode it behaves the same as unowned(unsafe).

The Essence of Optional

The last fundamentals question: the underlying implementation of Optional. I answered that Optional is an enum with two cases: some(Wrapped) and none. The interviewer followed up: why did Swift design Optional? I explained from a type safety perspective — null references are the "billion-dollar mistake," and Optional forces developers to handle nil cases, preventing null pointer issues at the language level.

Round 1 Impressions

Round 1 lasted about 50 minutes. Overall I felt pretty good — I answered most fundamentals questions, and while I missed the unowned(safe) detail, the interviewer was encouraging. I received the Round 2 notification that same evening.

Round 2: Runtime, Runloop, and Performance Optimization

Interviewer Style

The Round 2 interviewer was clearly more senior, likely a team lead level. He preferred starting from real scenarios and then drilling into underlying principles step by step. The pressure was noticeably higher than Round 1.

Runtime Message Forwarding Mechanism

He opened with the Runtime message forwarding mechanism. I'd memorized this, but the interviewer wanted me to explain it in the context of real scenarios. I walked through the complete three-step forwarding process: dynamic method resolution (resolveInstanceMethod) → fast forwarding (forwardingTargetForSelector) → full forwarding (forwardInvocation). He followed up: have you used message forwarding in your projects? I described using forwardingTargetForSelector to achieve a multiple-inheritance effect, and using resolveInstanceMethod for dynamically adding methods. He seemed satisfied.

Runloop Mechanism and Applications

Next was how Runloop works. I explained that Runloop is essentially an event loop that continuously receives and processes events (Timer, Source, Observer). The interviewer asked several deeper questions:

1. What is a Runloop Mode? I answered that Mode is the Runloop's operating mode — different Modes only process their corresponding Sources and Timers. For example, when scrolling a ScrollView, it switches to UITrackingRunLoopMode, and Timers under NSDefaultRunLoopMode won't fire.

2. Practical applications of Runloop? I covered three scenarios: keeping a background thread alive (adding a Port so the Runloop doesn't exit), performance optimization (monitoring lag between kCFRunLoopBeforeSources and kCFRunLoopAfterWaiting), and lazy loading (performSelector:withObject:afterDelay depends on Runloop's Timer).

UI Lag Optimization

The interviewer gave a scenario: a page stutters noticeably during scrolling — how do you diagnose and optimize? I answered step by step: first use Instruments' Time Profiler to identify expensive methods, then use CADisplayLink to monitor frame rate, and optimize from several directions — move main thread work to background threads, reduce view hierarchy depth, avoid frequent layout calculations, and pre-decode images asynchronously. He followed up: why does image decoding need to be async? I explained that UIImage only triggers hardware decoding when it's set on a UIImageView, and this process blocks the UI on the main thread, so it needs to be decoded ahead of time on a background thread.

UITableView Performance Optimization

Finally, UITableView optimization strategies. I listed several: cell reuse, height caching, async drawing, reducing subview hierarchy, pre-layout and pre-calculation, and on-demand loading. He asked about how to implement height caching, and I described using a dictionary to cache cellHeight — checking the cache first in heightForRowAtIndexPath, and calculating and caching if not found.

Round 2 Impressions

Round 2 lasted about 1 hour. The follow-up questions made me nervous, especially around Runloop application scenarios where some details weren't perfect. But the interviewer kept guiding me and didn't let me get completely stuck. Three days later I received the Round 3 notification.

Round 3: Architecture Design and Algorithms

Interviewer Style

The Round 3 interviewer was likely a technical director. His questions were more macro-level, focusing on architectural thinking and systematic reasoning, rather than nitpicking details like the previous rounds.

Project Architecture Design

He first asked me to describe my current project's architecture. I explained that we used MVC but had the Massive ViewController problem, and gradually introduced MVVM. He followed up: what's the core difference between MVVM and MVC? I answered that MVVM extracts business logic from the Controller into the ViewModel, with the Controller only handling view binding and lifecycle management, making the ViewModel more testable. He then asked: what binding approach do you use for MVVM? I described using the Combine framework for reactive binding, and previously using KVO.

Modularization Approach

The interviewer asked about my understanding of iOS modularization. I explained that the core of modularization is decoupling, using an intermediary layer (Router or Protocol) for inter-module communication. I mentioned three approaches: URL Router (Mogujie's approach), Target-Action (CTMediator), and Protocol-Class registration (BeeHive), analyzing the pros and cons of each. He followed up: which approach does your project use and why? I described using CTMediator because it doesn't require a registration table, and runtime decoupling is more thorough — although hardcoded strings are risky, they can be generated through tooling.

CI/CD Process

The interviewer asked about our project's CI/CD setup. I described our automated build pipeline using Jenkins + Fastlane, including code checking (SwiftLint), unit testing, build distribution (fir.im), and automatic TestFlight uploads. He followed up: what does Fastlane's match command do? I answered that it centrally manages certificates and provisioning profiles, avoiding certificate management chaos when multiple people collaborate.

Algorithm Questions

Two algorithm problems:

1. Maximum depth of a binary tree: Recursive solution, max(depth(left), depth(right)) + 1. Finished in a few minutes. The interviewer then asked for an iterative version, which I implemented using BFS level-order traversal.

2. Sort a linked list: Required O(nlogn) time complexity and O(1) space complexity. I used merge sort — first finding the midpoint with fast/slow pointers, then recursively sorting, and finally merging the sorted lists. I had a small bug during implementation — forgetting to handle remaining nodes during the merge — which the interviewer pointed out and I quickly fixed.

Round 3 Impressions

Round 3 lasted about 1 hour 10 minutes. The architecture discussion was quite deep, and the algorithm questions were moderately difficult. Overall, the interviewer valued thought process and reasoning over exact answers. One week later I received the HR round notification.

HR Round: Motivation and Career Planning

The HR round was relatively relaxed, covering several questions:

1. Why Apple? I talked about Apple's deep expertise in mobile, the technical intersection of their ecosystem and iOS development, and how I identify with their engineering culture of substance over style.

2. Career planning? I said in the short term I want to deepen my iOS low-level expertise, and long term I hope to lead a team, growing in both technical and managerial dimensions.

3. Salary expectations? I gave a reasonable range without being unreasonable, and indicated willingness to negotiate.

4. Any other offers? I honestly mentioned I had another one in process, but Apple was my top choice.

Interview Questions Summary

Swift Fundamentals

1. Difference between value types and reference types? Difference in method dispatch between struct and class?

2. How does ARC work? What scenarios cause retain cycles?

3. Difference between weak and unowned? Difference between unowned(safe) and unowned(unsafe)?

4. What is the essence of Optional? Why did Swift design Optional?

Underlying Principles

5. Complete flow of the Runtime message forwarding mechanism?

6. How does Runloop work? What is Mode? Practical application scenarios?

7. How to diagnose and optimize UI lag?

8. UITableView performance optimization strategies? How to implement height caching?

Architecture and Engineering

9. Core difference between MVVM and MVC? What binding approaches exist?

10. What iOS modularization approaches exist? Pros and cons of each?

11. How to set up CI/CD? What does Fastlane match do?

Algorithms

12. Maximum depth of a binary tree (recursive + iterative)

13. Sort a linked list (merge sort, O(nlogn) time, O(1) space)

Key Takeaways and Advice

1. Fundamentals must be solid, but understanding principles matters more. The interview won't just ask "what" — they'll probe "why" and "how." For example, everyone knows Optional is an enum, but why design it that way? There's a philosophy of language design behind it.

2. Performance optimization is a differentiator. In Round 2, if you can walk through the complete chain of monitoring → diagnosis → optimization for lag issues, the interviewer will see you have real-world experience, not just memorized answers.

3. Discuss architecture in the context of your project. Don't just state theory — always tie it to real examples from your project, explaining why you chose a particular approach, what problems you encountered, and how you solved them.

4. Don't neglect algorithms. While algorithms aren't the biggest portion of iOS interviews, Round 3 still tests them, and the bar isn't low. The linked list sort problem required O(1) space, which rules out recursive merge sort — you must use iteration.

5. Interview mindset matters. I was definitely nervous during Round 2's follow-up questions, but I realized the interviewer wasn't trying to stump me — they wanted to see my thought process. When you don't know something, saying "I'm not entirely sure, but my understanding is..." is far better than making things up.

FAQ

Q1: Does the iOS interview value project experience or fundamental principles more?

Both matter, but with different emphasis. Round 1 leans toward fundamentals, Round 2 toward practical experience and performance optimization, Round 3 toward architectural thinking. Project experience is the vehicle; fundamental principles are the engine — you need both.

Q2: Will I be at a disadvantage without big-company experience?

No. I came from a smaller company too. The interviewers focus on your problem-solving ability and technical depth, not your company background. Clearly articulating the highlights of your projects is more convincing than a famous company name.

Q3: How much algorithm preparation is needed?

LeetCode medium difficulty mainly, with focus on linked lists, trees, and dynamic programming. The algorithm questions won't be overly obscure, but you'll need to analyze time and space complexity, and may be asked to optimize.

Q4: How long does the interview process take?

My entire process took about three weeks: Round 1 to Round 2 in 3 days, Round 2 to Round 3 in 3 days, Round 3 to HR round in 1 week, HR round to offer in 3 days. This varies by team, so take it as a reference.

Q5: What's the salary range?

For 3 years of iOS experience, the offer was above average for the industry. I won't share specific numbers. I recommend researching market rates before interviewing and setting a reasonable expectation range.