Sample CodemacOSReviewed 2026-07-21View on Apple Developer

Monitoring System Events with Endpoint Security

At a glance

Item Summary
Purpose Receive notifications and authorization requests for sensitive operations by creating an Endpoint Security client for your app.
App architecture A macOS installer app activates one system-extension target; that extension compiles either the authorization or notification C entry point and owns the Endpoint Security client loop.
Main patterns Delegate or data-source callbacks
Project style 7 scanned source file(s) across C, C/Objective-C header, Objective-C, organized around ranked entry, type, and file boundaries.

Project structure

Source bundle/
├── SampleEndpointApp/
│   ├── main.m
│   ├── AppDelegate.m
│   ├── ViewController.m
│   ├── AppDelegate.h
│   └── ViewController.h
├── Extension/
│   ├── auth_demo.c
│   ├── notify_demo.c
│   ├── Extension.entitlements
│   └── Info.plist
├── Configuration/
│   └── SampleCode.xcconfig
└── SampleEndpointApp.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, Objective-C.
  • The verified tree contains 8 project/configuration file(s) and 2 source declaration(s).

Overall architecture

Reference code

SampleEndpointApp/ViewController.m:28 — the app submits the activation request

    OSSystemExtensionRequest *req = [OSSystemExtensionRequest activationRequestForExtension:@"com.example.apple-samplecode.SampleEndpointApp.Extension" queue:dispatch_get_main_queue()];
    req.delegate = (id<OSSystemExtensionRequestDelegate>)self;

    [[OSSystemExtensionManager sharedManager] submitRequest:req];
    self.currentRequest = req;

Extension/auth_demo.c:136 — the selected extension entry creates and subscribes its client

es_client_t *client;
es_new_client_result_t result = es_new_client(&client, ^(es_client_t *c, const es_message_t *msg) {
    handle_event(c, msg);
});

Interpretation

The app and extension are separate lifecycle boundaries. The app retains the in-flight activation request; after launch, the system extension creates the Endpoint Security client and stays in its dispatch loop. The target includes exactly one of auth_demo.c or notify_demo.c, so those files are alternative extension entries rather than cooperating runtime layers.

Ownership and state

Ownership evidence

SampleEndpointApp/ViewController.m:12 — stored dependency or nearest verified ownership anchor

@interface ViewController ()

@property (strong) OSSystemExtensionRequest *currentRequest;
@property (weak) IBOutlet NSButton *installButton;
@property (unsafe_unretained) IBOutlet NSTextView *textView;

@end
Owner Object or state Relationship Mutation authority
ViewController OSSystemExtensionRequest (currentRequest) retains or copies an assigned value Owning Objective-C implementation
ViewController NSButton (installButton) holds a non-owning reference The referenced object’s lifecycle is owned elsewhere
ViewController NSTextView (textView) holds a non-owning reference The referenced object’s lifecycle is owned elsewhere

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

SampleEndpointApp/AppDelegate.h:9 — representative type boundary

@interface AppDelegate : NSObject <NSUserNotificationCenterDelegate>

@end
Type Responsibility Depends on or conforms to
AppDelegate Receives callback-driven events NSObject, NSUserNotificationCenterDelegate
ViewController View lifecycle, callbacks, and feature coordination NSViewController

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
currentRequest (SampleEndpointApp/ViewController.m:12) implementation Visibility follows header/implementation and language linkage rules. Inference: keep the declaration in the Objective-C implementation boundary.
installButton (SampleEndpointApp/ViewController.m:13) implementation Visibility follows header/implementation and language linkage rules. Inference: keep the declaration in the Objective-C implementation boundary.
textView (SampleEndpointApp/ViewController.m:14) implementation Visibility follows header/implementation and language linkage rules. Inference: keep the declaration in the Objective-C implementation boundary.
auth_demo (Extension/auth_demo.c:8) 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

SampleEndpointApp/ViewController.m:12 — representative boundary

@interface ViewController ()
// ...
@property (strong) OSSystemExtensionRequest *currentRequest;
// ...
@end

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
View lifecycle, callbacks, and feature coordination ViewController The source’s Controller suffix makes this role explicit.
Receives callback-driven events AppDelegate The source’s Delegate suffix makes this role explicit.

Design patterns

Pattern Source evidence Purpose or tradeoff
Delegate or data-source callbacks SampleEndpointApp/AppDelegate.h:9 Callback protocols invert event delivery back into the sample’s owner.

Naming conventions

  • Types: Controller: ViewController; Delegate: AppDelegate.
  • Protocols: no local protocol declaration in the scanned source.
  • Methods: applicationDidFinishLaunching, applicationWillTerminate, installExtension, viewDidLoad, setRepresentedObject, logText, logWithFormat, logError.
  • Files: SampleEndpointApp/AppDelegate.m, SampleEndpointApp/ViewController.m, SampleEndpointApp/AppDelegate.h, SampleEndpointApp/ViewController.h.

Architecture takeaways

  • SampleEndpointApp owns installation UI and request state; macOS owns extension activation and launch.
  • The selected C entry owns the Endpoint Security client until its dispatch loop ends; authorization and notification demos are build alternatives.
  • 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
SampleEndpointApp/main.m Feature implementation
Extension/auth_demo.c Feature implementation
Extension/notify_demo.c Feature implementation
SampleEndpointApp/AppDelegate.m AppDelegate
SampleEndpointApp/ViewController.m ViewController, activation request callbacks
SampleEndpointApp/AppDelegate.h AppDelegate
SampleEndpointApp/ViewController.h ViewController