Adopting drag and drop in a table view

At a glance

Project structure

TableViewDragAndDrop/
├── AppDelegate.swift
├── SceneDelegate.swift
├── Model/
│   ├── Model.swift
│   └── Model+Dragging.swift
└── TableViewController/
    ├── TableViewController.swift
    ├── TableViewController+Data.swift
    ├── TableViewController+Drag.swift
    └── TableViewController+Drop.swift

Structure observations

• Core model mutation is separate from drag representation, but both remain extensions of the same value owner.
• Controller extensions align one-to-one with UIKit data-source/delegate boundaries.

Overall architecture

flowchart LR
    Controller["TableViewController"] --> Model["Model"]
    Controller ..-> Data["UITableView data callbacks"]
    Controller ..-> Drag["UITableViewDragDelegate"]
    Controller ..-> Drop["UITableViewDropDelegate"]
    Data --> Model
    Drag --> Model
    Model --> Provider["NSItemProvider plain text"]
    Provider --> Drop
    Drop -->|external copy| Model
    Data -->|local move| Model
    Model --> Table["UITableView rows"]

Reference code

TableViewDragAndDrop/TableViewController/TableViewController.swift:17 — the controller owns the model and installs itself at both framework boundaries.

class TableViewController: UITableViewController {
    var model = Model()

    override func viewDidLoad() {
        super.viewDidLoad()
        tableView.dragInteractionEnabled = true
        tableView.dragDelegate = self
        tableView.dropDelegate = self
        navigationItem.rightBarButtonItem = editButtonItem
    }
}

Interpretation

Local moves reuse the table’s traditional moveRowAt path, while external drops decode provider data and insert rows. Both paths commit through Model, keeping the array authoritative.

Ownership and state

classDiagram
    TableViewController *-- Model : owns value
    Model *-- Array~String~ : owns placeNames
    UITableView o-- UITableViewDragDelegate : nonowning callback
    UITableView o-- UITableViewDropDelegate : nonowning callback
    UIDragItem *-- NSItemProvider : owns
    UIDropSession o-- UIDragItem : supplies

Ownership evidence

TableViewDragAndDrop/Model/Model.swift:11 — callers can read place names, but array writes are restricted to model methods.

struct Model {
    private(set) var placeNames = ["Yosemite", "Yellowstone", "Theodore Roosevelt"]

    mutating func moveItem(at sourceIndex: Int, to destinationIndex: Int) {
        guard sourceIndex != destinationIndex else { return }
        let place = placeNames.remove(at: sourceIndex)
        placeNames.insert(place, at: destinationIndex)
    }
}

Class and protocol design

No app-defined protocol layer is present; concrete extensions directly implement UIKit’s boundaries.

Access control

Reference code

TableViewDragAndDrop/Model/Model+Dragging.swift:24 — transfer construction is exposed as a model-facing helper, while raw storage stays protected.

func dragItems(for indexPath: IndexPath) -> [UIDragItem] {
    let placeName = placeNames[indexPath.row]
    let data = placeName.data(using: .utf8)
    let itemProvider = NSItemProvider()
    itemProvider.registerDataRepresentation(
        forTypeIdentifier: kUTTypePlainText as String,
        visibility: .all) { completion in
            completion(data, nil)
            return nil
        }
    return [UIDragItem(itemProvider: itemProvider)]
}

Logic ownership and placement

Design patterns

Naming conventions

• Model is intentionally generic because the sample domain is incidental.
• moveItem and addItem name model mutations; dragItems names representation production.
• +Data, +Drag, +Drop, and +Dragging filenames expose boundary roles.
• UIKit delegate signatures retain framework vocabulary such as proposal, coordinator, and destination index path.

Architecture takeaways

• Keep table rows authoritative in the model and route both local and external operations through it.
• Use private(set) when UI needs read access but should not mutate collection storage directly.
• Separate a local move from an external copy because their data-delivery paths differ.
• Organize large delegate surfaces by extension without inventing extra owners.

Source map

• Official Apple documentation