# NTPAnalyzer-XCF — XCFramework distribution example

This NTPv4 plugin is built **without any access to the CocoaPacketAnalyzer source tree** — only the binary `CPAPluginSDK-X.Y.Z/` distribution.

This is the version a third-party developer would build outside the CPA repo. The Xcode project references nothing from `Packages/`; every compile-time and link-time dependency comes from the 9 `.xcframework` bundles in `Frameworks/`.

## Layout

```
NTPAnalyzer-XCF/
├── NTPAnalyzer.xcodeproj/         (uses XCFrameworks, no SPM)
├── NTPAnalyzer/
│   ├── NTPPlugInController.swift  (declares the settings surface)
│   ├── NTPProtocolAnalyzer.swift
│   ├── NTPDissector.swift
│   ├── Info.plist
│   └── en.lproj/LocalizableNTPAnalyzer.strings
├── Frameworks/                    (the 9 .xcframeworks this project links)
│   ├── CPAPluginSDK.xcframework
│   ├── CPADependencies.xcframework
│   └── …
└── README.md  (this file)
```

## Build

```bash
xcodebuild -project NTPAnalyzer.xcodeproj \
           -scheme NTPAnalyzer \
           -configuration Debug \
           -destination 'platform=macOS' \
           CODE_SIGNING_ALLOWED=NO \
           build
```

Output: `~/Library/Developer/Xcode/DerivedData/NTPAnalyzer-*/Build/Products/Debug/NTPAnalyzer.cpaplugin`.

## What this proves

The resulting `.cpaplugin` has the same Mach-O linkage as an SPM-built plugin:

```bash
otool -L NTPAnalyzer.cpaplugin/Contents/MacOS/NTPAnalyzer | grep @rpath
# Same 9 frameworks referenced, no embedded Frameworks dir.
```

Both approaches resolve their dynamic libraries from the host app's `Contents/SharedFrameworks/` at runtime. The XCFramework distribution is a drop-in replacement for the SPM path-reference approach, **with full library-evolution stability** — plugins can be built with a newer Xcode major version than the SDK without rebuilding the bundle.

