Connecting iPadOS and visionOS apps over the local network

At a glance

Project structure

Source bundle/
├── iPadCompanionApp/RobotConfigurationExperience/RobotConfigurationExperienceApp.swift  # RobotConfigurationExperienceApp
├── iPadCompanionApp/Companion/CompanionApp.swift  # CompanionApp
├── iPadCompanionApp/Packages/PeerToPeerMessaging/Sources/PeerToPeerMessaging/ConnectionTypes.swift  # NetworkEvent, ConnectionEvent, NetworkState
├── iPadCompanionApp/Packages/PeerToPeerMessaging/Sources/PeerToPeerMessaging/Actors/Client.swift  # Client
├── iPadCompanionApp/Companion/Views/ServerContentView.swift  # ServerContentView
├── iPadCompanionApp/SharedContent/Models/RobotViewModel.swift  # RobotViewModel
├── iPadCompanionApp/Packages/PeerToPeerMessaging/Sources/PeerToPeerMessaging/Protocols/PeerMessagingProtocols.swift  # PeerToPeerMessage, PeerMessagingManager
├── iPadCompanionApp/Packages/PeerToPeerMessaging/Sources/PeerToPeerMessaging/TLS/CertificateTrustManager.swift  # CertificateTrustManager
└── iPadCompanionApp/Packages/RealityKitContent/Package.realitycomposerpro/ProjectData/main.json  # authored RealityKit content

Structure observations

• The runtime boundary is WindowGroup + volumetric window; the pruned tree lists only files that explain lifecycle, state, or framework integration.
• App code is split into role-named views, models, managers, providers, components, or systems.
• Authored .reality or Reality Composer Pro content is a real implementation boundary; Swift loads or drives it rather than reproducing its entity graph.

Overall architecture

flowchart LR
    CompanionApp_1["CompanionApp"]
    WindowGroup___volumetric_window_2["WindowGroup + volumetric window"]
    ServerContentView_3["ServerContentView"]
    RobotViewModel_4["RobotViewModel"]
    RealityView_entity_graph_5["RealityView entity graph"]
    Peer_transport___Network_framework_6["Peer transport / Network.framework"]
    CompanionApp_1 --> WindowGroup___volumetric_window_2
    WindowGroup___volumetric_window_2 --> ServerContentView_3
    ServerContentView_3 --> RobotViewModel_4
    RobotViewModel_4 --> RealityView_entity_graph_5
    RealityView_entity_graph_5 --> Peer_transport___Network_framework_6

Reference code

iPadCompanionApp/Companion/CompanionApp.swift:12 — the app or executable entry declares the outer scene lifecycle.

struct CompanionApp: App {
    // ...
}

The diagram is a responsibility flow, not a claim that every adjacent node directly calls the next. It keeps scene ownership, shared state, RealityKit content, and framework-provider work at separate levels.

Ownership and state

classDiagram
    CompanionApp *-- PeerMessagingController : serverController
    CompanionApp *-- RobotViewModel : robotViewModel
    ServerContentView o-- ServerController : serverController
    ServerContentView o-- RobotViewModel : robotViewModel

Ownership evidence

iPadCompanionApp/Companion/CompanionApp.swift:13 — representative stored state or the nearest verified lifecycle anchor.

@main
struct CompanionApp: App {
    @State private var serverController: PeerMessagingController<Server<NetworkCommand>>
    // ...
}

Ownership here is deliberately narrow: @Environment and weak references are shared links, initialized @State or stored services are lifecycle ownership, and a RealityView content closure owns additions to its entity graph without making the SwiftUI view a reference-type owner.

Class and protocol design

Verified protocol-oriented seams: NetworkCommand → PeerToPeerMessage, RobotEvent → PeerToPeerMessage, MockNetworkActor → PeerMessagingManager. Framework conformances remain adapters, not proof of an app-wide protocol architecture.

Access control

No reviewed declaration uses fileprivate, open; unmodified Swift declarations are internal.

Reference code

iPadCompanionApp/Packages/PeerToPeerMessaging/Sources/PeerToPeerMessaging/PeerMessagingController.swift:24 — representative visibility boundary.

    public private(set) var connectionState: NetworkState = .cancelled
    public private(set) var errorMessage: String?

    // Tasks for monitoring state.
    @ObservationIgnored private var monitorTask: Task<Void, Never>?
    @ObservationIgnored private var networkTask: Task<Void, Error>?

Logic ownership and placement

Design patterns

Naming conventions

• Role suffixes are evidence, not decoration: App: CompanionApp, RobotConfigurationExperienceApp; ViewModel: RobotViewModel; Manager: CertificateTrustManager, PeerMessagingManager; Client: Client.
• Protocols: PeerToPeerMessage, PeerMessagingManager.
• Commands use verb-led methods: toggleWindowPresentation, start, createConnection, openStream, handleBrowserStateUpdates, invalidate, send, receiveMessages.
• Files generally match their primary type; Views, Models, Managers, Providers, Components, Systems, and Packages folders describe architectural roles where present.

Architecture takeaways

• Treat CompanionApp as the owner of scene declarations, not as the owner of every RealityKit entity created later.
• Keep view-local interaction in SwiftUI, but move provider sessions, playback resources, shared game state, or transport state into a stable owner when their lifetime exceeds one render pass.

Source map

• Official Apple documentation