Integrating your messaging app with Apple Intelligence

At a glance

Project structure

UnicornChat/
├── AppIntents/                 # Schema intents, entities, queries, shortcuts
├── Managers/                   # Data, navigation, notifications, generation
├── Model/                      # SwiftData Contact/Conversation/Message
├── Extensions/                 # Model fetching and entity projections
├── Views/                      # Contact, conversation, and message features
└── UnicornChatApp.swift        # Composition root

The folders separate framework-facing contracts from stored models and UI. Larger ModelManager responsibilities are split into source extensions without creating additional owners.

Overall architecture

flowchart LR
    Root["UnicornChatApp"] --> Views["SwiftUI views"]
    Root --> Model["ModelManager actor"]
    Root --> Nav["NavigationManager"]
    Root --> DI["AppDependencyManager"]
    DI --> Intents["Message schema intents"]
    DI --> Queries["Entity queries"]
    Intents --> Model
    Intents --> Nav
    Model --> Store["SwiftData"]
    Model --> Generator["ConversationManager / Foundation Models"]
    Root --> Notifications["NotificationManager"]
    Notifications --> Nav

Reference code

UnicornChat/UnicornChatApp.swift:22 — the app creates one object graph and registers the same managers for App Intents.

init() {
    let model = ModelManager()
    let navigation = NavigationManager()
    AppDependencyManager.shared.add(dependency: navigation)
    AppDependencyManager.shared.add(dependency: model)
    NotificationManager.shared.configure(model: model, navigation: navigation)
    self.navigation = navigation
    self.model = model
}

Views and background intent invocations converge on the same state owners. The intent structs translate system schemas; they do not create stores or navigation state.

Ownership and state

classDiagram
    UnicornChatApp *-- ModelManager : creates and retains
    UnicornChatApp *-- NavigationManager : creates and retains
    ModelManager *-- ConversationManager : private owner
    ModelManager *-- ModelContainer : model actor storage
    NotificationManager o-- ModelManager : configured reference
    NotificationManager o-- NavigationManager : configured reference
    SendMessageIntent --> ModelManager : injected
    DraftMessageIntent --> NavigationManager : injected
    ConversationManager *-- Mutex : owns sessions

Ownership evidence

UnicornChat/Managers/ModelManager.swift:13 — the model actor privately owns the automatic-response service.

@ModelActor
actor ModelManager {
    @MainActor var mainContext: ModelContext {
        modelContainer.mainContext
    }
    private let conversationManager = ConversationManager()
}

Class and protocol design

Protocol-oriented design is concentrated at system boundaries (AppIntent, EntityQuery, IndexedEntity, Transferable, and UNUserNotificationCenterDelegate) rather than an app-defined service-protocol layer.

Access control

Reference code

UnicornChat/Managers/NotificationManager.swift:18 — singleton creation and its mutable links are narrowly scoped.

nonisolated(unsafe) static let shared = NotificationManager()

private var model: ModelManager?
private var navigation: NavigationManager?

private override init() {}

The nonisolated(unsafe) exception is limited to the singleton reference; configuration and delegate routing are explicitly main-actor operations.

Logic ownership and placement

Design patterns

Naming conventions

• Managers are named by owned capability: ModelManager, ConversationManager, NavigationManager, and NotificationManager.
• Stored domain nouns are un-suffixed (Message, Conversation, Contact); system projections add Entity.
• System commands use verb-noun Intent names such as SendMessageIntent and UnsendMessageIntent.
• Methods distinguish commands (sendMessage, openConversation) from lookups (entities(for:), fetchRecentMessages).
• Files generally match their primary type; extensions group fetch, entity conversion, and error concerns around ModelManager.

Architecture takeaways

• Register the same long-lived managers for views and App Intents instead of constructing a second state graph.
• Keep SwiftData mutation actor-isolated and cross that boundary with sendable snapshots for long-running generation work.
• Treat intents and entities as adapters around domain owners, not as owners themselves.
• Use weak/configured links for process services that route back into app state, and document narrow isolation exceptions.

Source map

• Official Apple documentation