What an autoreleasepool is and when to add one manually

WHAT THIS TESTS The question checks whether you understand the autorelease mechanism inherited from Objective-C and when ARC alone is not enough to control peak memory.

A GOOD ANSWER COVERS An autorelease pool is a stack of objects that have been sent an autorelease message, meaning their release is deferred until the pool itself is drained. On the main thread Cocoa drains a pool at the end of every run loop pass, so transient objects normally disappear promptly between events. ARC still inserts releases for Swift-managed objects, but Objective-C APIs and bridged Foundation types may return autoreleased objects that only die when a pool drains.

WHEN YOU ADD ONE MANUALLY Inside a long, tight, synchronous loop that has no run loop turn, such as processing thousands of files or images. Each iteration may create temporary autoreleased objects, often from Foundation or other Objective-C frameworks, and they pile up until the loop returns. Wrapping the body in autoreleasepool { } drains per iteration and keeps the high-water mark flat instead of growing without bound.

COMMON WRONG ANSWERS Confusing autorelease pools with retain-cycle resolution, which is unrelated. Believing pure Swift value code benefits, when the issue is specifically deferred-release Objective-C objects. Thinking the pool frees memory immediately rather than at drain time.

LIKELY FOLLOW-UPS Where does the main run loop drain its pool? What happens on a background thread you create yourself? How does this differ from a memory leak versus a temporary spike? Why does Image or Data processing in a loop commonly trigger this?

ONE CONCRETE EXAMPLE A batch importer loads ten thousand images, resizes each, and writes a thumbnail, all in one for loop. Memory climbs steadily and the app is jetsammed. Wrapping the loop body in autoreleasepool { } lets each iteration's temporary UIImage and Data objects drain immediately, holding memory roughly constant across the whole batch.