When should you use frame-based layout versus Auto Layout?
When manual frames beat constraints.
Frames suit static or high-frequency UI like particle systems; Auto Layout handles rotation, Dynamic Type, localization, and split screen.
Claiming Auto Layout always wins.
What's really being asked
This question probes whether you understand that UIKit offers two distinct layout paradigms and that senior engineers pick the right tool for the job rather than defaulting to the modern option. Interviewers want to hear that you grasp the performance characteristics of manual layout and the adaptive power of constraints.
The full answer
First, a crisp definition of frame-based layout as manually setting the origin and size of a view, typically in layoutSubviews or during animation blocks. Second, a clear explanation of Auto Layout as a constraint satisfaction system that calculates frames at runtime based on relationships between views, the superview, and intrinsic content size. Third, the specific domains where each wins: frames are ideal for static views, high-frequency updates like particle emitters or custom drawing, and performance-critical code where constraint solving overhead is unacceptable; Auto Layout is the right choice for adaptive interfaces that must respond to external changes like device rotation, split-screen multitasking, size classes, and internal changes like Dynamic Type, localization text expansion, or varying image aspect ratios. Fourth, the practical reality that most modern apps use Auto Layout for screens and frames for isolated high-performance subviews.
The mistakes people make
Claiming that frame-based layout is deprecated or forbidden by Apple. Asserting that Auto Layout is always preferred because it is newer. Describing Auto Layout purely as a visual design tool rather than a runtime engine. Failing to mention intrinsic content size or content hugging and compression resistance. Saying you would use Auto Layout inside a tight animation loop without mentioning that updating constraints there causes expensive recalculations.
What usually comes next
How would you animate a view laid out with Auto Layout? The expected path is to animate the constant of a constraint and call layoutIfNeeded inside an animation block. When would you mix the two approaches? A strong answer mentions using Auto Layout for the overall scene but frames for a custom rendering layer or a collection view cell that needs to hit 60 frames per second. How does Auto Layout interact with transforms? You should note that transforms operate on the rendered layer and do not affect the calculated frame, which can lead to clipping or misalignment if the constraint system is unaware of the visual change.
A concrete example
Imagine a photo editing app with a scrolling filmstrip of thumbnails and a main canvas showing the selected image. The filmstrip and surrounding chrome should use Auto Layout so the interface adapts cleanly to iPad split screen, iPhone rotation, and localized button labels. The main canvas, however, might host a custom UIView subclass that draws a complex image with overlaid brush strokes at specific pixel coordinates. That canvas view uses frame-based layout because its content is not constraint-friendly, its geometry is fixed relative to its parent, and it may need to update at 60 or 120 frames per second during pinch-to-zoom without triggering a constraint solve.
Interview question
Which situation most justifies using frame-based layout instead of Auto Layout?
- a.A settings screen that must adapt to iPad split-screen multitasking and device rotation
- b.A button whose intrinsic content size determines its width based on localized text
- c.A custom view that redraws particle effects at 60 frames per secondCorrect
- d.A table view cell whose layout responds to Dynamic Type changes
Why? this is the answer
Frame-based layout avoids the runtime overhead of constraint solving, making it ideal for high-frequency updates like particle systems at 60 fps. Auto Layout is the right choice for adaptive scenarios such as split-screen multitasking, localized text expansion, and Dynamic Type.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
- #ios
- #uikit
- #auto-layout
- #frame-layout
- #interview
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ios — each one lists the topics its interview covers.
See open roles