frame and bounds use different coordinate systems
They describe the same view from two different coordinate systems. frame locates and sizes the view in its superview; bounds describes its own local coordinate space.
“The frame rectangle, which describes the view’s location and size in its superview’s coordinate system.”
“The bounds rectangle, which describes the view’s location and size in its own coordinate system.”
When do their sizes differ?
Without a transform, their sizes are usually the same. Apple documents that the default bounds size matches the size of frame.
“The default bounds origin is (0,0) and the size is the same as the size of the rectangle in the frame property.”
A transform can scale or rotate a view. Apple also warns that after a non-identity transform, you must not treat frame as a reliable measurement. So a diagram can show the visual effect, but do not promise that UIKit’s frame getter will return a larger or smaller transformed size.
“Use this property to scale or rotate the view’s frame rectangle within its superview’s coordinate system.”
“When the value of this property is anything other than the identity transform, the value in the frame property is undefined and should be ignored.”
For a transformed view, reason about its bounds, center, and transform instead of relying on frame.
What scrolling changes
A scroll view demonstrates how bounds.origin can move while the scroll view keeps its size. Apple describes a scroll view as:
“A scroll view is a view with an origin that’s adjustable over the content view.”
As you scroll vertically, bounds.origin.y changes. contentOffset.y describes the content origin’s offset relative to the scroll view’s origin:
“The point at which the origin of the content view is offset from the origin of the scroll view.”
In a typical unzoomed scroll view, both values track the same vertical scroll position:
scrollView.bounds.origin.y
scrollView.contentOffset.yThey are related measurements, not two names for the same property. contentSize is separate: it describes the size of the scrollable content.
Myth: A bigger image makes UIImageView.bounds bigger
A high-resolution image does not automatically enlarge a fixed-size UIImageView. UIImage.size is its logical size in points:
“The logical dimensions, in points, for the image.”
Pixel dimensions depend on the image’s scale:
“Multiply the size values by the value in the scale property to get the pixel dimensions of the image.”
The image view controls how that image appears inside its own bounds:
“An image view uses its contentMode property and the configuration of the image itself to determine how to display the image.”
The UIImageView changes size only when its own layout or sizing changes; a larger image by itself does not enlarge the view’s bounds.
“If the size of the image view itself changes, it automatically scales the image as needed.”
That is the myth to remember: making the image larger or centering it does not resize the UIImageView’s bounds. If no transform is applied, Apple says the default bounds size matches the frame size.
Remember: frame is in the superview’s coordinate system; bounds is local to the view. Scrolling changes the scroll view’s bounds origin, while image resolution alone does not resize a fixed-size image view.