Is IBDesignable broken for AppKit in Xcode 9.2 and Swift 4?

Question

Most questions, and answers related to this, are based on older versions of both Xcode and Swift. Additionally, 90 percent of the questions relate to UIKit and drawing custom controls.

I am adding a standard button, that is centered inside a custom control, decorated with IBDesignable.

import Cocoa

@IBDesignable public class ButtonPresetView: NSView {
    public override init(frame frameRect: NSRect) {
        super.init(frame: frameRect)
        initialControlSetup()
    }

    public required init?(coder decoder: NSCoder) {
        super.init(coder: decoder)
        initialControlSetup()
    }

    private func initialControlSetup() {
        let button = NSButton(title: "Hello", target: nil, action: nil)
        button.translatesAutoresizingMaskIntoConstraints = false
        addSubview(button)

        // Configure button
        centerXAnchor.constraint(equalTo: button.centerXAnchor).isActive = true
        centerYAnchor.constraint(equalTo: button.centerYAnchor).isActive = true
    }
}

I add a custom view to the application and set the class property in the Identity Inspector to my custom class (ButtonPresetView).

It should show the button centered on the canvas, but the canvas is blank. Not sure many people use it this way, but it worked gloriously with Swift 3 in Xcode 8.3.

Does anyone else have this problem?

score 2 · Accepted Answer · answered Dec 08 '17 at 08:04

2

I was able to get this to work in the latest Xcode by adding the following two lines to the top of the initialControlSetup function:

wantsLayer = true
canDrawSubviewsIntoLayer = true

I think this basically tells the NSView to render in a way that is more similar to how iOS works. If this worked in Xcode 8.3 as you say, it's possible that Apple introduced this regression in Xcode 9 without realizing it.

answered Dec 08 '17 at 08:04

Dave Weston

6,527
1
29
44

Layering is on by default, so `wantsLayer = true` is uneccessary. – TimTwoToes Dec 09 '17 at 11:07
I’m not aware of AppKit making any changes in this area. Do you have a link that confirms that the default has changed? Or are you saying that just setting `canDrawSubviewIntoLayer` to `true` will turn on the `NSView`’s own layer? – Dave Weston Dec 09 '17 at 20:27
Sorry my wording is wrong. Layer-backing is not on by default in custom controls. I meant to say that, in a new AppKit project, the content view is layer-backed by default, and therefore all its sub-views. – TimTwoToes Dec 10 '17 at 20:58
In fact I believe you are right. The ``canDrawSubviewIntoLayer`` appears to be a move from Apple, to align the AppKit rendering model with the UIKit rendering model. I found out, if you un-check the layer-backed content view, the ``canDrawSubviewIntoLayer`` is unnecessary as well and works like it did in xCode 8.3. Thanks for the help. It was driving me nuts. – TimTwoToes Dec 10 '17 at 21:04

score 0 · Answer 2 · answered Dec 10 '17 at 22:16

Dave's answer is correct, I just want to make a note on the consequences of this solution.

When canDrawSubviewsIntoLayer is set to true, all its sub views, that did not enable wantsLayer specifically, will render its contents using the layer of the parent view with canDrawSubviewsIntoLayer set to true.

This means sub view animations is disabled, since they lack a backing layer of their own. To prevent this from happening during runtime, you can put canDrawSubviewsIntoLayer = true into the prepareForInterfaceBuilder() function.

On a curious note, Interface Builder does not render the control, if you explicitly set button.wantsLayer = true, which according to the "canDrawSubviewsIntoLayer" documentation, should give the control its own backing layer and not render itself into the parent layer. This is purely speculation, but I'm guessing as an optimisation, Interface Builder only renders the top layers/controls of the content view.

Is IBDesignable broken for AppKit in Xcode 9.2 and Swift 4?

2 Answers2