Adding context menus in your app

At a glance

Project structure

ContextMenus/
├── ContextMenu.swift
├── Model.swift
├── BaseCollectionViewTestViewController.swift
├── BaseTableTestViewController.swift
├── CollectionView*.swift
├── TableView*.swift
├── Control*.swift
├── View*.swift
├── WebView*.swift
├── DetailViewManager.swift
├── SceneDelegate.swift
└── Base.lproj/Main.storyboard

Structure observations

• Filename families form a deliberate matrix of host (CollectionView, TableView, Control, View, WebView) and behavior (Basic, Submenu, Preview, PreviewProvider).
• Base list controllers own common sample data and layout; subclasses override only context-menu callbacks.
• Shared menu-action construction lives in capability protocols, not a utility singleton.

Overall architecture

flowchart LR
    Storyboard["Storyboard example menu"] --> Example["Concrete example controller"]
    Example --> Base["Base table or collection controller"]
    Base --> Data["Diffable data source and Model"]
    Example --> Delegate["UIKit context-menu delegate callback"]
    Example ..-> Capability["ContextMenu capability protocol"]
    Capability --> Actions["UIAction and UIMenu factories"]
    Delegate --> Preview["Optional preview controller"]
    Scene["SceneDelegate"] --> Detail["DetailViewManager"]

Reference code

ContextMenus/CollectionViewPreviewProvider.swift:14 — one example combines shared list data, a custom preview provider, and protocol-built actions.

override func collectionView(_ collectionView: UICollectionView,
                             contextMenuConfigurationForItemAt indexPath: IndexPath,
                             point: CGPoint) -> UIContextMenuConfiguration? {
    guard let item = dataSource.itemIdentifier(for: indexPath) else { return nil }
    return UIContextMenuConfiguration(identifier: NSString(string: item.name),
        previewProvider: { self.storyboard?.instantiateViewController(identifier: "PreviewViewController") },
        actionProvider: { _ in
            UIMenu(children: [self.inspectAction(indexPath),
                              self.duplicateAction(indexPath),
                              self.deleteAction(indexPath)])
        })
}

Interpretation

This is a catalog architecture, not one feature pipeline. Each screen is intentionally concrete, while base controllers and capability extensions remove only the repeated data/layout and action-building mechanics.

Ownership and state

classDiagram
    SceneDelegate *-- DetailViewManager : creates
    DetailViewManager o-- UISplitViewController : receives
    BaseCollectionViewTestViewController *-- UICollectionViewDiffableDataSource : creates
    BaseTableViewTestViewController *-- UITableViewDiffableDataSource : creates
    DiffableDataSource *-- Model : identifies values
    ExampleController --> UIContextMenuInteraction : creates and attaches
    UIView *-- UIContextMenuInteraction : retains after attachment
    UIContextMenuConfiguration --> UIViewController : preview provider creates

Ownership evidence

ContextMenus/SceneDelegate.swift:25 — the scene creates and retains the split-view helper, then injects the storyboard-owned split controller.

func scene(_ scene: UIScene, willConnectTo session: UISceneSession,
           options connectionOptions: UIScene.ConnectionOptions) {
    if let splitViewController = window!.rootViewController as? UISplitViewController {
        detailViewManager = DetailViewManager()
        detailViewManager.splitViewController = splitViewController
    }
}

Class and protocol design

This is genuine protocol-oriented reuse: protocols describe commands, extensions provide action factories, and concrete screens retain control of feature behavior.

Access control

Reference code

ContextMenus/BaseCollectionViewTestViewController.swift:10 — common layout is private, while the data source is intentionally visible to subclasses.

class BaseCollectionViewTestViewController: UICollectionViewController {
    private let sectionInsets = UIEdgeInsets(top: 6, left: 6, bottom: 6, right: 6)
    enum Section { case main }
    var dataSource: UICollectionViewDiffableDataSource<Section, Model>! = nil
}

Logic ownership and placement

Design patterns

Naming conventions

• Family prefixes name the host surface; suffixes name the demonstrated behavior.
• Base...TestViewController signals reusable catalog scaffolding rather than production domain screens.
• Capability protocols use noun phrases; required methods use perform..., and factories use ...Action.
• PreviewProvider names controllers that supply preview closures, not standalone provider objects.

Architecture takeaways

• Use capability protocols plus extensions when many unrelated screens share action construction but not effects.
• Keep UIKit context-menu configuration with the host controller because identifiers, previews, and commit navigation are host-specific.
• Share only the stable scaffolding—data source and layout—through base controllers.
• Distinguish framework ownership after addInteraction from temporary local creation.

Source map

• Official Apple documentation