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 C, C/Objective-C header, Objective-C sample bundle with entry-bearing project variants Extension, SampleEndpointApp, each leading to EndpointSecurity APIs. |
| 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. |
| 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 | Cocoa, bsm, dispatch, EndpointSecurity, os; these are source dependencies, not architecture labels. |
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
Bundle["Sample bundle"]
V1["Extension"]
V2["SampleEndpointApp"]
Boundary["EndpointSecurity APIs"]
Bundle --> V1
V1 --> Boundary
Bundle --> V2
V2 --> Boundary
Reference code
SampleEndpointApp/main.m:9 — architecture anchor
int main(int argc, const char * argv[]) {
@autoreleasepool {
// Setup code that might create autoreleased objects goes here.
}
return NSApplicationMain(argc, argv);
}Interpretation
The branches represent separate entry-bearing project variants in the downloaded bundle, not runtime calls between those variants. Each branch is intentionally collapsed at the documented framework boundary; the detailed target-local flow remains in the cited files. Ownership is claimed only where the next section cites a stored property or assignment.
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.
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 | Cocoa |
The cited file imports this module; runtime use and architectural role are not inferred. | SampleEndpointApp/AppDelegate.h:7 |
| Source import | bsm |
The cited file imports this module; runtime use and architectural role are not inferred. | Extension/auth_demo.c:10 |
| Source import | dispatch |
The cited file imports this module; runtime use and architectural role are not inferred. | Extension/auth_demo.c:9 |
| Source import | EndpointSecurity |
The cited file imports this module; runtime use and architectural role are not inferred. | Extension/auth_demo.c:8 |
| Source import | os |
The cited file imports this module; runtime use and architectural role are not inferred. | Extension/auth_demo.c:12 |
| Source import | stdio.h |
The cited file imports this module; runtime use and architectural role are not inferred. | Extension/auth_demo.c:11 |
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
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:132) |
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
mainis the main source-visible entry or composition anchor for this sample.- Framework work reaches Cocoa, EndpointSecurity, bsm, dispatch 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 |
|---|---|
SampleEndpointApp/main.m |
Cited implementation, Feature implementation |
SampleEndpointApp/ViewController.m |
Cited implementation, currentRequest, installButton, textView, ViewController |
SampleEndpointApp/AppDelegate.h |
AppDelegate, Cited implementation, Cocoa |
Extension/auth_demo.c |
Cited implementation, bsm, dispatch, EndpointSecurity, os, stdio.h, Feature implementation |
Extension/notify_demo.c |
Feature implementation |
SampleEndpointApp/AppDelegate.m |
AppDelegate |
SampleEndpointApp/ViewController.h |
ViewController |