Since Xcode 8 and iOS10, views are not sized properly on viewDidLayoutSubviews

IosAutolayoutIos10Xcode8

Ios Problem Overview


It seems that with Xcode 8, on viewDidLoad, all viewcontroller subviews have the same size of 1000x1000. Strange thing, but okay, viewDidLoad has never been the better place to correctly size the views.

But viewDidLayoutSubviews is!

And on my current project, I try to print the size of a button:

- (void)viewDidLayoutSubviews {
	[super viewDidLayoutSubviews];
	
	NSLog(@"%@", self.myButton);
}

The log shows a size of (1000x1000) for myButton! Then if I log on a button click, for example, the log shows a normal size.

I'm using autolayout.

Is it a bug?

Ios Solutions


Solution 1 - Ios

Now, Interface Builder lets the user change dynamically the size of every view controllers in storyboard, to simulate the size of a certain device.

Before this functionality, the user should set manually each view controller size. So the view controller was saved with a certain size, which was used in initWithCoder to set the initial frame.

Now, it seems that initWithCoder do not use the size defined in storyboard, and define a 1000x1000 px size for the viewcontroller view & all its subviews.

This is not a problem, because views should always use either of these layout solutions:

  • autolayout, and all the constraints will layout correctly your views

  • autoresizingMask, which will layout each view which doesn't have any constraint attached to (note autolayout and margin constraints are now compatible in the same view \o/ !)

But this is a problem for all layout stuff related to the view layer, like cornerRadius, since neither autolayout nor autoresizing mask applies to layer properties.

To answer this problem, the common way is to use viewDidLayoutSubviews if you are in the controller, or layoutSubview if you are in a view. At this point (don't forget to call their super relative methods), you are pretty sure that all layout stuff has been done!

Pretty sure? Hum... not totally, I've remarked, and that's why I asked this question, in some cases the view still has its 1000x1000 size on this method. I think there is no answer to my own question. To give the maximum information about it:

1- it happends only when laying out cells! In UITableViewCell & UICollectionViewCell subclasses, layoutSubview won't be called after subviews would be correctly layed out.

2- As @EugenDimboiu remarked (please upvote his answer if useful for you), calling [myView layoutIfNeeded] on the not-layed out subview will layout it correctly just in time.

- (void)layoutSubviews {
    [super layoutSubviews];
    NSLog (self.myLabel); // 1000x1000 size	
    [self.myLabel layoutIfNeeded];
    NSLog (self.myLabel); // normal size
}

3- To my opinion, this is definitely a bug. I've submitted it to radar (id 28562874).

PS: I'm not english native, so feel free to edit my post if my grammar should be corrected ;)

PS2: If you have any better solution, feel free not write another answer. I'll move the accepted answer.

Solution 2 - Ios

Are you using rounded corners for your button ? Try calling layoutIfNeeded() before.

Solution 3 - Ios

Solution: Wrap everything inside viewDidLayoutSubviews in DispatchQueue.main.async.

// swift 3

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()

    DispatchQueue.main.async {
        // do stuff here
    }
}

Solution 4 - Ios

I know this wasn't your exact question, but I ran into a similar problem where as on the update some of my views were messed up despite having the correct frame size in viewDidLayoutSubviews. According to iOS 10 Release notes:

> "Sending layoutIfNeeded to a view is not expected to move the view, > but in earlier releases, if the view had > translatesAutoresizingMaskIntoConstraints set to NO, and if it was > being positioned by constraints, layoutIfNeeded would move the view to > match the layout engine before sending layout to the subtree. These > changes correct this behavior, and the receiver’s position and usually > its size won’t be affected by layoutIfNeeded. > > Some existing code may be relying on this incorrect behavior that is > now corrected. There is no behavior change for binaries linked before > iOS 10, but when building on iOS 10 you may need to correct some > situations by sending -layoutIfNeeded to a superview of the > translatesAutoresizingMaskIntoConstraints view that was the previous > receiver, or else positioning and sizing it before (or after, > depending on your desired behavior) layoutIfNeeded. > > Third party apps with custom UIView subclasses using Auto Layout that > override layoutSubviews and dirty layout on self before calling super > are at risk of triggering a layout feedback loop when they rebuild on > iOS 10. When they are correctly sent subsequent layoutSubviews calls > they must be sure to stop dirtying layout on self at some point (note > that this call was skipped in release prior to iOS 10)."

Essentially you cannot call layoutIfNeeded on a child object of the View if you are using translatesAutoresizingMaskIntoConstraints - now calling layoutIfNeeded has to be on the superView, and you can still call this in viewDidLayoutSubviews.

Solution 5 - Ios

If the frames are not correct in layoutSubViews (which they are not) you can dispatch async a bit of code on the main thread. This gives the system some time to do the layout. When the block you dispatch is executed, the frames have their proper sizes.

Solution 6 - Ios

This fixed the (ridiculously annoying) issue for me:

- (void) viewDidLayoutSubviews {

    [super viewDidLayoutSubviews];

    self.view.frame = CGRectMake(0,0,[[UIScreen mainScreen] bounds].size.width,[[UIScreen mainScreen] bounds].size.height);

}

Edit/Note: This is for a full screen ViewController.

Solution 7 - Ios

Actually viewDidLayoutSubviews also is not the best place to set frame of your view. As far as I understood, from now on the only place it should be done is layoutSubviews method in the actual view's code. I wish I wasn't right, someone correct me please if it is not true!

Solution 8 - Ios

I already reported this issue to apple, this issue exist since a long time, when you are initializing UIViewController from Xib, but i found quite nice workaround. In addition to that i found that issue in some cases when layoutIfNeeded on UICollectionView and UITableView when datasource is not set in initial moment, and needed also swizzle it.

extension UIViewController {
    open override class func initialize() {
        if self !== UIViewController.self {
            return
        }
        DispatchQueue.once(token: "io.inspace.uiviewcontroller.swizzle") {
            ins_applyFixToViewFrameWhenLoadingFromNib()
        }
    }
    
    @objc func ins_setView(view: UIView!) {
        // View is loaded from xib file
        if nibBundle != nil && storyboard == nil && !view.frame.equalTo(UIScreen.main.bounds) {
            view.frame = UIScreen.main.bounds
            view.layoutIfNeeded()
        }
        ins_setView(view: view)
    }
    
    private class func ins_applyFixToViewFrameWhenLoadingFromNib() {
        UIViewController.swizzle(originalSelector: #selector(setter: UIViewController.view),
                                 with: #selector(UIViewController.ins_setView(view:)))
        UICollectionView.swizzle(originalSelector: #selector(UICollectionView.layoutSubviews),
                                 with: #selector(UICollectionView.ins_layoutSubviews))
        UITableView.swizzle(originalSelector: #selector(UITableView.layoutSubviews),
                                 with: #selector(UITableView.ins_layoutSubviews))
     }
}

extension UITableView {
    @objc fileprivate func ins_layoutSubviews() {
        if dataSource == nil {
            super.layoutSubviews()
        } else {
            ins_layoutSubviews()
        }
    }
}

extension UICollectionView {
    @objc fileprivate func ins_layoutSubviews() {
        if dataSource == nil {
            super.layoutSubviews()
        } else {
            ins_layoutSubviews()
        }
    }
}

Dispatch once extension:

extension DispatchQueue {
    
    private static var _onceTracker = [String]()
    
    /**
     Executes a block of code, associated with a unique token, only once.  The code is thread safe and will
     only execute the code once even in the presence of multithreaded calls.
     
     - parameter token: A unique reverse DNS style name such as com.vectorform.<name> or a GUID
     - parameter block: Block to execute once
     */
    public class func once(token: String, block: (Void) -> Void) {
        objc_sync_enter(self); defer { objc_sync_exit(self) }
        
        if _onceTracker.contains(token) {
            return
        }
        
        _onceTracker.append(token)
        block()
    }
}

Swizzle extension:

extension NSObject {
    @discardableResult
    class func swizzle(originalSelector: Selector, with selector: Selector) -> Bool {
        
        var originalMethod: Method?
        var swizzledMethod: Method?
        
        originalMethod = class_getInstanceMethod(self, originalSelector)
        swizzledMethod = class_getInstanceMethod(self, selector)
        
        if originalMethod != nil && swizzledMethod != nil {
            method_exchangeImplementations(originalMethod!, swizzledMethod!)
            return true
        }
        return false
    }
}

Solution 9 - Ios

My issue was solved by changing the usage from

-(void)viewDidLayoutSubviews{
    [super viewDidLayoutSubviews];
    self.viewLoginMailTop.constant = -self.viewLoginMail.bounds.size.height;
}

to

-(void)viewWillLayoutSubviews{
    [super viewWillLayoutSubviews];
    self.viewLoginMailTop.constant = -self.viewLoginMail.bounds.size.height;
}

So, from Did to Will

Super weird

Solution 10 - Ios

Better solution for me.

protocol LayoutComplementProtocol {
	func didLayoutSubviews(with targetView_: UIView)
}

private class LayoutCaptureView: UIView {
	var targetView: UIView!
	var layoutComplements: [LayoutComplementProtocol] = []

	override func layoutSubviews() {
		super.layoutSubviews()

		for layoutComplement in self.layoutComplements {
			layoutComplement.didLayoutSubviews(with: self.targetView)
		}
	}
}

extension UIView {
	func add(layoutComplement layoutComplement_: LayoutComplementProtocol) {
		func findLayoutCapture() -> LayoutCaptureView {
			for subView in self.subviews {
				if subView is LayoutCaptureView {
					return subView as? LayoutCaptureView
				}
			}
			let layoutCapture = LayoutCaptureView(frame: CGRect(x: -100, y: -100, width: 10, height: 10)) // not want to show, want to have size
			layoutCapture.targetView = self
			self.addSubview(layoutCapture)
			return layoutCapture
		}

		let layoutCapture = findLayoutCapture()
		layoutCapture.layoutComplements.append(layoutComplement_)
	}
}

Using

class CircleShapeComplement: LayoutComplementProtocol {
	func didLayoutSubviews(with targetView_: UIView) {
		targetView_.layer.cornerRadius = targetView_.frame.size.height / 2
	}
}

myButton.add(layoutComplement: CircleShapeComplement())

Solution 11 - Ios

Override layoutSublayers(of layer: CALayer) instead of layoutSubviews in cell subview to have correct frames

Solution 12 - Ios

If you need to do something based on your view's frame - override layoutSubviews and call layoutIfNeeded

    override func layoutSubviews() {
    super.layoutSubviews()
    
    yourView.layoutIfNeeded()
    setGradientForYourView()
}

I had the issue with viewDidLayoutSubviews returning the wrong frame for my view, for which I needed to add a gradient. And only layoutIfNeeded did the right thing :)

Solution 13 - Ios

As per new update in ios this is actually a bug but we can reduce this by using -

If you are using xib with autolayout in your project then you have to just update frame in autolayout setting please find image for this .enter image description here

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionMartinView Question on Stackoverflow
Solution 1 - IosMartinView Answer on Stackoverflow
Solution 2 - IosEugen DimboiuView Answer on Stackoverflow
Solution 3 - IosDerek SoikeView Answer on Stackoverflow
Solution 4 - IosHannahCarneyView Answer on Stackoverflow
Solution 5 - IosEmielView Answer on Stackoverflow
Solution 6 - IosNerdhappyView Answer on Stackoverflow
Solution 7 - Iosalex_roudiqueView Answer on Stackoverflow
Solution 8 - IosMichal ZaborowskiView Answer on Stackoverflow
Solution 9 - IosJanView Answer on Stackoverflow
Solution 10 - IosbizharaView Answer on Stackoverflow
Solution 11 - IosEntroView Answer on Stackoverflow
Solution 12 - IosVitya ShurapovView Answer on Stackoverflow
Solution 13 - Iosneha mishraView Answer on Stackoverflow