Why is there a frame rectangle and a bounds rectangle in a UIView?

Question

Well although it's late in the dark night, I don't get why there are two different rectangles: frame and bounds.

Like I understand it, one single rectangle would have been just enough to do everything. Positioning the View itself relative to another coordinate system, and then clipping its contents to a specified size. What else would you do with two rectangles? And how do they interact with each other?

Does anyone have a good explanation? The one from the Apple docs with the kid holding the fruit is not very good for understanding.

Sortie

Answer 1

Here's the cheatsheet:

• frame is where the view is (with respect to the superview)
• bounds is where the view is allowed to draw (with respect to itself)

Some more clarification:

If you are positioning the view in its superview, you almost always change the frame origin.

If you are clipping where the UIView is drawing, you almost always modify its bounds.

Note that you are allowed to have bounds that is bigger than the frame. That is, you can draw "outside the lines" of where you are.

Saturable

so the frame is something like a starting coordinate relative to the superview coordinate system, and from that starting point the bounds clipping will be done in coordinates relative to the view coordinate system? – Sortie

I noticed that bounds always have 0,0 starting point. So bounds always start at 0. Am I correct? – Calomel

Typically bounds' origin is 0,0. It's not required to be so though. – Saturable

"bounds is where the view is allowed to draw (with respect to itself)", that is true only if clipsToBounds is NO. – Royo

Can you really have one bigger than the other? The docs say The size of the bounds rectangle is coupled to the size of the frame rectangle, so that changes to one affect the other. developer.apple.com/library/ios/documentation/uikit/reference/… – Unaccomplished

Bounds does not always have (0,0) origin. The best example is probably a scroll view: if you imagine a scroll view that can scroll vertically, then bouds.origin equals (0,0) only when it is scrolled to the very top – Abcoulomb

Answer 2

Frame is in the superview's coordinate system, bounds is in the view's coordinate system. From my perspective, it is a convenience to have both. Frame seems to be the more useful of the two, unless there is some case I am unaware of where a subview can have a completely different coordinate system (e.g. pixels scaled differently) than the superview.

Amortization

There is. If you change the subview's transform property, for example by setting its rotation, its bounds will be unchanged, but its coordinate system will be different than that of the superview. – Languid

Answer 3

I've been having troubles with bounds lately and have done some experimentation. The bounds property does limit where a UIView can draw, but does not limit its subviews. The other thing bounds controls is touch event dispatching. A view will not, as far a I can tell, receive touch events that are outside its bounds. Furthermore, any subview that outside of the parent view's bounds will also not receive touch events. In these situations, you have to pretty meticulously update the bounds of the container view as the size and position of its subviews change. Everything will always draw fine (because subviews aren't clipped by the bounds of their parent) but touches won't be received.

(This really should be a reply to an earlier post, but since I can't reply yet, it's stuck here...)

Sanson

UIViews have a clipsToBounds property that will prevent its subview from coloring outside the lines. – Saturable

If you override pointInside:withEvent you can intercept touch events from outside your views frame. Great for making buttons larger than they appear. – Co

if you have a transform applied is the touch event translated back to the bounds coordinate system? – Brigitta