How do their APIs compare?

I should clarify: neither of these two projects exposes a conventional public "API" (like REST endpoints or a client library) — they're both native macOS desktop apps. So "API" here really means their internal code interfaces / architecture for how components interact. Let me compare what's visible from the retrieved source.

p0deje/maccy

Maccy's internal structure is organized around a few focused classes with narrow, single-purpose interfaces:

• Search exposes one public entry point, search(string:within:), which dispatches to private strategies (simpleSearch, fuzzySearch, mixedSearch) based on a Defaults[.searchMode] setting, returning [SearchResult] [Maccy/Search.swift:L36-L52]. The Mode enum (exact, fuzzy, regexp, mixed) is the whole "API surface" a caller needs to know about [Maccy/Search.swift:L6-L24].
• Notifier is a static-method utility (authorize(), notify(body:sound:)) wrapping UNUserNotificationCenter, with no instance state — a simple procedural API [Maccy/Notifier.swift:L4-L34].
• ApplicationImage and HistoryItem use Combine-style reactive properties (lastChecked, image) and file-system event sources (DispatchSource) rather than request/response calls — icons update themselves via .write/.delete filesystem events [Maccy/ApplicationImage.swift:L36-L75].
• HistoryItem also exposes computed properties like fromMaccy, universalClipboard that inspect pasteboard content types, plus a private Vision-framework OCR pipeline (performTextRecognition, recognizeTextHandler) [Maccy/Models/HistoryItem.swift:L211-L262].

Overall Maccy's internal "API" style leans toward small, stateless/static utility classes and computed properties, with search behavior configured via a global Defaults settings enum rather than constructor parameters.

runjuu/inputsourcepro

Input Source Pro's internals are built heavily around Core Data (NSPersistentContainer, NSFetchRequest, NSFetchedResultsController) as its primary data-access layer, which is a very different paradigm from Maccy's plain Swift objects:

• MainStorage wraps a persistent container and exposes reactive state via Combine CurrentValueSubject (e.g., keyboardConfigs), refreshed through a NSFetchedResultsController delegate pattern (refresh()) [Input Source Pro/Persistence/MainStorage.swift:L1-L40].
• SettingsBackup exposes a set of fetch*() throwing methods (fetchAppRules, fetchBrowserRules, fetchKeyboardConfigs, fetchHotKeyGroups) that each build an NSFetchRequest with sort descriptors and return typed arrays, plus a transactional restore-style method that deletes and reinserts objects inside a do/catch with context.rollback() on failure [Input Source Pro/Persistence/SettingsBackup.swift:L561-L635].
• PreferencesVM+BrowserRule and PreferencesVM+AppCustomization follow a consistent mutate-then-notify pattern: methods like updateBrowserRule(...) and toggleBrowserRule(...) wrap changes in saveContext { ... } closures and, on success, call notifyRuntimeRulesChanged() to propagate updates [Input Source Pro/Models/PreferencesVM+BrowserRule.swift:L36-L71]. Similarly getAppCustomization(bundleId:) and cleanRemovedAppCustomizationIfNeed() use NSPredicate-based fetch requests [Input Source Pro/Models/PreferencesVM+AppCustomization.swift:L106-L129].
• Naming/style conventions are explicitly documented in AGENTS.md: UpperCamelCase types, Type+Feature.swift extension files, 4-space indentation [AGENTS.md:L18-L25] — Input Source Pro is more deliberately documented for contributors than what's shown from Maccy.