This repository implements a Build Server Protocol (BSP) server that integrates Xcode builds with language servers like sourcekit-lsp. It parses Xcode build logs (either from IDE builds or xcodebuild) to extract compiler flags and serves them via BSP to provide accurate code completion, navigation, and other language features for Swift, C, C++, Objective-C, and Objective-C++ projects. The server operates in two modes: 'xcode' mode automatically monitors build logs via a post-build script or file watching, and 'manual' mode processes build logs on demand. Key components include a robust compilation database handler, a parser for Xcode's proprietary xcactivitylog binary format, and a log parser that handles various Xcode build output formats. The project is actively maintained with recent commits and shows no significant technical debt.
This repository contains a tool named `xcdiff` for comparing two Xcode project files (.xcodeproj) and outputting their differences in multiple formats. It is designed as both a command-line utility and a reusable Swift library (XCDiffCore). The tool analyzes structural and configuration differences between projects, including targets, sources, headers, resources, build settings, and dependencies. The architecture follows a modular, plugin-like design where each aspect of the project comparison is handled by a separate comparator implementing a common protocol. This allows for easy extension with new comparison types. Results are rendered through a similarly abstracted renderer system, supporting output formats such as plain text, JSON, markdown, and HTML. The tool is actively maintained and keeps pace with evolving Xcode project formats, as evidenced by fixtures for recent Xcode features like synchronized groups.
AsyncBluetooth is a Swift Package Manager library that brings Swift Concurrency to CoreBluetooth. It wraps the central manager and peripheral delegate APIs into async/await methods and AsyncStreams, so clients can scan, connect, discover services and characteristics, read/write values, and subscribe to notifications without nested delegate callbacks. It is not a standalone application; it is a dependency library for Apple-platform apps performing Bluetooth Low Energy central-role work. Architecturally, the code is split into CentralManager and Peripheral layers, with supporting types for scan data, services, characteristics, and events. A notable internal component is CentralManagerContext, a serialized async work queue that guarantees per-key operation ordering and supports cancellation. CoreBluetooth callbacks are translated into typed event enums such as CentralManagerEvent and exposed as AsyncStreams. The library uses os.log for diagnostics and ships a privacy manifest, indicating modern Apple platform practices. Maintenance is active: the repository has recent commits and a 6.2.2 tag. The code uses current Swift concurrency features, has no third-party dependencies, and includes tests. Technical drift is low.
The SwiftUIMasonry library provides two custom layout types for SwiftUI: `VMasonry` and `HMasonry`, which arrange subviews in a vertical or horizontal masonry grid respectively. These layouts support adaptive or fixed column/row counts, configurable spacing, and two placement modes (fill or order) to control how subviews are positioned. Subviews can also span multiple columns or rows using the `masonryColumnSpan` and `masonryRowSpan` view modifiers. The library is structured as a Swift package with a clear separation between public API and internal implementation. The API exposes the layout structures, configuration enums (for column/row counts and placement mode), and view extensions for setting span values. The internal files contain the layout logic, including a caching mechanism to optimize performance by storing layout results for specific size proposals. Key reusable components include the `MasonryColumnCount` and `MasonryRowCount` enums, which provide a type-safe way to specify adaptive or fixed dimensions, and the layout value system (keys and view extensions) that allows subviews to communicate their span requirements to the parent layout. These components demonstrate solid SwiftUI engineering practices and could be extracted for use in other custom layout systems.
MiaoYan is a local-first macOS Markdown note-taking application (Swift 6, AppKit, macOS 12+) that treats notes as plain .md/.markdown/.txt files in a user-selected folder. In production it is a desktop editor: an FSEvents watcher detects external file changes, cmark-GFM renders Markdown through a single pipeline, and a WebKit preview surface (vendored KaTeX, Mermaid, PlantUML, Markmap, Reveal.js) handles rendering. The app ships wikilinks/backlinks, version history, CJK-aware typography normalization, PDF/HTML/PNG/PPT export, and URL routing (miaoyan://, nv://, nvalt://). There is no server component — cloud sync is deliberately delegated to iCloud Drive/Nutstore/Dropbox. Distribution includes Sparkle auto-update, Homebrew, App Store, a bash CLI (miao), and an agent-facing SKILL.md. The architecture is a monolith with two UI shells: the primary AppKit storyboard window (ViewController, EditTextView, SidebarProjectView) and an in-progress SwiftUI shell launched via -MiaoYanShell YES. Both shells share the Business/ layer, with dedicated parity tests keeping them aligned. A Foundation-only MiaoYanCore package holds platform-agnostic text logic (frontmatter parsing, multi-encoding detection, search matching, preview extraction) shared with an iOS build — the cleanest architectural boundary in the repo. Core domain services include Storage/Note/Project models, NoteVersionManager, WikilinkIndex, CloudSyncManager (NSMetadataQuery-based), and debounced atomic saves using renamex_np RENAME_SWAP. Engineering strengths: an extensive regression-driven test suite (26+ files) covering real incident history (editor buffer ownership #543, storage relocation, save debounce, shell parity), strict CI where SwiftLint and swift-format warnings block merges, tiered highlighting for very large files, xattr-based note metadata, legacy encoding support (UTF-8/UTF-16/GB18030/Big5/CP1252), and localization in five languages. Notable weaknesses: ViewController is a god-class accumulating layout/keyboard/storage/preview/PPT logic; the dual-UI shell carries ongoing parity risk; saveCloudPins/restoreCloudPins are empty stubs (cloud pin sync is unimplemented); large hand-maintained regex sets in NotesTextProcessor; UserDefaults key sprawl; two Package.resolved manifests with a Sparkle version mismatch (2.8.0 vs 2.9.0); and a large vendored DownView.bundle JS payload that is an update/maintenance burden.
Peekaboo is a mature macOS desktop automation toolkit that provides a CLI, Mac app, and MCP server for screen capture, UI element detection, input synthesis, window management, and AI agent integration. The architecture is modular: a Swift CLI (peekaboo) exposes ~33 commands for interaction, system control, and AI agent orchestration; a Mac app provides a menu bar interface, session management, and visualizer overlays; a bridge daemon (PeekabooBridge) enables secure remote automation via a versioned socket protocol with operation allowlisting. The MCP server exposes native automation tools to AI clients (Claude, Cursor, etc.) via stdio transport. The agent runtime (PeekabooAgentService) supports multiple AI providers (OpenAI, Anthropic, Ollama, etc.) with streaming, tool calling, and session persistence. The codebase is written in Swift 6.2 with strict concurrency, extensive unit/integration tests, and a focus on safety (fail-closed target validation, honest effect reporting). It is not a data research project; it is a production-grade application for macOS automation.
Themis is a cross-platform cryptographic library developed by Cossack Labs, providing high-level security primitives such as Secure Cell (symmetric encryption with three modes: Seal, Token Protect, Context Imprint), Secure Message (asymmetric encryption and digital signing), Secure Session (mutual authentication and key exchange), Secure Comparator (zero-knowledge password comparison), and key generation (EC, RSA, symmetric). The core is implemented in C with a cryptographic engine abstraction layer (Soter) that supports OpenSSL, BoringSSL, and a custom Ed25519 implementation. The library exposes consistent APIs across 13+ language wrappers including Python, Go, Rust, Java, Swift, Objective-C, JavaScript (Node.js and WebAssembly), PHP, Ruby, C++, and React Native. The codebase is well-structured with extensive unit, integration, and fuzz testing, CI/CD pipelines for each wrapper, and cross-language compatibility tests. While the repository has deprecated older APIs and maintains multiple backends, it remains actively maintained with regular releases, security patches, and community engagement.
This repository implements the GraphQL specification for Swift, providing a complete parsing, validation, and execution engine. It is a library intended to be consumed by server‑side Swift frameworks (e.g., Graphiti, graphql‑vapor) or any Swift project requiring GraphQL support. The architecture follows a layered design: a lexical analyzer and recursive‑descent parser produce an AST (Sources/GraphQL/Language/), a rich type system (Sources/GraphQL/Type/) supports all GraphQL types and directives, a validation layer (Sources/GraphQL/Validation/) implements over 20 spec‑required rules, and an execution engine (Sources/GraphQL/Execution/) resolves queries concurrently. Subscriptions are supported via Swift async sequences (Sources/GraphQL/Subscription/). The library also includes schema construction from SDL, schema printing, and a flexible Map value type for dynamic GraphQL values. In production, a client calls the top‑level `graphql()` function with a schema, a query string, and optional variables. The query is parsed, validated against the schema, and then executed field‑by‑field. Resolvers (provided by the schema) produce results that are serialized into a `GraphQLResult` with proper error handling. The library handles all GraphQL features: object types, interfaces, unions, enums, input objects, custom scalars, directives (`@deprecated`, `@specifiedBy`, `@oneOf`), and persisted queries. The test suite mirrors the reference JavaScript implementation and covers the Star Wars schema, introspection, federation, and edge cases. The codebase is well‑structured and follows best practices for Swift libraries: it uses Swift concurrency, Sendable annotations, and the `swift‑collections` package for ordered dictionaries. Several components are self‑contained and could be reused independently, such as the `Map` dynamic value type, the AST visitor infrastructure, and the printer. However, some deviations from the GraphQL spec remain (e.g., a handful of validation rules are commented out), and there is code duplication between `AnyCoder` and `MapCoder`. Force‑unwraps and some thread‑safety workarounds indicate areas that could be hardened. Overall, the library is production‑ready and actively maintained.
This repository is a Flutter plugin that bridges Flutter applications with Apple CarPlay and Android Auto in-car infotainment systems. It provides a Dart API to construct native vehicle-optimized UI templates (lists, grids, tab bars, alerts, search, etc.) and manage navigation stacks on both platforms. The architecture is a classic Flutter plugin pattern: Dart models serialize to JSON, which is passed via method channels to native iOS (Swift) and Android (Kotlin) implementations that render the corresponding native CarPlay/Android Auto templates. Event channels handle user interactions (list item selection, alert actions, connection changes) back to Dart. The plugin includes a sophisticated SVG rasterization utility that converts Flutter asset SVGs to PNG bytes for native consumption, since native platforms cannot render SVG directly. It also provides image loading with caching and tinting on both platforms. The example app demonstrates full setup and usage for both iOS and Android, including scene delegate configuration and Android Auto service registration. External dependencies include the Flutter SDK, flutter_svg for rasterization, and native frameworks (CarPlay.framework on iOS, Car App API on Android).
This repository builds 'WWDC', an unofficial macOS application for browsing, searching, and playing WWDC session videos. It provides a native experience with features like video playback via a custom PlayerUI framework, transcript viewing with full-text search, session scheduling, bookmarks, favorites, iCloud sync via CloudKit, and video downloading. The architecture is modular, comprising main app target with embedded frameworks (PlayerUI, ConfUIFoundation, ConfCore), an XPC service for transcript indexing, and a Swift package for transcript handling. Data flows from Apple's WWDC API through a sync engine into a local Realm database, with UI built using AppKit and SwiftUI, heavy use of Combine for reactive updates, and Sparkle for auto-updates. While primarily an application, it also includes JSON fixtures and test data for transcript processing, giving it a minor hybrid character.
Gifski is a polished macOS application that converts video files into high-quality animated GIFs. The application uses a hybrid architecture: a SwiftUI frontend handles the user interface, video decoding (via AVFoundation), real-time preview compositing (via Metal shaders), and system integration (Share Extension, Shortcuts), while the core GIF encoding is performed by a companion Rust library (gifski-api) exposed through a C API. Key data flows involve decoding video frames, optional cropping/trimming/resizing, temporal denoising and palette quantization in the Rust engine, and finally writing the GIF output. The codebase demonstrates solid engineering with actor-based concurrency, comprehensive unit tests, and reusable UI components. However, it carries technical drift from macOS version workarounds and deprecated Rust API usage, and targets a future macOS version (26+) not yet generally available.
ZLPhotoBrowser is a mature, feature-rich iOS library for selecting, previewing, and editing photos and videos, inspired by the WeChat photo picker. It provides a full-screen image/video preview with pinch-to-zoom, a custom camera with photo and video recording, and an extensive image editor supporting drawing, mosaic, text/image stickers, filters, brightness/contrast/saturation adjustments, and clipping with various aspect ratios. The library also handles GIFs, Live Photos, and video trimming/merging. It is built entirely in Swift and targets iOS 10+. The architecture is UIKit-based, centered around a navigation controller flow (`ZLImageNavController`) that manages album list (`ZLAlbumListController`), thumbnail grid (`ZLThumbnailViewController`), and preview (`ZLPhotoPreviewController`). Configuration is handled via singleton classes (`ZLPhotoConfiguration`, `ZLPhotoUIConfiguration`, `ZLEditImageConfiguration`) with a builder-pattern chaining API. The library uses `PHPhotoLibrary` for asset fetching, `AVFoundation` for camera and video processing, and `Core Image` for filters. It includes custom interactive transitions for dismiss and pop animations, and a gesture coordinator for sticker manipulation. Key entry points are `ZLPhotoPicker` (SwiftUI wrapper) and `ZLPhotoPreviewSheet` (UIKit) for presenting the picker. The library has no external dependencies for its core functionality; the example app bundles Kingfisher and SnapKit for demonstration purposes. It supports CocoaPods, Carthage, and Swift Package Manager, and includes localization for 17 languages. The codebase is well-structured with clear separation of concerns, though some view controllers are large and there is minor duplication in transition logic.
EFQRCode is a pure-Swift, cross-platform Apple framework for generating stylized and highly customizable QR codes, and for recognizing QR codes from images. The core production code exposes two primary entry points: `EFQRCode.Generator` and `EFQRCode.Recognizer`. The generator accepts text/data input, encodes it using the external `QRCodeSwift` package, maps the resulting matrix through a strategy-based style hierarchy (`EFQRCodeStyleBasic`, `EFQRCodeStyleBubble`, `EFQRCodeStyleLine`, `EFQRCodeStyle25D`, `EFQRCodeStyleImage`, etc.), and produces SVG representations which are then rasterized by `SwiftDraw` into static images, PDFs, GIFs, APNGs, or AVFoundation-backed video files. The recognizer uses CoreImage-based detection with grayscale fallback and result caching. The library is heavily documented, supports iOS, macOS, tvOS, watchOS, and visionOS, and is distributed through SPM, CocoaPods, and Carthage. The `Examples/` directory contains demo apps for each platform that act as integration-style usage references, but these are example clients rather than the core deliverable. This is definitively an application/library repository; there are no data pipelines, notebooks, or research artifacts.
HealthGPT is an iOS application that enables users to interact with their Apple Health data using large language models (LLMs) in a conversational interface. Built on the Stanford Spezi modular framework, the app supports three LLM execution modes: remote OpenAI (GPT-3.5/4), on-device local models (Llama3 via MLX), and privacy-preserving fog nodes within the local network. The architecture follows a monolith application pattern with clear separation of concerns: HealthDataFetcher queries HealthKit for steps, sleep, heart rate, etc.; HealthDataInterpreter prepares the LLM context with a system prompt generated from the fetched data; and the SwiftUI ChatView manages the conversation flow. External dependencies include Spezi modules (HealthKit, LLM, Onboarding, Storage) and OpenAI API. The codebase is well-structured with SwiftLint enforcement, comprehensive UI and unit tests, CI/CD pipelines via GitHub Actions and Fastlane, and an automated TestFlight deployment workflow. While the app is tightly coupled to the iOS ecosystem and Apple HealthKit, the data fetching, prompt generation, and LLM orchestration patterns are cleanly abstracted and potentially reusable in other health-related Swift applications.
This repository contains the public-facing source code for Draw Things, a production-grade AI image and video generation application for macOS/iOS/Linux. The codebase implements a comprehensive suite of diffusion models (Stable Diffusion, FLUX, HiDream, Qwen, MiniMax, etc.), samplers, LoRA training, model conversion, and a gRPC-based distributed inference server. It is written primarily in Swift, using Bazel for builds, and includes extensive use of FlatBuffers for data serialization, SQLite for persistence, and a custom neural network compiler (NNC) for on-device inference. The architecture is modular, with separate libraries for tokenization (CLIP, Tiktoken, SentencePiece), model zoos (downloadable model specifications), image generation pipelines, and cloud authentication. The repository also includes CLI tools (draw-things-cli, gRPCServerCLI, model converters) and server management scripts for deploying GPU-backed inference services with Tailscale, Envoy, and Docker. While the core application is a consumer-facing app, the codebase also contains research-grade components such as instruction count estimators for performance profiling, formal verification tools (Z3, Lean), and web search integration with browser fallback. The code is well-structured with many reusable patterns, though it carries some maintenance overhead from vendored dependencies and generated code.
Tachikoma is a production-grade Swift SDK/library that provides a unified typed interface to a broad spectrum of LLM providers: OpenAI (Chat Completions, the newer Responses API for GPT-5+ generations, and a ChatGPT Codex OAuth backend), Anthropic (Claude with streaming signed thinking blocks), Google Gemini, Mistral, Groq, Grok/xAI, Kimi, MiniMax, OpenRouter, Together, Replicate, Ollama, LM Studio, Azure OpenAI, and arbitrary OpenAI/Anthropic-compatible endpoints. Its public surface is deliberately modeled on the Vercel AI SDK: generateText/streamText, generateObject/streamObject with partial-JSON repair, embeddings, vision analysis, and multi-step agent tool-calling loops. Beyond generation, it ships composable stop conditions, response caching, retry policies, usage/cost accounting, reasoning-effort controls, and a provider feature-parity adapter that normalizes differences in system roles, vision, and tool limits across backends. The repo is strictly an application SDK in character: no datasets, notebooks, or data pipelines. The one data-like facet is its manually curated model capability catalog (context lengths, pricing, per-generation reasoning support), which is embedded as Swift enums rather than external registries. Architecturally it is a SwiftPM monorepo of five products: Tachikoma (core generation/provider layer), TachikomaAgent (conversations, dynamic tool registry, MCP tool binding), TachikomaAudio (transcription, TTS, and an OpenAI Realtime WebSocket voice client), TachikomaMCP (a client for Model Context Protocol servers over stdio/SSE/HTTP with full JSON Schema bridging), and TachikomaConfigCLI (auth/credential helper), plus two example CLIs (ai-cli, gpt5cli). All providers implement a common ModelProvider protocol with ProviderRequest/ProviderResponse and AsyncThrowingStream-based streaming, with shared SSE/NDJSON parsing funneled through OpenAICompatibleHelper and provider-specific adapters for Anthropic, Google, and Ollama. The code is Swift 6.2, heavily async/await, and covered by a substantial test suite (Swift Testing, mock URLProtocol fixtures, snapshot tests, serialized mutex-guarded tests for shared state), with CI across macOS and Linux. The codebase exhibits strong engineering practice: clean provider abstraction, genuinely reusable utilities (stream transforms, retry policies, TTL caches, typed JSON Schema views), modular product boundaries, and disciplined error modeling. Its principal weaknesses are the enormous provider surface that must be manually maintained (hardcoded capability matrices, context-length string heuristics like isOpus48/isSonnet5, static pricing tables in ModelCostCalculator), a handful of @unchecked Sendable singletons and NSLock-guarded global state, Linux/Apple streaming divergence (Linux buffers the full response instead of streaming bytes), some dead placeholder APIs (the legacy generate() returning a mock string), and a rapid feature-churn cadence visible in the changelog (GPT-5.6/6, Claude 5, reasoning replay). These are maintainability risks more than correctness defects; the tested behavior is consistently thorough. Overall this is a high-craft SDK that an engineer building AI application features in Swift would benefit from studying, particularly its OpenAI-compatible adapter pattern, cache-key determinism, and MCP schema translation.
MuscleMap is a SwiftUI SDK for rendering interactive human body muscle maps with highlighting, heatmaps, and gesture support. It provides male and female body models in front and back views, supports tap/long-press/drag interactions, pinch-to-zoom, multi-select with undo/redo, pulse animations, and extensive localization (11 languages). Built entirely in SwiftUI with zero external dependencies, it uses SVG path parsing for precise muscle rendering and offers both SwiftUI and UIKit interfaces.
This repository is the DGCharts framework (formerly Charts), a mature, open-source charting library for Apple platforms (iOS, tvOS, macOS). It is a direct port of the popular MPAndroidChart library, providing nearly identical API for cross-platform consistency. The library offers eight primary chart types: Line, Bar, Pie, Scatter, CandleStick, Bubble, Radar, and Combined (overlaying multiple chart types). It supports rich customization including dual axes, animations, legends, highlighters, limit lines, markers, and value formatters. The codebase is structured with protocol-oriented design separating views, renderers, data models, and formatters. It includes comprehensive demo applications for iOS (Swift and Objective-C) and macOS, as well as playgrounds and snapshot-based unit tests. The library is distributed via CocoaPods, Carthage, and Swift Package Manager, and requires iOS 12+, tvOS 12+, or macOS 10.13+. While the core functionality is well-established, the codebase shows some technical debt including deprecated API methods, TODOs for Swift collection conformance, and a large number of demo controllers that duplicate boilerplate. Overall, it is a production-grade visualization library with a strong architecture and active maintenance.
PortKiller is a cross-platform desktop application for developers to monitor, manage, and kill processes listening on TCP ports. It provides a unified interface across macOS (SwiftUI), Windows (.NET 9 / WinUI 3), and Linux (Python GTK3 + Rust core) with features including real-time port scanning, process type detection, favorites and watched ports with notifications, two-stage process termination (SIGTERM → SIGKILL), Kubernetes port-forward management with auto-reconnect, and Cloudflare tunnel integration (quick and named tunnels). The application also includes an onboarding wizard, sponsor/contributor display, Sparkle-based auto-updates (macOS), and extensive keyboard shortcut support. The architecture is platform-native with shared patterns: each platform implements its own UI layer, port scanner, and process killer, while a Rust core library (`portkiller-core`) provides scanning and process termination for Linux. The macOS version uses an actor-based `PortScanner` and observable state management (`AppState`), the Windows version follows MVVM with a system tray mini-window, and the Linux version uses a GTK3 system tray indicator. All platforms share a common feature set but with varying completeness (macOS is the most feature-rich). External dependencies include `lsof`/`ss` (Linux), `kubectl`, `cloudflared`, `socat`, and system utilities for process enumeration. Key data flows: port scanning via platform-specific commands (lsof, ss, GetExtendedTcpTable) → parsing into `PortInfo` models → filtering/searching → display in tree/table views → user actions (kill, watch, favorite, forward, tunnel). Kubernetes port-forwards and Cloudflare tunnels are managed as subprocesses with monitoring loops for reconnection and log streaming. The application persists user preferences (favorites, watched ports, customizations) using platform-native storage (Defaults on macOS, JSON on Windows/Linux).
Latest is a native macOS application that aggregates and manages software updates from multiple sources: the Mac App Store (via private frameworks CommerceKit/StoreFoundation), Sparkle-based apps (by parsing appcast feeds), and Homebrew Cask (via the Homebrew API). It scans local application directories, identifies installed apps, checks for updates, and provides a unified UI to view release notes, update individual apps, or update all at once. The architecture follows a monolith pattern with clear separation: model layer (App, Update, Version), update checkers (MacAppStoreCheckerOperation, SparkleCheckerOperation, HomebrewCheckerOperation), update executors (MacAppStoreUpdateOperation, SparkleUpdateOperation), and a Cocoa-based UI with table views, search, and Touch Bar support. The codebase demonstrates solid Swift engineering with custom NSOperation subclasses, observable patterns, and a well-tested version parser. However, it relies on private macOS frameworks and has some code quality issues (forced unwraps, fatalError usage, a typo in struct name 'Sparke'). The project is actively maintained with extensive localization and community contributions.