Greetings, traveler!
On iOS interviews, candidates are often asked to reimplement familiar higher-order functions from scratch. These tasks look simple on the surface, yet they quickly reveal how well you understand generics, value semantics, and iteration over collections.
I keep seeing variations of this question across different companies, and the exact function rarely matters as much as the reasoning behind it. In this article, I continue the interview preparation series and walk through several common examples you may be asked to implement, along with the details that usually come up during follow-up questions.
removeDuplicates
removeDuplicates is a very common interview task because it opens the door to complexity analysis, trade-offs between time and memory, and subtle questions about ordering. The first implementation most candidates reach for uses a Set to track elements that have already been seen. This gives linear time on average, because membership checks and insertions into a hash-based set are usually O(1).
extension Array where Element: Hashable {
func removingDuplicates() -> [Element] {
var seen = Set<Element>()
var result: [Element] = []
result.reserveCapacity(count)
for element in self {
if seen.insert(element).inserted {
result.append(element)
}
}
return result
}
}This version also preserves the original order of the first occurrence of each element, which is often an explicit interview requirement. The Set itself does not preserve order, though the result array does. That distinction matters. You use the set only for fast lookup, while the output array records elements in the order they were first encountered.
A useful follow-up is to write the same function without Set. In that case, the simplest approach is to keep the result array and check whether each new element is already present.
extension Array where Element: Equatable {
func removingDuplicatesWithoutSet() -> [Element] {
var result: [Element] = []
result.reserveCapacity(count)
for element in self {
if !result.contains(element) {
result.append(element)
}
}
return result
}
}This version also preserves order, though it does so at a higher cost. Every contains call may scan the current result array, so the overall complexity becomes O(n²) in the worst case. That trade-off is exactly what interviewers often want you to articulate. The Set-based solution is faster, though it requires Hashable and extra memory for the hash table. The version without Set works with Equatable only and may be acceptable for small inputs or when hashing is unavailable.
There is also another variant worth mentioning when order does not matter. You can convert the array to a Set directly and then back to an array.
extension Array where Element: Hashable {
func removingDuplicatesUnordered() -> [Element] {
Array(Set(self))
}
}This is concise, though it drops ordering guarantees because sets are inherently unordered. That makes it unsuitable for many real tasks, especially when the original sequence carries semantic meaning.
If you need the best average performance and Element conforms to Hashable, use a Set for lookup and a result array for stable ordering. If you only have Equatable, use the array-based check and call out the quadratic complexity. If order is irrelevant, converting through Set is the shortest option, though it changes the behavior in a way that should be stated clearly.
map
A good place to start is map, because it is familiar enough to discuss quickly and rich enough to expose whether you understand what happens under the hood. For Array, the custom implementation is straightforward: allocate a result buffer, reserve enough capacity for all elements up front, then append transformed values one by one. Reserving capacity matters because the output array will contain exactly the same number of elements as the input.
Without reserveCapacity(_:), the array may grow in several steps and reallocate its storage along the way. That extra copying does not change correctness, though it does add avoidable overhead, and interviewers often expect you to notice that detail when the final size is known in advance.
extension Array {
func customMap<T>(_ transform: (Element) throws -> T) rethrows -> [T] {
var result: [T] = []
result.reserveCapacity(count)
for element in self {
try result.append(transform(element))
}
return result
}
}The same idea can be generalized to Sequence, which is often a stronger answer in an interview because it shows you are thinking beyond one concrete collection type.
The implementation still iterates once and appends transformed values into a new array. The difference is that a generic Sequence does not always know its exact size in advance, so there is no universal count to rely on. Still, when the sequence provides an underestimate through underestimatedCount, you can use it as a hint and reserve at least that much space. This keeps the implementation broadly applicable while still taking advantage of cheap optimization when the underlying sequence can provide it.
extension Sequence {
func customMap<T>(_ transform: (Element) throws -> T) rethrows -> [T] {
var result: [T] = []
result.reserveCapacity(underestimatedCount)
for element in self {
try result.append(transform(element))
}
return result
}
}In some interview discussions, map becomes a starting point for a deeper question: what if the transformation itself is expensive? That is where parallel processing enters the picture. When each element can be transformed independently, you may want to spread the work across multiple threads or tasks.
A common example is CPU-heavy image processing, JSON decoding for many independent payloads, or preparing view models from large datasets before they reach the UI layer. With GCD, one practical approach is to preserve ordering by preallocating a buffer of optionals and synchronizing writes by index. Each job runs concurrently, computes its transformed value, and stores it in the corresponding slot.
extension Array {
func concurrentMap<T>(_ transform: @escaping (Element) -> T) -> [T] {
let lock = NSLock()
var storage = Array<T?>(repeating: nil, count: count)
DispatchQueue.concurrentPerform(iterations: count) { index in
let value = transform(self[index])
lock.lock()
storage[index] = value
lock.unlock()
}
return storage.map { $0! }
}
}The lock is required here because Array is not thread-safe for concurrent mutation.
With Swift Concurrency, the same idea becomes easier to express. A task group lets you launch child tasks for each element, collect their results, and then rebuild the final array in the original order.
extension Array {
func concurrentMap<T: Sendable>(
_ transform: @Sendable @escaping (Element) async -> T
) async -> [T] where Element: Sendable {
await withTaskGroup(of: (Int, T).self) { group in
for (index, element) in enumerated() {
group.addTask {
let value = await transform(element)
return (index, value)
}
}
var storage = Array<T?>(repeating: nil, count: count)
for await (index, value) in group {
storage[index] = value
}
return storage.map { $0! }
}
}
}This kind of parallel map is useful when the cost of each transformation dominates the overhead of coordination. That condition matters. For lightweight work such as simple arithmetic or string formatting, a plain sequential loop is usually the better choice because it is easier to read and often faster in practice.
Parallelization starts to pay off when each unit of work is substantial, independent, and safe to run concurrently. That distinction often leads to a strong interview answer, because it shows that you are thinking about trade-offs rather than treating concurrency as an automatic optimization.
compactMap
Another function that almost always follows map in interviews is compactMap. It adds a small twist: the transform returns an optional, and only non-nil results make it into the final array. The implementation looks very similar, though there is an important difference compared to map. You do not know the exact number of resulting elements, though the upper bound is still the size of the original collection. Reserving full capacity is safe and avoids reallocations, but may over-allocate memory when many elements are filtered out. In practice, you can reserve count, use underestimatedCount as a lighter hint, or skip reservation entirely depending on the expected data distribution.
extension Array {
func customCompactMap<T>(
_ transform: (Element) throws -> T?
) rethrows -> [T] {
var result: [T] = []
result.reserveCapacity(count)
for element in self {
if let value = try transform(element) {
result.append(value)
}
}
return result
}
}flatten
flatMap often appears in interviews in a slightly different form: instead of asking for a generic transformation, the interviewer narrows the problem down to flattening a nested array.
This is where recursion naturally comes into play. The input is a structure where elements can either be values or other arrays of the same kind, and the goal is to produce a single flat sequence. The simplest way to approach it is to process each element, append it if it is a value, and recursively unwrap it if it is another collection.
func flatten(_ array: [Any]) -> [Int] {
var result: [Int] = []
for element in array {
if let value = element as? Int {
result.append(value)
} else if let nested = element as? [Any] {
result.append(contentsOf: flatten(nested))
}
}
return result
}This solution works because each recursive call handles a smaller portion of the same problem. When the function encounters a nested array, it delegates the work to another invocation of itself, which continues until it reaches only plain values. At that point, the recursion starts unwinding, and all intermediate results are combined into a single array.
There are a couple of details that interviewers often explore further. The first one is type safety. Using [Any] keeps the example simple, though it removes compile-time guarantees. A more robust approach would involve defining a recursive enum that models the structure explicitly, which avoids casting and makes the intent clearer.
indirect enum NestedArray<Element> {
case value(Element)
case array([NestedArray<Element>])
}The indirect keyword allows the enum to store itself recursively. Each element is either a single value or another array of the same structure.
With this model, the flatten implementation becomes both safer and easier to reason about:
func flatten<Element>(
_ array: [NestedArray<Element>]
) -> [Element] {
var result: [Element] = []
for element in array {
switch element {
case .value(let value):
result.append(value)
case .array(let nested):
result.append(contentsOf: flatten(nested))
}
}
return result
}This version has a few advantages.
First, there are no runtime casts. The compiler enforces that every case is handled, which eliminates an entire class of errors.
Second, the structure of the data is explicit. When you read the type, you immediately understand that it can contain nested arrays, which makes the code easier to maintain.
Third, it scales naturally. You can extend the enum with additional cases if the model evolves, and the compiler will guide you to update all affected code paths.
If you want to push this further, you can also make the flatten logic a method on the enum itself, which often reads more naturally:
extension NestedArray {
func flatten() -> [Element] {
switch self {
case .value(let value):
return [value]
case .array(let nested):
return nested.flatMap { $0.flatten() }
}
}
}This keeps the recursion localized and aligns well with how similar problems are modeled in real-world code.
Another point is complexity. Each element is visited exactly once, so the time complexity is linear relative to the total number of values across all nesting levels. Memory usage grows with the depth of recursion due to the call stack. For deeply nested inputs, an iterative solution with an explicit stack can be safer, though recursion remains the most straightforward way to express the idea.
You can follow that paragraph with an iterative version that uses an explicit stack. The core idea is to move recursion from the call stack into your own data structure. That makes the control flow slightly more verbose, but it avoids the risk of deep recursive calls on heavily nested input.
func flattenIterative<Element>(
_ array: [NestedArray<Element>]
) -> [Element] {
var result: [Element] = []
var stack: [NestedArray<Element>] = array.reversed()
while let element = stack.popLast() {
switch element {
case .value(let value):
result.append(value)
case .array(let nested):
stack.append(contentsOf: nested.reversed())
}
}
return result
}Iterative version is not inherently faster. It is safer for deeply nested input because it avoids growing the call stack. Recursive version is simpler and preferred unless nesting depth is unbounded.
Finally, this example helps connect back to flatMap in the standard library. In its general form, flatMap transforms each element into a sequence and then flattens the result by one level. The recursive flatten problem can be seen as a repeated application of that idea, where each level of nesting is reduced until a flat structure remains.
reduce
reduce is another staple in interviews because it forces you to think in terms of accumulation rather than iteration. Instead of building a result step by step in an imperative loop, you carry an accumulator through each element and update it using a closure. The implementation itself is simple, though the mental model is what interviewers care about.
extension Array {
func customReduce<Result>(
_ initial: Result,
_ combine: (Result, Element) throws -> Result
) rethrows -> Result {
var result = initial
for element in self {
result = try combine(result, element)
}
return result
}
}At each step, the current accumulated value and the next element are passed into the closure, which returns a new accumulated value. By the end of the iteration, the accumulator contains the final result. This pattern works for a wide range of tasks, from summing numbers to building complex structures.
A common follow-up is to express other higher-order functions in terms of reduce. Rewriting map using reduce demonstrates that you understand how these abstractions relate to each other. The idea is to start with an empty array and append transformed elements as you go.
extension Array {
func mapUsingReduce<T>(
_ transform: (Element) throws -> T
) rethrows -> [T] {
try customReduce(into: []) { result, element in
result.append(try transform(element))
}
}
}If you want to stay closer to the standard reduce signature without inout, you can write it like this:
extension Array {
func mapUsingReduceClassic<T>(
_ transform: (Element) throws -> T
) rethrows -> [T] {
try customReduce([]) { partial, element in
var copy = partial
copy.append(try transform(element))
return copy
}
}
}Each step creates a new array, which may lead to additional copying. In practice, reduce(into:) is preferred because it mutates the accumulator in place and avoids unnecessary allocations. That distinction often becomes a discussion point in interviews, since it touches on value semantics and performance characteristics rather than just syntax.
filter
filter is another function that shows up regularly, often right after map and compactMap. The idea is simple: iterate over elements and keep only those that satisfy a predicate. The implementation follows the same pattern, though the resulting size is unknown, so capacity reservation becomes a trade-off rather than a certainty.
extension Array {
func customFilter(
_ isIncluded: (Element) throws -> Bool
) rethrows -> [Element] {
var result: [Element] = []
result.reserveCapacity(count)
for element in self {
if try isIncluded(element) {
result.append(element)
}
}
return result
}
}Reserving full capacity here can still make sense when you expect a large portion of elements to pass the predicate. In cases where most elements are filtered out, that reservation becomes wasted space, so this is usually framed as a pragmatic optimization rather than a strict requirement.
At this point, interviewers often push the discussion further and ask for a lazy version. The goal is to avoid allocating a new array entirely and instead evaluate elements on demand. One way to express this is by returning a custom sequence that wraps the original one and applies the predicate during iteration.
struct LazyFilterSequence<Base: Sequence>: Sequence {
let base: Base
let isIncluded: (Base.Element) -> Bool
func makeIterator() -> AnyIterator<Base.Element> {
var iterator = base.makeIterator()
return AnyIterator {
while let element = iterator.next() {
if self.isIncluded(element) {
return element
}
}
return nil
}
}
}Usage stays close to the standard library:
let lazyFiltered = LazyFilterSequence(base: array) { $0 > 10 }Nothing is computed until you start iterating. This approach avoids intermediate storage and becomes especially useful when chaining multiple operations, since each element flows through the pipeline only once.
Another variation of the same idea is “no additional memory.” In strict terms, returning a filtered collection always requires allocating storage for the result. The only way to avoid that is to either mutate the original collection in place or switch to a lazy representation. For arrays, an in-place partitioning approach can be used when mutation is allowed.
extension Array {
mutating func filterInPlace(
_ isIncluded: (Element) -> Bool
) {
var writeIndex = 0
for readIndex in indices {
if isIncluded(self[readIndex]) {
self[writeIndex] = self[readIndex]
writeIndex += 1
}
}
removeLast(count - writeIndex)
}
}This version reuses the existing buffer, overwriting elements that do not satisfy the predicate and then trimming the tail. No extra array is created, and memory usage stays constant.
The basic implementation shows control over iteration and generics. The lazy version demonstrates understanding of evaluation strategies. The in-place variant shows awareness of memory behavior and trade-offs when mutation is acceptable.
forEach
forEach looks trivial at first glance, which is exactly why it appears in interviews. The implementation is just a thin wrapper over iteration, applying a closure to each element without producing a new collection.
extension Array {
func customForEach(
_ body: (Element) throws -> Void
) rethrows {
for element in self {
try body(element)
}
}
}The interesting part is not the code itself, but how forEach behaves compared to a regular for-in loop. A common follow-up question is why you cannot use break or continue inside forEach. The reason lies in control flow. The break keyword works only with language-level loop constructs, where the compiler understands how to exit the loop early. In forEach, the loop is hidden inside the function implementation, and you only provide a closure. From the compiler’s perspective, that closure is just a function body, not a loop context, so break has no meaning there.
forEach is suitable when you want to apply an action to every element and do not need early exit or complex control flow. As soon as you need to stop iteration based on a condition, a for-in loop becomes the better choice. This distinction is small but important, and it often signals whether a candidate understands the difference between language constructs and higher-order abstractions.
first(where:)
first(where:) is a small function, though it often turns into a discussion about early exit and how to model search operations efficiently. The implementation highlights a key idea: stop as soon as you find a match.
extension Array {
func customFirst(
where predicate: (Element) throws -> Bool
) rethrows -> Element? {
for element in self {
if try predicate(element) {
return element
}
}
return nil
}
}The important detail here is that the loop does not traverse the entire collection if it does not have to. As soon as a matching element appears, the function returns immediately. This gives it a best-case complexity of O(1) and a worst-case of O(n), which is often something interviewers expect you to call out.
contains(where:)
contains(where:) builds directly on the same idea as first(where:), though it simplifies the result to a boolean. Instead of returning the element, it answers a yes-or-no question: does any element satisfy the predicate. The implementation follows the same early-exit pattern.
extension Array {
func customContains(
where predicate: (Element) throws -> Bool
) rethrows -> Bool {
for element in self {
if try predicate(element) {
return true
}
}
return false
}
}This function is essentially a specialized version of first(where:). You could implement it on top of that:
func customContains(
where predicate: (Element) throws -> Bool
) rethrows -> Bool {
try customFirst(where: predicate) != nil
}That leads to a natural discussion about trade-offs. The direct implementation avoids creating an intermediate optional and communicates intent more clearly. The version built on top of first(where:) is more compositional and reuses existing logic.
Another common angle is complexity. Just like first(where:), this function benefits from early exit. In the best case, it returns after the first element. In the worst case, it scans the entire collection. That behavior is often contrasted with approaches that always traverse all elements, such as naive uses of map or filter.
allSatisfy
allSatisfy usually comes next, especially after contains(where:), because the two functions form a natural pair. While contains(where:) answers whether at least one element matches a condition, allSatisfy checks that every element does. The implementation again relies on early exit, though in the opposite direction.
extension Array {
func customAllSatisfy(
_ predicate: (Element) throws -> Bool
) rethrows -> Bool {
for element in self {
if try !predicate(element) {
return false
}
}
return true
}
}The key idea is to fail fast. As soon as you encounter an element that does not satisfy the predicate, the function returns false. If the loop completes, the result is true. This gives the same complexity profile as the previous functions: best case O(1), worst case O(n).
This function often leads to a short but useful discussion about its relationship with contains(where:). One can be expressed through the other by inverting the predicate:
!array.customContains { !predicate($0) }That equivalence shows how these abstractions connect, though the direct implementation remains clearer and avoids the mental overhead of double negation.
Another detail that sometimes comes up is the behavior on empty collections. allSatisfy returns true when the collection is empty, which may feel counterintuitive at first. This follows standard logic: there are no elements that violate the condition.
chunked(into:)
The task is to split a collection into smaller arrays of a given size while preserving order. The key detail is handling the last chunk, which may be smaller than the requested size.
A straightforward implementation uses stride to step through the array by fixed offsets and then slices the underlying storage.
extension Array {
func chunked(into size: Int) -> [[Element]] {
precondition(size > 0)
var result: [[Element]] = []
result.reserveCapacity((count + size - 1) / size)
for start in stride(from: 0, to: count, by: size) {
let end = Swift.min(start + size, count)
result.append(Array(self[start..<end]))
}
return result
}
}There are a few points interviewers usually focus on here. The first is correctness around boundaries. The last chunk should include all remaining elements without going out of bounds, which is why min(start + size, count) is required.
The second is capacity planning. Since you can compute the number of chunks in advance, reserving capacity avoids repeated reallocations. The formula (count + size - 1) / size rounds up and gives the exact number of chunks.
Another angle is whether this can be done lazily. A lazy version would avoid creating all chunks upfront and instead produce them on demand. This becomes useful when working with large datasets or streaming data, where you do not want to allocate the entire result in memory at once.
Finally, this function often leads to a discussion about slicing versus copying. Array(self[start..<end]) creates a new array for each chunk. If you want to avoid copying, you could return ArraySlice instead, which references the original storage. That trade-off depends on how the result will be used, and being able to explain it usually strengthens the answer in an interview context.
groupBy
groupBy is a common step up in difficulty because it combines iteration, generics, and dictionary manipulation. The task is to partition elements into buckets based on a key derived from each element. The result is a dictionary where each key maps to an array of elements that share that key.
extension Array {
func groupBy<Key: Hashable>(
_ keySelector: (Element) throws -> Key
) rethrows -> [Key: [Element]] {
var result: [Key: [Element]] = [:]
result.reserveCapacity(count)
for element in self {
let key = try keySelector(element)
result[key, default: []].append(element)
}
return result
}
}The implementation relies on a useful dictionary feature: result[key, default: []]. It either returns the existing array for the key or creates a new one if the key has not been seen before. This keeps the code compact while avoiding extra checks.
The function runs in O(n) time on average, assuming constant-time hashing. Each element is processed once, and dictionary insertions are efficient under normal conditions.
The arrays stored as dictionary values preserve the original order of elements within each group. The dictionary itself does not guarantee any ordering of keys, which is an important distinction to call out.
Grouping does not reorder elements globally, it only partitions them. Sorting, on the other hand, establishes a total order. These are different operations, and choosing between them depends on the problem.
This function often appears in real code when building view models, organizing data for sections in a table or collection view, or aggregating domain objects by some property.
zip
The idea is to iterate over two sequences in parallel and combine their elements into pairs. Iteration stops as soon as one of the sequences runs out of elements, which is an important detail to call out.
A simple implementation for arrays can be written using indices.
func customZip<A, B>(_ a: [A], _ b: [B]) -> [(A, B)] {
let count = Swift.min(a.count, b.count)
var result: [(A, B)] = []
result.reserveCapacity(count)
for i in 0..<count {
result.append((a[i], b[i]))
}
return result
}Here, the result size is known in advance, so reserving capacity avoids unnecessary reallocations. The loop runs only up to the length of the shorter array, which guarantees safe indexing.
This often leads to a more general version for Sequence, which avoids relying on indices and instead works with iterators.
struct ZipSequence<S1: Sequence, S2: Sequence>: Sequence {
let s1: S1
let s2: S2
func makeIterator() -> AnyIterator<(S1.Element, S2.Element)> {
var it1 = s1.makeIterator()
var it2 = s2.makeIterator()
return AnyIterator {
guard let e1 = it1.next(),
let e2 = it2.next() else {
return nil
}
return (e1, e2)
}
}
}This version highlights how Sequence works under the hood. Each iterator advances independently, and the combined sequence stops when either one returns nil. There is no need to know the size of the inputs in advance.
What happens when the sequences have different lengths? The answer is that the extra elements in the longer sequence are ignored.
Does the result preserve order? It does, since elements are paired in the order they are produced by each sequence.
zip is useful when combining related datasets, such as pairing IDs with values, merging two streams of data, or iterating over indices and elements together without explicitly calling enumerated. In practice, it often appears in transformations where two collections represent parallel pieces of information.
partition
partition is another variation on splitting data, though in this case you divide elements into exactly two groups based on a predicate. Conceptually, it is close to filter, but instead of discarding elements that do not match, you keep both sides.
A straightforward implementation returns a tuple of two arrays.
func partition<T>(
_ array: [T],
by predicate: (T) -> Bool
) -> ([T], [T]) {
var matching: [T] = []
var nonMatching: [T] = []
matching.reserveCapacity(array.count)
nonMatching.reserveCapacity(array.count)
for element in array {
if predicate(element) {
matching.append(element)
} else {
nonMatching.append(element)
}
}
return (matching, nonMatching)
}
This version is easy to reason about and preserves the original order of elements within each group. The capacity reservation is conservative, since each array may end up smaller, though it avoids repeated reallocations when the distribution is uneven.
This function often leads to a comparison with filter. You could implement partition by calling filter twice, once for each condition. That would traverse the array twice, while the single-pass version above does it in one iteration.
Another direction is in-place partitioning. If mutation is allowed, you can rearrange elements inside the same array and avoid allocating additional memory. The idea is to move matching elements toward the front and keep track of a boundary index.
extension Array {
mutating func partitionInPlace(
by predicate: (Element) -> Bool
) -> Int {
var boundary = startIndex
for i in indices {
if predicate(self[i]) {
swapAt(i, boundary)
formIndex(after: &boundary)
}
}
return boundary
}
}After this operation, all elements before the returned index satisfy the predicate, and the rest do not. Order is not preserved in this variant, which is another trade-off to mention.
Conclusion
These exercises may look routine, though they consistently reveal how comfortable you are with the foundations of Swift. Writing a custom map or reduce is rarely about memorizing syntax. The conversation quickly shifts toward generics, value semantics, memory behavior, and the cost of seemingly small decisions like reserving capacity or avoiding intermediate allocations. That is exactly why these questions keep appearing in interviews.
What I find useful when preparing is to treat these functions as a small toolkit rather than isolated tasks. Once you understand how they relate to each other, you start seeing patterns. map, filter, and compactMap differ mostly in what they do with elements. reduce generalizes all of them. Functions like groupBy, chunked, or partition are variations built on the same iteration model. At that point, writing them from scratch becomes mechanical, and the focus moves to trade-offs and clarity.