Diagnosing choppy scrolling performance

WHAT THIS TESTS The question separates engineers who guess from those who measure. Smooth scrolling means rendering each frame inside the refresh budget, roughly 16.6 milliseconds at 60Hz, and the interviewer wants to see a disciplined diagnostic approach.

A GOOD ANSWER COVERS The first tool is Instruments. The Time Profiler shows where main-thread time goes by sampling the call stack, letting you spot expensive synchronous work running during the scroll gesture. The Animation Hitches or Core Animation instrument counts dropped frames and hitches directly. You are looking for main-thread work that blows the frame budget: synchronous image decoding and resizing, repeated Auto Layout passes, offscreen rendering from shadows or masks, blending, and cell construction done lazily during scroll instead of ahead of time.

COMMON WRONG ANSWERS Immediately blaming the table or collection view and rewriting cell code without profiling. Saying you would add print timing everywhere, which perturbs the very timing you measure. Confusing CPU usage with frame drops; an app can be busy yet still hit every frame, or idle yet hitch from a single blocking call.

LIKELY FOLLOW-UPS How do you fix image decoding hitches? What is offscreen rendering and how do you detect it? How does prefetching help? What does the green and red overlay in the Core Animation instrument indicate?

ONE CONCRETE EXAMPLE A feed stutters on a midrange phone. The Time Profiler shows forty percent of scroll time inside UIImage decode calls on the main thread. You move decoding to a background queue, downsample with ImageIO to the display size, and cache the result. The next trace shows hitches drop to near zero because the main thread now only assigns ready bitmaps.