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
flowchart LR
User["Install action"] --> App["SampleEndpointApp"]
App --> Manager["OSSystemExtensionManager"]
Manager --> Extension["Extension target"]
Extension --> Client["es_client_t event loop"]
Client --> ES["EndpointSecurity APIs"]
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
classDiagram
ViewController o-- OSSystemExtensionRequest : currentRequest
ViewController o-- NSButton : installButton
ViewController o-- NSTextView : textView
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;
// ...
@endSwift 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
SampleEndpointAppowns 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 |