Autoresizing masks programmatically vs Interface Builder / xib / nib

I was in an (probably false) assumption that enabling the right margin indicator in xib is equivalent to using UIViewAutoresizingFlexibleLeftMargin inside code and so on.

So, I used to think according to this snapshot:

Later today I had to cross check, and stumbled upon this thread.

And also the apple documentation, entitled with the section with title - "Handling Layout Changes Automatically Using Autoresizing Rules" in this link: https://developer.apple.com/library/content/documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/CreatingViews/CreatingViews.html

So I now have a renewed concept in my mind as to how setting autoresizing masks programmatically would be equivalent to xib settings:

Scenario 1: Setting only (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight) is equivalent to:

In XIB?

Scenario 2: Setting (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin | UIViewAutoresizingFlexibleBottomMargin) in code is equivalent to:

In XIB?

Are my 2 renewed scenarios correct? Am I right now in my understanding?

Yes, you have cited things correctly. Also, I agree that it feels a bit backwards, so for that reason I appreciate your post.

You might like using a preprocessor Macro UIViewAutoresizingFlexibleMargins when making a UIView's margin flexible in every direction. I put this in the precompiled header file so it gets included everywhere.

#define UIViewAutoresizingFlexibleMargins                 \
              UIViewAutoresizingFlexibleBottomMargin    | \
              UIViewAutoresizingFlexibleLeftMargin      | \
              UIViewAutoresizingFlexibleRightMargin     | \
              UIViewAutoresizingFlexibleTopMargin

Using UIViewAutoresizingFlexibleMargins will make a UI Element stay centered since it will NOT be hugging any one side. To make the element grow / shrink with its parent, set the UIViewAutoresizingFlexibleWidth and UIViewAutoresizingFlexibleHeight respectively.

I like using UIViewAutoresizingFlexibleMargins because I can later reference it like:

myView.autoresizingMask = UIViewAutoresizingFlexibleMargins;

instead of

myView.autoresizingMask = UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin;

All to often I see these margins OR'ed together on one line like the example above. Just hard to read.

Yes, Interface Builder has it "reversed" in a sense (or UIView, depending on how you look at it). Your cited "scenarios" are correct.

Enabling the vertical/horizontal arrow (called spring) inside the box will make the height/width flexible. But enabling an outside line (called strut) will make that side inflexible/ non-flexible.

Enabling the outer left line (left strut) is not equivalent to enabling UIViewAutoresizingFlexibleRightMargin. Instead, UIViewAutoresizingFlexibleRightMargin = on if right strut disabled, off if right strut enabled.

It is quite confusing at first, but if you see closely, there is a difference in the springs and struts. I don't know why Apple did this, but for me, there were some cases where it was easier to use. And using opposite properties in code is even more confusing.

Swift 4 use this

gadBannerView?.autoresizingMask = [.flexibleRightMargin  , .flexibleLeftMargin , .flexibleTopMargin , .flexibleBottomMargin]

Objective-C

myView.autoresizingMask = UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin;