Connecting a network driver
At a glance
| Item | Summary |
|---|---|
| Purpose | Create an Ethernet driver that interfaces with the system’s network protocol stack. |
| App architecture | A C++, C/Objective-C header, Swift sample with the source-visible chain NetworkingDriverKitSampleApp → DriverLoadingView → DriverLoadingViewModel → DriverKit APIs. |
| Main patterns | Model-View-ViewModel, Delegate or data-source callbacks, Publisher-backed observable state |
| Project style | 5 scanned source file(s) across C++, C/Objective-C header, Swift, organized around ranked entry, type, and file boundaries. |
Project structure
Source bundle/
├── NetworkingDriverKitSampleApp/
│ ├── NetworkingDriverKitSampleApp.swift
│ ├── DriverLoadingViewModel.swift
│ ├── DriverLoadingView.swift
│ ├── NetworkingDriverKitSampleApp.entitlements
│ └── NetworkingDriverKitSampleApp.plist
├── NetworkingDriverKitSample/
│ ├── NetworkingDriverKitSample.cpp
│ ├── NetworkingDriverKitDebug.h
│ ├── NetworkingDriverKitSample.entitlements
│ └── NetworkingDriverKitSample.plist
├── Configuration/
│ └── SampleCode.xcconfig
└── NetworkingDriverKitSample.xcodeproj/
├── .xcodesamplecode.plist
└── project.pbxproj
Structure observations
- Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
- Primary languages: C++, C/Objective-C header, Swift.
- The verified tree contains 7 project/configuration file(s) and 8 source declaration(s).
Overall architecture
flowchart LR
N1["NetworkingDriverKitSampleApp"]
N2["DriverLoadingView"]
N3["DriverLoadingViewModel"]
N4["DriverKit APIs"]
N1 --> N2
N2 --> N3
N3 --> N4
Reference code
NetworkingDriverKitSampleApp/NetworkingDriverKitSampleApp.swift:10 — architecture anchor
@main
struct NetworkingDriverKitSampleApp: App {
var body: some Scene {
WindowGroup {
DriverLoadingView()
}
}
}Interpretation
The arrows summarize the source-visible entry, role-named types or folders, and framework direction; when nodes come from structural folders, the sequence is a high-level interpretation rather than proof that every adjacent node calls the next. Ownership is claimed only where the next section cites a stored property or assignment. The diagram is intentionally limited to the dominant path into PCIDriverKit.
Ownership and state
classDiagram
DriverLoadingViewModel o-- State : state
DriverLoadingViewModel *-- String : dextIdentifier
DriverLoadingView o-- DriverLoadingViewModel : viewModel
Ownership evidence
NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift:76 — stored dependency or nearest verified ownership anchor
class DriverLoadingViewModel: NSObject {
// ...
@Published private var state: DriverLoadingStateMachine.State = .unloaded
// ...
}| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
DriverLoadingViewModel |
State (state) |
stores or receives | Owning lexical scope |
DriverLoadingViewModel |
String (dextIdentifier) |
owns value state | Initialized by the owner; the binding is immutable |
DriverLoadingView |
DriverLoadingViewModel (viewModel) |
observes externally owned state | The observed object is authoritative |
Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.
Class and protocol design
NetworkingDriverKitSampleApp/NetworkingDriverKitSampleApp.swift:11 — representative type boundary
struct NetworkingDriverKitSampleApp: App {
var body: some Scene {
WindowGroup {
DriverLoadingView()
}
}
}| Type | Responsibility | Depends on or conforms to |
|---|---|---|
NetworkingDriverKitSampleApp |
Application entry and top-level composition | App |
DriverLoadingViewModel |
UI-facing state and feature coordination | NSObject |
DriverLoadingView |
User-interface presentation and input forwarding | View |
DriverLoadingStateMachine |
Owns feature behavior and collaborator lifecycle | Concrete collaborators/imported frameworks |
State |
Represents mutable feature state | Concrete collaborators/imported frameworks |
Event |
Defines a closed set of feature states or choices | Concrete collaborators/imported frameworks |
NetworkingDriverKitSample_IVars |
Represents a feature value or composable behavior | Concrete collaborators/imported frameworks |
IOUserNetworkPacketBufferPoolOptions |
Carries feature or framework configuration | Concrete collaborators/imported frameworks |
No local protocol conformance is claimed as protocol-oriented design; external framework conformances are listed only as dependencies.
Access control
| Symbol | Access | Verified effect | Likely rationale |
|---|---|---|---|
state (NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift:76) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
dextIdentifier (NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift:78) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
dextLoadingState (NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift:80) |
public |
The symbol is visible to importing modules. | Inference: make the declaration available across a module or target boundary. |
DriverLoadingView (NetworkingDriverKitSampleApp/DriverLoadingView.swift:8) |
implicit internal |
No explicit modifier means the Swift declaration is internal to the module. | Inference: app-target collaboration needs no exported library surface. |
Reference code
NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift:76 — representative boundary
class DriverLoadingViewModel: NSObject {
// ...
@Published private var state: DriverLoadingStateMachine.State = .unloaded
// ...
}Swift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.
Logic ownership and placement
| Logic | Owning type or file | Placement rationale |
|---|---|---|
| Application entry and top-level composition | NetworkingDriverKitSampleApp |
The source’s App suffix makes this role explicit. |
| User-interface presentation and input forwarding | DriverLoadingView |
The source’s View suffix makes this role explicit. |
| UI-facing state and feature coordination | DriverLoadingViewModel |
The source’s ViewModel suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| Model-View-ViewModel | NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift:73 |
Role-named view models keep UI-facing state or coordination outside view declarations. |
| Delegate or data-source callbacks | NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift:129 |
Callback protocols invert event delivery back into the sample’s owner. |
| Publisher-backed observable state | NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift:76 |
Published properties notify observers while mutation remains with the state object. |
Naming conventions
- Types: App: NetworkingDriverKitSampleApp; View: DriverLoadingView; ViewModel: DriverLoadingViewModel.
- Protocols: no local protocol declaration in the scanned source.
- Methods:
process,activateMyDext,activateExtension,deactivateExtension,request,requestNeedsUserApproval. - Files:
NetworkingDriverKitSampleApp/NetworkingDriverKitSampleApp.swift,NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift,NetworkingDriverKitSampleApp/DriverLoadingView.swift.
Architecture takeaways
NetworkingDriverKitSampleAppis the main source-visible entry or composition anchor for this sample.- Framework work reaches DriverKit, SwiftUI, NetworkingDriverKit, SystemExtensions through a deliberately small high-level chain; the detailed API graph remains inside the cited implementation files.
- Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
- Access-control conclusions separate verified language visibility from the likely design rationale.
- The source does not justify labeling the design protocol-oriented.
Source map
| Source file | Relevant symbols |
|---|---|
NetworkingDriverKitSampleApp/NetworkingDriverKitSampleApp.swift |
NetworkingDriverKitSampleApp |
NetworkingDriverKitSampleApp/DriverLoadingViewModel.swift |
DriverLoadingStateMachine, State, Event, DriverLoadingViewModel |
NetworkingDriverKitSampleApp/DriverLoadingView.swift |
DriverLoadingView, DriverLoadingView_Previews |
NetworkingDriverKitSample/NetworkingDriverKitSample.cpp |
NetworkingDriverKitSample_IVars, IOUserNetworkPacketBufferPoolOptions |
NetworkingDriverKitSample/NetworkingDriverKitDebug.h |
Feature implementation |