Sample CodemacOSReviewed 2026-07-21View on Apple Developer

Building a Simple USB Driver

At a glance

Item Summary
Purpose Set up and load a driver that logs output to the Console app.
App architecture A C++, C/Objective-C header sample centered on SimpleUSBInterfaceDriver, with direct use of IOKit.
Main patterns No named application pattern supported by the extracted structure
Project style 3 scanned source file(s) across C++, C/Objective-C header, organized around ranked entry, type, and file boundaries.
Execution model No structured execution marker indexed; callback threading requires source review.
State/event model No structured observation or publisher-scheduling marker indexed.
Key frameworks/packages AssertMacros.h, IOKit, os; these are source dependencies, not architecture labels.

Project structure

Source bundle/
├── SimpleUSBInterfaceDriver/
│   ├── SimpleUSBInterfaceDriver.h
│   ├── SimpleUSBInterfaceDriver.cpp
│   ├── debug.h
│   └── Info.plist
├── Configuration/
│   └── SampleCode.xcconfig
└── SimpleUSBInterfaceDriver.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.
  • The verified tree contains 4 project/configuration file(s) and 1 source declaration(s).

Overall architecture

Reference code

SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.h:34 — architecture anchor

#ifndef _SimpleUSBInterfaceDriver_h_
class SimpleUSBInterfaceDriver: public IOService
{
    OSDeclareDefaultStructors(SimpleUSBInterfaceDriver)
    // ...
};
#endif

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 Kernel.

Ownership and state

Ownership evidence

SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.cpp:15 — stored dependency or nearest verified ownership anchor

OSDefineMetaClassAndStructors(SimpleUSBInterfaceDriver, IOService);
Owner Object or state Relationship Mutation authority
SimpleUSBInterfaceDriver Kernel APIs Uses framework types; no stored lifecycle relationship was detected in the architecture anchor. The declaring implementation controls calls.

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.

Concurrency, scheduling, and thread safety

Evidence limit: actor isolation, async/await, or Task creation does not by itself prove background-thread execution; Sendable conformance alone does not prove thread-safe mutation.

No source-visible execution, scheduling, or synchronization boundary was found in the indexed source.

@MainActor/MainActor.run, DispatchQueue.main, and RunLoop.main are reported as distinct isolation, queue, and event-loop mechanisms. A plain Task is kept separate from Task.detached; neither is labeled as a background thread.

State propagation, frameworks, and dependencies

Evidence limit: an import proves a source-level compilation dependency at the cited line; it does not prove runtime use, architectural adoption, or whether a Swift package is a direct application dependency.

Category Mechanism or module Verified role Evidence
Source import AssertMacros.h The cited file imports this module; runtime use and architectural role are not inferred. SimpleUSBInterfaceDriver/debug.h:92
Source import IOKit The cited file imports this module; runtime use and architectural role are not inferred. SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.h:31
Source import os The cited file imports this module; runtime use and architectural role are not inferred. SimpleUSBInterfaceDriver/debug.h:13

receive(on:) describes downstream delivery scheduling, while subscribe(on:) describes upstream subscription/request/cancel scheduling. An import Combine alone establishes neither behavior nor a Store, reducer, Redux, or other application architecture.

Class and protocol design

SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.h:34 — representative type boundary

#ifndef _SimpleUSBInterfaceDriver_h_
class SimpleUSBInterfaceDriver: public IOService
{
    OSDeclareDefaultStructors(SimpleUSBInterfaceDriver)
    // ...
};
#endif
Type Responsibility Depends on or conforms to
SimpleUSBInterfaceDriver Owns feature behavior and collaborator lifecycle IOService

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
SimpleUSBInterfaceDriver (SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.h:34) header-visible The declaration is exposed to translation units that import the header. Inference: declare a contract needed by other Objective-C/C translation units.
debugMasks_t (SimpleUSBInterfaceDriver/debug.h:16) language/file boundary Visibility follows header/implementation and language linkage rules. Inference: the language’s file or module boundary is sufficient for this sample collaboration.

Reference code

SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.h:34 — representative boundary

#ifndef _SimpleUSBInterfaceDriver_h_
class SimpleUSBInterfaceDriver: public IOService
{
    // ...
};
#endif

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
Feature and framework orchestration SimpleUSBInterfaceDriver The sample keeps the demonstrated path in its primary concrete type.

Design patterns

Pattern Source evidence Purpose or tradeoff
No named application pattern SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.h:34 The verified source directly composes concrete framework types; this document avoids forcing a pattern name.

Naming conventions

  • Types: feature-specific names rather than reusable layer suffixes.
  • Protocols: no local protocol declaration in the scanned source.
  • Methods: no representative method name extracted from the architectural files.
  • Files: SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.h.

Architecture takeaways

  • SimpleUSBInterfaceDriver is the main source-visible entry or composition anchor for this sample.
  • Framework work reaches IOKit 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
SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.h SimpleUSBInterfaceDriver, IOKit
SimpleUSBInterfaceDriver/SimpleUSBInterfaceDriver.cpp SimpleUSBInterfaceDriver, Feature implementation
SimpleUSBInterfaceDriver/debug.h debug, AssertMacros.h, os, Feature implementation