Introduction

Yes, but not directly on a plain UIView in the way you can set text, fonts, or colors on many built-in controls. Border styling lives on the view's backing CALayer, so the usual solution is to expose those layer values to Interface Builder with @IBInspectable properties.

Why Interface Builder Does Not Show These Fields By Default

UIView already has everything needed for a border at runtime:

• 'layer.borderWidth'
• 'layer.borderColor'
• 'layer.cornerRadius'

The problem is discoverability, not capability. Interface Builder does not automatically surface every useful CALayer property on every generic view, so you often need a custom subclass or extension to make those settings editable in the Attributes Inspector.

The Usual Fix: @IBInspectable

The cleanest way to make border properties editable in Interface Builder is to expose them as inspectable properties and forward them to the view's layer.

1import UIKit
2
3@IBDesignable
4final class BorderedView: UIView {
5    @IBInspectable var borderWidth: CGFloat = 0 {
6        didSet {
7            layer.borderWidth = borderWidth
8        }
9    }
10
11    @IBInspectable var borderColor: UIColor = .clear {
12        didSet {
13            layer.borderColor = borderColor.cgColor
14        }
15    }
16
17    @IBInspectable var cornerRadius: CGFloat = 0 {
18        didSet {
19            layer.cornerRadius = cornerRadius
20            layer.masksToBounds = cornerRadius > 0
21        }
22    }
23}

After adding this class to the project, assign BorderedView as the custom class in Interface Builder. The border fields then appear in the inspector and can be edited visually.

Why @IBDesignable Helps

@IBDesignable tells Interface Builder to render the custom appearance on the canvas, not just at runtime. That makes border work much faster because you can adjust width, color, and radius while looking at the actual layout.

For simple styling, this is usually worth it. If the custom view becomes complex, live rendering can slow Interface Builder, so do not treat @IBDesignable as mandatory for every subclass.

Extension Versus Subclass

You can also expose these properties in a UIView extension:

1import UIKit
2
3extension UIView {
4    @IBInspectable var ibBorderWidth: CGFloat {
5        get { layer.borderWidth }
6        set { layer.borderWidth = newValue }
7    }
8
9    @IBInspectable var ibCornerRadius: CGFloat {
10        get { layer.cornerRadius }
11        set {
12            layer.cornerRadius = newValue
13            layer.masksToBounds = newValue > 0
14        }
15    }
16}

This makes the properties available everywhere, which is convenient, but it also affects every UIView in the project. A subclass is usually a better choice if you want tighter control and clearer intent.

A good rule is:

• use a subclass when the style represents a reusable UI component
• use an extension when the team intentionally wants these helpers on most views

Interface Builder Runtime Attributes

Another option is User Defined Runtime Attributes. You can set values such as layer.cornerRadius or layer.borderWidth directly in Interface Builder without writing a subclass.

That works for quick one-off adjustments, but it has drawbacks:

• the available keys are less discoverable
• color bridging for CGColor is awkward
• the configuration is harder to reuse across multiple screens

For maintainability, @IBInspectable is usually better.

A Small Example In A View Controller

If you want to verify behavior in code as well, this works with the subclass above:

1import UIKit
2
3final class ViewController: UIViewController {
4    @IBOutlet private weak var cardView: BorderedView!
5
6    override func viewDidLoad() {
7        super.viewDidLoad()
8        cardView.borderWidth = 2
9        cardView.borderColor = .systemBlue
10        cardView.cornerRadius = 12
11    }
12}

The point is that the same properties can be configured either from Interface Builder or from code, which keeps the design flexible.

Common Pitfalls

The most common mistake is trying to assign a UIColor directly to layer.borderColor. The layer expects CGColor, so you need color.cgColor.

Another common issue is forgetting masksToBounds when using cornerRadius. Without it, subviews or layer contents may still draw outside the rounded corners.

Developers also sometimes put everything in a global UIView extension too early. That is convenient at first, but it can make the codebase less explicit about which views are supposed to be styleable.

Finally, remember that Interface Builder changes only affect the view instance you configured. If you want a shared visual style, put the logic into a reusable class rather than repeating inspector values everywhere.

Summary

• Yes, UIView border properties can be configured from Interface Builder, but usually through custom inspectable properties.
• The border settings live on the backing CALayer.
• '@IBInspectable makes width, color, and radius editable in the Attributes Inspector.'
• '@IBDesignable enables live preview on the storyboard canvas.'
• A subclass is usually cleaner than relying only on runtime attributes.