Supporting multiple windows on iPad

At a glance

Project structure

Source bundle/
├── Gallery/
│   ├── AppDelegate.swift
│   ├── InspectorSceneDelegate.swift
│   ├── GalleryViewController.swift
│   ├── InspectorViewController.swift
│   ├── PhotoDetailViewController.swift
│   ├── SceneDelegate.swift
│   ├── Photo.swift
│   ├── GalleryViewController+Toolbar.swift
│   └── PhotoCell.swift
├── Configuration/
│   └── SampleCode.xcconfig
└── Gallery.xcodeproj/
    ├── .xcodesamplecode.plist
    └── project.pbxproj

Structure observations

• The app delegate owns configuration routing only; gallery and inspector controllers own feature presentation.
• Photo converts domain identity into detail/inspector activities, keeping payload keys out of controllers.
• Inspector activation searches existing sessions first, preventing duplicate windows for the same photo.

Overall architecture

flowchart LR
    ACT["NSUserActivity type and photo payload"] --> APP["AppDelegate scene configuration router"]
    APP --> GALLERY["Gallery scene"]
    APP --> INSPECTOR["Inspector scene"]
    GALLERY --> PHOTO["Selected Photo"]
    PHOTO --> REQUEST["InspectorSceneDelegate.openInspectorSceneSessionForPhoto"]
    REQUEST --> FIND["Find matching open session"]
    FIND -->|found| REACTIVATE["Reactivate session"]
    FIND -->|missing| CREATE["Create session with activity"]
    CREATE --> INSPECTOR
    REACTIVATE --> INSPECTOR

Reference code

Gallery/AppDelegate.swift:18 — activity-based scene configuration

    func application(_ application: UIApplication,
                     configurationForConnecting connectingSceneSession: UISceneSession,
                     options: UIScene.ConnectionOptions) -> UISceneConfiguration {
        let configurationName: String
        switch options.userActivities.first?.activityType {
        case UserActivity.GalleryOpenInspectorActivityType:
            configurationName = "Inspector Configuration"
        default:
            configurationName = "Default Configuration"
        }
        return UISceneConfiguration(name: configurationName,
                                    sessionRole: connectingSceneSession.role)
    }

Interpretation

Scene creation is routed by an activity contract rather than a direct controller call. The gallery asks the inspector scene coordinator to open a photo, and the inspector coordinator owns session identity, activation, configuration, and restoration.

Ownership and state

classDiagram
    PhotoManager *-- PhotoArray : shared catalog
    GalleryViewController o-- PhotoArray : retained value
    GalleryViewController *-- UICollectionView : creates
    GalleryViewController *-- DiffableDataSource : creates
    Photo *-- NSUserActivity : computed payload
    UISceneSession o-- PhotoIdentity : userInfo
    InspectorSceneDelegate o-- UIWindow : UIKit supplies

Ownership evidence

Gallery/GalleryViewController.swift:13 — gallery model and collection state

    let photos = PhotoManager.shared.photos

    enum Section {
        case main
    }

    var dataSource: UICollectionViewDiffableDataSource<Section, Int>! = nil
    var collectionView: UICollectionView! = nil

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

Gallery/InspectorSceneDelegate.swift:89 — reuse-before-create scene policy

    class func activeInspectorSceneSessionForPhoto(_ photoAsset: String) -> UISceneSession? {
        for session in UIApplication.shared.openSessions
            where session.configuration.delegateClass == InspectorSceneDelegate.self {
            if let userInfo = session.userInfo,
               userInfo[InspectorSceneDelegate.inspectorScenePhotoAsset] as? String == photoAsset {
                return session
            }
        }
        return nil
    }

Scene, collection, drag, and user-activity protocols are UIKit/Foundation callbacks. The sample defines no local protocol abstraction; its cross-scene contract is the NSUserActivity type and user-info schema.

Access control

Reference code

Gallery/Photo.swift:20 — public type with internal members

public struct Photo {
    let assetName: String
    let title: String

    var inspectorUserActivity: NSUserActivity {
        let userActivity = NSUserActivity(
            activityType: UserActivity.GalleryOpenInspectorActivityType)
        userActivity.userInfo = activityUserInfo
        return userActivity
    }
}

Swift access is per declaration: public struct Photo does not promote unmodified properties to public. No open class hierarchy or fileprivate boundary appears in this feature.

Logic ownership and placement

Design patterns

Naming conventions

• Scene roles are explicit (SceneDelegate, InspectorSceneDelegate) and configuration names match those roles.
• Activity constants include the use case (GalleryOpenDetailActivityType, GalleryOpenInspectorActivityType).
• Commands state lifecycle intent (openInspectorSceneSessionForPhoto, activeInspectorSceneSessionForPhoto).
• Controller suffixes describe presentation roles; PhotoManager identifies the data owner.

Architecture takeaways

• Use an activity type and payload as the contract between a feature controller and a new scene.
• Let the scene delegate own reuse, activation, configuration, and restoration policy.
• Read access per declaration: a public container can still have internal members.

Source map

• Official Apple documentation