Adopting drag and drop in a custom view

At a glance

Project structure

CustomViewDragAndDrop/
├── AppDelegate.swift
├── ViewController.swift
├── ViewController+Drag.swift
├── ViewController+Drop.swift
└── Base.lproj/Main.storyboard

Structure observations

• The files split protocol conformances, not ownership: all state still belongs to one controller.
• Cross-process representation (NSItemProvider) and in-process representation (localObject) are created together at the drag boundary.

Overall architecture

flowchart LR
    Controller["ViewController"] --> Image["UIImageView"]
    Controller --> Drag["UIDragInteraction"]
    Controller --> Drop["UIDropInteraction"]
    Image --> Drag
    Root["Controller root view"] --> Drop
    Controller ..-> DragDelegate["UIDragInteractionDelegate"]
    Controller ..-> DropDelegate["UIDropInteractionDelegate"]
    DragDelegate --> Item["UIDragItem and NSItemProvider"]
    Item --> DropDelegate
    DropDelegate --> Image

Reference code

CustomViewDragAndDrop/ViewController.swift:22 — setup attaches interactions to the views that own their lifetimes.

override func viewDidLoad() {
    super.viewDidLoad()
    imageView.isUserInteractionEnabled = true

    let dragInteraction = UIDragInteraction(delegate: self)
    imageView.addInteraction(dragInteraction)

    let dropInteraction = UIDropInteraction(delegate: self)
    view.addInteraction(dropInteraction)
}

Interpretation

The controller is both adapter and UI state owner. UIKit drives the delegates; the drag side publishes an image representation, and the drop side validates location/type before asynchronously assigning the result.

Ownership and state

classDiagram
    UIViewController o-- UIImageView : storyboard outlet
    UIImageView *-- UIDragInteraction : retains attached interaction
    UIView *-- UIDropInteraction : retains attached interaction
    UIDragInteraction o-- UIDragInteractionDelegate : delegate
    UIDropInteraction o-- UIDropInteractionDelegate : delegate
    UIDragItem *-- NSItemProvider : owns transfer provider
    UIDragItem o-- UIImage : localObject fast path

Ownership evidence

CustomViewDragAndDrop/ViewController+Drag.swift:17 — each drag item owns a portable provider and also carries the same image for local use/preview.

func dragInteraction(_ interaction: UIDragInteraction,
                     itemsForBeginning session: UIDragSession) -> [UIDragItem] {
    guard let image = imageView.image else { return [] }
    let provider = NSItemProvider(object: image)
    let item = UIDragItem(itemProvider: provider)
    item.localObject = image
    return [item]
}

Class and protocol design

No app-defined protocol is needed because one concrete controller implements both UIKit boundaries.

Access control

Reference code

CustomViewDragAndDrop/ViewController+Drop.swift:91 — drop-target highlighting is a controller helper shared only by drop callbacks in that extension file.

func updateLayers(forDropLocation dropLocation: CGPoint) {
    if imageView.frame.contains(dropLocation) {
        view.layer.borderWidth = 0
        imageView.layer.borderWidth = 2
    } else if view.frame.contains(dropLocation) {
        view.layer.borderWidth = 5
        imageView.layer.borderWidth = 0
    } else {
        view.layer.borderWidth = 0
        imageView.layer.borderWidth = 0
    }
}

Logic ownership and placement

Design patterns

Naming conventions

• +Drag and +Drop filenames name protocol-bound responsibilities.
• Delegate methods retain UIKit terminology; the one helper names its visible effect, updateLayers.
• dragInteraction/dropInteraction variables mirror framework types and lifecycle direction.

Architecture takeaways

• Attach interactions once, then keep session decisions in framework delegate conformances.
• Publish a transferable item-provider representation even when a local object is available.
• Validate type, cardinality, and location before proposing a drop operation.
• Splitting conformances across files does not create separate owners.

Source map

• Official Apple documentation