Updating collection views using diffable data sources

At a glance

Project structure

Source bundle/
├── DiffableDataSourceSample/
│   ├── AppDelegate.swift
│   ├── SidebarViewController.swift
│   ├── RecipeSplitViewController.swift
│   ├── RecipeListViewController.swift
│   ├── RecipeDetailViewController.swift
│   ├── SceneDelegate.swift
│   ├── Models/
│   │   ├── Data.swift
│   │   └── Recipe.swift
│   └── NotificationName.swift
├── Configuration/
│   └── SampleCode.xcconfig
└── DiffableDataSourceSample.xcodeproj/
    ├── .xcodesamplecode.plist
    └── project.pbxproj

Structure observations

• The split controller is the navigation/state coordinator; it does not own recipe persistence data.
• Snapshots contain stable identifiers, and cell providers resolve full models from DataStore at render time.
• Sidebar section snapshots and recipe-list snapshots are separate read models for the same store-driven feature.

Overall architecture

flowchart LR
    STORE["DataStore recipes and collections"] --> SIDEBAR["SidebarViewController"]
    SIDEBAR --> FILTER["RecipeSplitViewController.selectedRecipes"]
    FILTER --> NOTICE["selectedRecipesDidChange IDs"]
    NOTICE --> LIST["RecipeListViewController snapshot"]
    LIST --> SELECT["selectedRecipeId"]
    SELECT --> SPLIT["RecipeSplitViewController"]
    SPLIT --> DETAIL["RecipeDetailViewController"]
    STORE --> EVENTS["add/change/delete notifications"]
    EVENTS --> SPLIT
    EVENTS --> LIST

Reference code

DiffableDataSourceSample/RecipeSplitViewController.swift:45 — split-owned selection state

    var selectedRecipes: SelectedRecipes? {
        didSet {
            guard let navController = viewController(for: .supplementary) as? UINavigationController,
                  let recipeList = navController.topViewController as? RecipeListViewController
            else { return }
            recipeList.showRecipes()
        }
    }

    var selectedRecipeId: Recipe.ID? {
        didSet {
            if let id = selectedRecipeId {
                showRecipeDetail(with: id)
            } else {
                hideRecipeDetail()
                show(.supplementary)
            }
        }
    }

Interpretation

The split controller carries cross-column selection, while each child owns its own collection-view projection. Store events invalidate those projections through notifications. Stable IDs cross the boundaries; full Recipe values are resolved only where cell/detail content needs them.

Ownership and state

classDiagram
    GlobalDataStore *-- DataStore : let dataStore
    DataStore *-- RecipeArray : allRecipes
    DataStore *-- StringArray : collections
    RecipeSplitViewController *-- SelectedRecipes : selection state
    RecipeListViewController *-- DiffableDataSource : private
    SidebarViewController *-- DiffableDataSource : private
    RecipeSplitViewController o-- RecipeListViewController : storyboard child
    RecipeSplitViewController o-- RecipeDetailViewController : storyboard child
    ImageStore *-- UIImageDictionary : cache

Ownership evidence

DiffableDataSourceSample/RecipeListViewController.swift:14 — list-owned projection state

    private enum RecipeListSection: Int {
        case main
    }

    private var recipeListDataSource:
        UICollectionViewDiffableDataSource<RecipeListSection, Recipe.ID>!

    private var recipeSplitViewController: RecipeSplitViewController {
        self.splitViewController as! RecipeSplitViewController
    }

Composition denotes source-visible construction and retained value state. Aggregation denotes a stored or injected collaborator whose exclusive lifetime the source does not prove.

Class and protocol design

DiffableDataSourceSample/RecipeListViewController.swift:250 — identifier-to-model cell provider

        recipeListDataSource = UICollectionViewDiffableDataSource(
            collectionView: collectionView) { collectionView, indexPath, identifier in
                // The snapshot stores Recipe.ID, not Recipe.
                let recipe = dataStore.recipe(with: identifier)!
                return collectionView.dequeueConfiguredReusableCell(
                    using: recipeCellRegistration,
                    for: indexPath,
                    item: recipe)
            }

Collection and split behavior use UIKit callbacks. The sample defines no local repository or coordinator protocol; controllers read the concrete module-level dataStore, so substitutability is not an architectural goal here.

Access control

Reference code

DiffableDataSourceSample/Models/Data.swift:41 — same-file image-cache boundary

final class ImageStore {
    typealias _ImageDictionary = [String: UIImage]
    fileprivate var images: _ImageDictionary = [:]
    fileprivate static var scale = 2

    static var shared = ImageStore()

    fileprivate func _guaranteeImage(name: String) -> _ImageDictionary.Index {
        if let index = images.index(forKey: name) { return index }
        images[name] = ImageStore.loadImage(name: name)
        return images.index(forKey: name)!
    }
}

fileprivate is deliberately wider than private but narrower than internal: helpers elsewhere in Data.swift may participate in cache/store implementation. No public or open feature API appears.

Logic ownership and placement

Design patterns

Naming conventions

• Controller names map to split roles (Sidebar, RecipeList, RecipeDetail, RecipeSplit).
• Selection state distinguishes a query (selectedRecipes) from one identity (selectedRecipeId).
• Snapshot/item types include their projection role (RecipeListSection, SidebarItem).
• Private cache helpers use an underscore to mark low-level guarantee semantics within Data.swift.

Architecture takeaways

• Put only cross-column selection on the split coordinator; keep each diffable projection private to its controller.
• Snapshot stable identifiers and resolve mutable models from the authoritative store.
• Use fileprivate narrowly when several same-file declarations truly share an implementation boundary.

Source map

• Official Apple documentation