How do their APIs compare?

Neither p0deje/maccy nor theboredteam/boring.notch expose a public "API" in the sense of a network service, SDK, or library interface meant for external consumers — both are standalone macOS menu bar apps. So "comparing their APIs" really means comparing their internal architecture/interfaces (how their components talk to each other). Here's what the retrieved code shows on that front:

Maccy — mostly synchronous, in-process, UI-driven interfaces

• Core logic is organized around small, focused Swift types like Search, exposed as a plain synchronous method: func search(string: String, within: [Searchable]) -> [SearchResult] [Maccy/Search.swift:L39-L41], which dispatches internally to simpleSearch, fuzzySearch, or mixedSearch based on a Defaults[.searchMode] setting [Maccy/Search.swift:L44-L52].
• State/actions are exposed through a shared singleton, AppState.shared, called directly from UI code (e.g. AppState.shared.history.clear(), AppState.shared.openPreferences()) [Maccy/Observables/Footer.swift:L42-L44, L63-L65, L79-L81]. This is a simple, centralized-singleton style "API" rather than a service-oriented one.
• Settings/preferences use the Defaults package with typed keys (e.g. Defaults.Toggle(key: [REDACTED], Defaults[.searchMode]`) as the interface between UI and persisted config [Maccy/Settings/GeneralSettingsPane.swift:L86-L96].
• Lower-level system interaction (e.g. ApplicationImage) wraps AppKit/DispatchSource APIs directly with callback-style event handlers rather than async/await [Maccy/ApplicationImage.swift:L42-L70].

boring.notch — heavier use of async/await and structured service objects

• Many "API" boundaries are @MainActor final class ... ObservableObject services with async methods, e.g. QuickLookService.show(urls:selectFirst:slideshow:) [boringNotch/components/Shelf/Services/QuickLookService.swift:L14-L34] and QuickShareService.discoverAvailableProviders() which is async and populates @Published state [boringNotch/components/Shelf/Services/QuickShareService.swift:L36-L44].
• There's an explicit XPC client layer (XPCHelperClient) exposing nonisolated async wrapper functions like setKeyboardBrightness(_:) async -> Bool and currentScreenBrightness() async -> Float?, which bridge to a remote XPC service via continuations [boringNotch/XPCHelperClient/XPCHelperClient.swift:L181-L199]. This is a much more formal async, error-handled inter-process API than anything visible in Maccy.
• Networking code (e.g. YouTubeMusicNetworking) uses real HTTP/token-based async methods — getPlaybackInfo(token:[REDACTED] async throws -> PlaybackResponse, toggleLike(token:[REDACTED] async throws -> Data — following a typical async REST client pattern with Decodable response types [boringNotch/MediaControllers/YouTube Music Controller/YouTubeMusicNetworking.swift:L46-L67].
• Settings navigation is exposed as a switch over string tab identifiers rendering different SwiftUI views [boringNotch/components/Settings/SettingsView.swift:L74-L96], structurally similar in spirit to Maccy's settings pane but not a shared/typed enum like Search.Mode.

Summary of the contrast

• Maccy's internal interfaces are simpler and synchronous/callback-based, centered on a singleton AppState and typed enums (Search.Mode) [Maccy/Search.swift:L6-L26].
• boring.notch's internal interfaces are more service-oriented, async/await-heavy, and include a genuine cross-process API (XPC) and external HTTP API client, reflecting its broader feature set (media control, sharing, XPC-based hardware access) versus Maccy's narrower clipboard-focused scope.

I don't have visibility into either project publishing a public developer-facing API (e.g., for third-party plugins); nothing in the retrieved data suggests either project has one. If you want, I can search further for plugin/extension points in either rep