Adopting menus and UIActions in your user interface

At a glance

Project structure

ControlMenus/
├── ViewController.swift
├── CustomMenuControl.swift
├── ButtonMenuDemoViewController.swift
├── BarButtonItemDemoViewController.swift
├── SegmentedControlDemoViewController.swift
├── DeferredMenuElementDemoViewController.swift
├── UpdateMenuViewController.swift
├── AppDelegate.swift
└── SceneDelegate.swift

Structure observations

• UIAction values carry titles, state, and closures directly; there is no command-model layer.
• CustomMenuControl is both reusable navigation control and the most complete custom-menu example.
• Asynchronous and live-update lifecycles stay in their dedicated demo controllers.

Overall architecture

flowchart LR
    Root["ViewController"] --> Selector["CustomMenuControl"]
    Selector --> Actions["UIAction values"]
    Actions --> Nav["UINavigationController"]
    Nav --> Button["Button demo"]
    Nav --> Bar["Bar-button demo"]
    Nav --> Segment["Segmented-control demo"]
    Nav --> Deferred["Deferred-element demo"]
    Nav --> Update["Visible-menu update demo"]
    Selector --> Menu["Computed UIMenu of proxy actions"]

Reference code

ControlMenus/ViewController.swift:15 — the root expresses navigation as action values installed on one custom menu control.

let customMenuControl = CustomMenuControl(
    frame: .zero,
    primaryAction: UIAction(title: "Demo Selector") { _ in })
customMenuControl.showSelectedItem = false
customMenuControl.items = [
    UIAction(title: "Button Demo") { [unowned self] _ in
        self.navigationController?.pushViewController(ButtonMenuDemoViewController(), animated: true)
    },
    UIAction(title: "Deferred Element Demo") { [unowned self] _ in
        self.navigationController?.pushViewController(DeferredMenuElementDemoViewController(), animated: true)
    }
]

Interpretation

The sample treats actions as composable values: the same object can describe a menu item and execute navigation or UI effects. Demo screens remain intentionally independent so their UIKit configurations are easy to compare.

Ownership and state

classDiagram
    ViewController *-- CustomMenuControl : creates and adds
    CustomMenuControl *-- Array~UIAction~ : stores items
    CustomMenuControl *-- UILabel : lazy private child
    CustomMenuControl --> UIMenu : computes
    UIMenu *-- UIAction : children
    UpdateMenuViewController *-- UIContextMenuInteraction : stores
    UpdateMenuViewController *-- Timer : owns while visible
    DeferredMenuElement --> CompletionClosure : completes asynchronously

Ownership evidence

ControlMenus/CustomMenuControl.swift:19 — the control owns source actions and selection state; changing them refreshes or disables its menu.

var items: [UIAction] = [] {
    didSet {
        if items.isEmpty {
            contextMenuInteraction?.dismissMenu()
            isContextMenuInteractionEnabled = false
        } else {
            updateMenuIfVisible()
            isContextMenuInteractionEnabled = true
        }
    }
}

var selectedIndex: Int = -1 {
    didSet { updateMenuIfVisible() }
}

Class and protocol design

No app-defined protocol exists; UIAction closures and UIKit delegate methods provide the collaboration boundaries.

Access control

Reference code

ControlMenus/CustomMenuControl.swift:54 — the private lazy label is created only through the control’s own rendering path.

private lazy var titleLabel: UILabel = {
    let label = UILabel()
    label.textColor = tintColor
    label.highlightedTextColor = .secondaryLabel
    addSubview(label)
    return label
}()

Logic ownership and placement

Design patterns

Naming conventions

• Demo types end in DemoViewController; names identify the UIKit API under study.
• items, selectedIndex, and showSelectedItem form the custom control’s small state API.
• Factory/forwarding methods use proxyAction, menu, and updateMenuIfVisible.

Architecture takeaways

• Model menu commands as values when metadata and effect naturally travel together.
• Keep a custom control’s subviews private and expose semantic items/selection instead.
• Scope timers and deferred work to menu presentation lifecycle.
• Treat catalog screens as independent examples, not a forced application-layer hierarchy.

Source map

• Official Apple documentation