Objective-C setFrame Swift equivalent

Question

I have an Objective-C project I'm refactoring and I've enountered a line that I can't translate and Apple's documentation site seems to be down:

[self.stepperView setFrame:self.stepperView.frame];

I've tried this:

    self.stepperView.frame = stepperView.frame

but the view is still getting drawn in the wrong spot. Does anyone know the setFrame equivalent in Swift?

I tried looking at Apple's documentation, but it seems the site is down:

Answer 1

setFrame and frame are equivalent in Objective-C and Swift.

In Objective-C, setFrame is the generated setter method for a property. You can also do (in Objective-C) view.frame = someFrame which is 100% the same as calling setFrame: it's just a matter of which syntax you prefer.

In Swift, all the setVariable: method names are replaced with the dot-syntax equivalent of view.frame = ....

As far as why your view is getting drawn in the wrong spot, you'd have to post a concrete example of how you're placing your view. It's most likely a math or calculation error. It's also worth noting that the iOS coordinate layout has y-values increasing as you go down, unlike typical Cartesian coordinates.

I also noticed that in one of the tabs in your screenshot that you searched "unable to set frame before viewDidLoad". viewDidLoad is the wrong place to be setting any frame values. According to the documentation:

This method is called after the view controller has loaded its view hierarchy into memory. This method is called regardless of whether the view hierarchy was loaded from a nib file or created programmatically in the loadView method. You usually override this method to perform additional initialization on views that were loaded from nib files.

which means viewDidLoad is the place for initialization of state, variables, whatever but not the place for layout because it's incredibly likely that somewhere in between viewDidLoad and viewDidAppear that something else, something out of your control is re-positioning your view. The most likely culprit is the view bounds changing and adjusting all subviews.