Alamofire is a mature, production-grade HTTP networking library for Apple platforms (iOS, macOS, tvOS, watchOS, visionOS). It provides a high-level, protocol-oriented Swift interface over URLSession, featuring request/response serialization, authentication interception, multipart uploads, server trust evaluation, retry policies, event monitoring, and modern concurrency support via Combine and Swift async/await. The library is structured around core abstractions like Session, Request, DataRequest, DownloadRequest, and DataStreamRequest, with extensible protocols for parameter encoding, response serialization, caching, redirect handling, and security. Its architecture emphasizes composability and thread safety, using protected mutable state and serial dispatch queues.
Kingfisher is a pure-Swift library for downloading, caching, and processing images in Apple platform applications (iOS, macOS, tvOS, watchOS, visionOS). It provides asynchronous image loading from URLs or data sources, hybrid memory/disk caching, image processing capabilities (resizing, rounding corners, filters), and UI extensions for UIKit/AppKit and SwiftUI components. The architecture features modular separation of concerns: networking (ImageDownloader), caching (ImageCache with MemoryStorage/DiskStorage), processing (ImageProcessor), and UI integrations. Key entry points include UIImageView.kf extensions, KFImage SwiftUI view, and KingfisherManager.shared for programmatic control. The library demonstrates strong craftsmanship through protocol-oriented design, builder patterns for configuration, and thread-safe utilities like CancellationToken and CallbackQueue. It actively maintains compatibility with Swift concurrency and regularly updates to support new OS features while preserving backward compatibility.
This repository is a production-grade Go CLI tool (`asc`) that automates the full Apple App Store Connect lifecycle: app management, builds, TestFlight distribution, metadata, screenshots, code signing, pricing, subscriptions, in-app purchases, Game Center, analytics, Apple Ads campaigns, StoreKit server APIs, and Xcode Cloud workflows. It is built on the `ffcli` command framework with a deep subcommand tree (hundreds of commands), uniform output rendering (JSON/table/markdown), structured diagnostic error codes, JWT-based API authentication, and a telemetry subsystem with opt-out. The architecture is cleanly layered: `internal/asc` provides the App Store Connect API client with generic pagination, retry, polling, and upload logic; `internal/cli` contains domain-organized command implementations sharing common flag-binding, output, and validation helpers; `internal/validation` implements a pre-submission readiness engine; and platform-specific packages (`internal/secureopen`, `internal/rootfs`, `internal/xcode`) handle secure file operations and macOS-only features with build-tag isolation. The codebase demonstrates unusually high engineering discipline for a developer tool: extensive black-box and integration tests (over 1,000 test files), security-conscious file operations (O_NOFOLLOW, atomic rename, symlink rejection), credential redaction in errors and logs, URL sanitization for signed query parameters, and a lazy output registry that defers renderer registration. It also reverse-engineers several undocumented Apple web endpoints (`internal/web`) for features like deep validation and subscription pricing, which introduces drift risk but is handled with defensive fallbacks. The tool is actively maintained with dependabot, CodeQL, govulncheck, and release-rehearsal workflows. Notable maintenance concerns are the large deprecated-command alias surface (API 4.4.1 migrations) and the reliance on AppleScript for 2FA capture, but these are contained and documented.
XcodesApp is a native macOS SwiftUI application for discovering, downloading, installing, selecting, and uninstalling multiple versions of Apple's Xcode, including management of the iOS simulator runtimes that ship with them. The app surfaces a list of available Xcode versions (from the Xcode Releases API or the Apple Developer portal), drives the full install pipeline (download via URLSession or the bundled aria2c, verify code signature, unxip archive, move into /Applications, run elevated post-install steps), switches the active developer directory, and supports Apple ID sign-in with 2FA, SMS, security keys, and federated authentication. This repository is the app shell and privileged-helper layer; core domain logic and authentication live in the separate XcodesKit and XcodesLoginKit packages. The architecture is a clean three-part split. Xcodes/Backend holds a central observable AppState coordinator and small subsystems (downloader, helper client, process runner, dependency-injection environment); Xcodes/Frontend is a SwiftUI view layer organized into list, info pane, sign-in, and preferences modules; com.xcodesorg.xcodesapp.Helper is a separate privileged XPC service installed via SMJobBless, with peer connections verified by code-signing designated requirements and audit-token comparison before any xcode-select, license-accept, or file-operation work is performed. Update delivery uses Sparkle with a Jekyll-generated appcast hosted on GitHub Pages. The codebase is well engineered for a GUI app: the Environment/Current dependency-injection seam makes nearly all side effects mockable, and the test suite is unusually thorough, covering SRP authentication vectors from real Apple ID sessions, stale-async-task race conditions, new-version notifications, and download/install state transitions. The main weaknesses are the reliance on the private NSXPCConnection.auditToken API, several SPM dependencies pinned to main branches, some duplicated view helpers and stale branding text (RobotsAndPencils references, a hardcoded WWDC 2022 status message), and a manual multi-step release process. Maintenance is active: recent commits, CI running on the latest macOS/Xcode runners, Dependabot config, release-drafter workflow, and xcstrings localization validation. Technical drift is low — the code aggressively tracks current Apple platforms (macOS 26 branches, Xcode 26.5 CI), though the private-API usage and main-branch dependency pins remain chronic medium-term risks.
Xcodes is a command-line tool for installing, managing, and switching between multiple versions of Apple's Xcode IDE. It provides subcommands for downloading, listing, selecting, uninstalling, and updating Xcode releases, as well as managing simulator runtimes. The tool supports two data sources: scraping Apple's Developer downloads page (the 'apple' source) and consuming the unofficial Xcode Releases JSON feed ('xcodeReleases'). Authentication is handled through Apple ID with two-factor or SMS fallback, or via fastlane session cookies. The architecture is a modular Swift Package Manager project with a thin CLI entry point (using Apple's ArgumentParser) and a core library (XcodesKit) that encapsulates all business logic. The core library uses a lightweight dependency injection pattern via an Environment struct, a strategy pattern for downloads (URLSession or aria2), and a service-oriented design for runtime installation, list management, and system configuration. The codebase exhibits strong Swift concurrency adoption and includes test fixtures for parsing Apple HTML and property-list data. While the Apple scraping approach is inherently fragile, the overall architecture is well-structured, testable, and follows modern Swift best practices.
Prefire is a Swift developer tool that scans SwiftUI source files, extracts `#Preview` macros and `PreviewProvider` declarations, and generates automated snapshot tests plus an interactive "Playbook" component catalog. It is not a data project: it is a CLI/code generator with a runtime library and SwiftPM/Xcode build-tool plugins. The real pipeline is: a build plugin invokes the `prefire` binary with target/source/config arguments; the binary parses sources using SwiftSyntax for `#Preview` macro ranges and a Sourcery fork for `PreviewProvider` types; a fingerprint-based cache avoids re-parsing unchanged files; Stencil templates (one for snapshot tests, one for playbook models) render generated Swift code; snapshot tests run against swift-snapshot-testing and the bundled Prefire runtime, while `PlaybookView` renders the generated `PreviewModels` inside an app.
MonitorControl is a macOS menu-bar utility that controls external displays' brightness, contrast, and volume. It does not just send one kind of command; it uses multiple control paths: hardware DDC/CI over IOKit I2C on Intel Macs, DDC/CI over IOAVService on Apple Silicon, Apple's private DisplayServices API for Apple/Thunderbolt displays, gamma-ramp adjustments for software dimming, and transparent shade windows for virtual displays. User input flows from native media keys, custom keyboard shortcuts, and menu-bar sliders into a DisplayManager singleton, which coordinates native OSD overlays, smooth brightness transitions, and cross-display synchronization. The app uses Sparkle for updates, SimplyCoreAudio for audio device handling, MediaKeyTap for media-key interception, and KeyboardShortcuts for user-defined bindings. Architecturally, this is a classic Cocoa application with a storyboard-based preferences UI, a login helper app (MonitorControlHelper), and a clean separation between models (Display, AppleDisplay, OtherDisplay), support services (DisplayManager, DDC backends, OSD utilities, media-key handling), and view controllers for preferences and onboarding. Entry points are main.swift, AppDelegate, DisplayManager, and MenuHandler. Persistence is UserDefaults backed through a PrefKey enum, and the UI is localized into 19 languages. There is no data/research component; this is purely an end-user utility. The codebase is modular and well organized, with the DDC communication isolated into Intel and ARM backends and display-specific logic abstracted behind a base Display class. It is actively maintained, with recent commits and a modern dependency setup. Technical drift is medium rather than low because much of the functionality depends on private or undocumented macOS APIs (DisplayServices, CoreDisplay, OSDUIHelper) and the code contains many macOS-version-specific workarounds, but the project tracks current macOS releases and continues to update its fallbacks.
XcodeGen is a command-line tool written in Swift that generates Xcode project files (.xcodeproj) from a declarative YAML or JSON specification (typically project.yml). It eliminates the need to manually manage Xcode project files by deriving the project structure from the filesystem and a concise spec, supporting all major Apple platforms (iOS, macOS, tvOS, watchOS, visionOS) and a wide range of product types including applications, frameworks, libraries, extensions, App Clips, and more. The tool integrates with Swift Package Manager, Carthage, and CocoaPods, and can generate schemes, breakpoints, Info.plist files, and build settings from layered presets. The architecture is modular: the ProjectSpec module defines the domain models and parsing logic for the spec format; XcodeGenKit contains the core generation logic (PBXProj generation, scheme generation, source file organization, settings resolution); XcodeGenCLI provides the command-line interface using SwiftCLI; and XcodeGenCore offers utility components like globbing, atomic properties, and path extensions. The tool is designed for automation and CI workflows, with caching support and pre/post generation commands. The codebase is well-structured with clear separation of concerns, extensive test coverage (unit tests, fixture-based golden tests, performance tests), and active maintenance. It demonstrates strong Swift engineering practices including protocol-oriented design, value types, and functional patterns. While the project is mature and widely adopted (over 8,800 stars), some areas like test fixtures are large and tightly coupled to specific Xcode versions, requiring periodic updates.
SimUtil is a Dart-based terminal UI/CLI for managing iOS simulators and Xcode Derived Data. It wraps `xcrun simctl` to list, boot, shut down, install, launch, and interact with simulator devices, and adds conveniences like showing/cleaning Derived Data. The app is operated entirely from the terminal and stores user preferences in `~/.simutil/settings.yaml`, including a `plugins:` section for custom commands. Architecturally it separates terminal UI components (`lib/components`) from services (`lib/services`) such as `CommandExec` (a shell-command abstraction), `UserConfig` (YAML settings with first-run defaults and scalar merge), and Derived Data helpers. A `tool/generate_changelog.dart` code generator parses `CHANGELOG.md` and emits typed Dart data so the app can show post-update changelog dialogs. Tests cover the changelog generator and config file behavior, and CI runs build/install verification across platforms.
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.
Copilot for Xcode is a macOS application that integrates multiple AI code completion and chat services (GitHub Copilot, Codeium, OpenAI, Claude, Google Gemini, Ollama) directly into Xcode as a source editor extension. It provides inline code suggestions, a chat panel with context-aware memory, a prompt-to-code feature, and custom command execution. The architecture is a multi-process system: a host app manages settings and lifecycle, an XPC extension service handles AI requests and workspace state, and an Accessibility-powered widget overlays suggestion and chat panels on Xcode windows. The codebase is heavily modularized into Swift packages (Core, Tool, OverlayWindow) and uses the Composable Architecture (TCA) for state management. While primarily an application, it includes data-centric components like embedding services, vector stores (USearch), and a LangChain-inspired chain abstraction for retrieval-augmented generation, giving it a hybrid character.
This repository is an educational companion to the book 'Programming with 64-Bit ARM Assembly Language', adapted for Apple Silicon (ARM64 macOS, iOS, watchOS, tvOS). It contains 16 chapters of progressively complex assembly examples, covering system calls, memory addressing, functions, floating-point, NEON, and optimization. The code demonstrates key differences between Linux and Darwin (Apple) ABIs, such as syscall numbers, addressing modes (ADRP/ADD vs LDR =symbol), and variadic function calling conventions. It includes reusable debug macros (printReg, printStr) for register inspection, file I/O macros, and a toupper function callable from C, Python, and Swift. The project also features an Xcode SwiftUI app that integrates assembly code across multiple Apple platforms. The repository is well-maintained and actively used as a reference for Apple Silicon assembly development.
xtool is a cross-platform CLI tool and Swift library that enables building, signing, and deploying iOS applications without requiring Xcode. It serves as a replacement for Xcode's build-and-deploy pipeline, supporting macOS and Linux (via Docker). The core library, XKit, provides modules for interacting with Apple Developer Services (certificates, provisioning profiles, devices), implementing Apple's GrandSlam authentication protocol (including Anisette data), code signing via zsign, and device installation via libimobiledevice. The tool also includes a packaging subsystem (PackLib) that resolves SwiftPM dependencies, builds the app, signs it, and bundles it into an .app or .ipa. It supports both free and paid developer accounts and can automatically manage capabilities and provisioning profiles. The architecture is modular, with clear separation between CLI commands (XToolSupport), core library (XKit), and packaging logic (PackLib). It uses modern Swift concurrency (async/await, actors) and dependency injection via swift-dependencies. The codebase includes generated OpenAPI client for Apple's REST API, cross-platform HTTP client abstraction, and utilities for ZIP compression, temporary files, and key-value storage. Examples and integration tests verify functionality. While primarily a developer tool for side-loading and CI/CD for iOS apps, it also exposes the underlying libraries as SwiftPM dependencies for programmatic use. The codebase demonstrates good engineering practices with protocol-oriented design, clean abstractions, and testability. However, it relies on private Apple APIs and a large number of external dependencies, which introduce maintenance risks. The generated OpenAPI client and platform-specific device interactions add fragility, but the core patterns are well-implemented.
GENie is a build system generator that creates native project files (Makefile, Visual Studio, Xcode, Ninja, etc.) from Lua-based project descriptions. It embeds Lua 5.3.0 as its scripting engine and uses a hierarchical configuration system (solution/project/platform/configuration) to manage build settings. The tool processes user-defined Lua scripts (typically premake4.lua) to generate tool-specific build files through registered actions. Architecture consists of a C host layer handling platform abstractions, Lua modules for core functionality (solution/project/config management, action/option system), toolchain-specific compilers/linkers, and generator actions for each build system. Key entry points are src/host/premake_main.c (main) and the embedded Lua API. Data flow involves: CLI args → Lua state initialization → user script execution → action-specific file generation. External dependencies are limited to system libc and platform APIs; Lua is fully embedded.
This repository is a collection of iOS application projects that recreate various UI designs from sources like Instagram, Dribbble, and Facebook. Each project is a self-contained iOS app implemented in either Swift (UIKit) or SwiftUI, demonstrating how to translate specific designs into functional code. The repository serves as an educational resource for iOS developers looking to learn practical UI implementation techniques. The project follows a clear organizational structure where each episode resides in its own folder containing a downloadable ZIP file with the complete source code. Projects cover a wide range of UI concepts including onboarding flows, social media interfaces, messaging apps, music players, and more. Both UIKit and SwiftUI implementations are showcased, reflecting the evolution of iOS development practices. While the actual implementation details are contained within the ZIP archives and cannot be directly inspected in this repository view, the consistent naming convention, clear documentation in README.md, and regular maintenance indicate a well-organized educational resource. The repository appears to be actively maintained with recent commits and covers contemporary iOS development topics.
Chisel is a collection of LLDB commands for debugging iOS and macOS applications. It provides a rich set of commands to inspect and manipulate the UI hierarchy, view controllers, accessibility, auto layout, animations, and memory. The project consists of Python scripts that define LLDB commands using a custom base class (FBCommand) and a native C/Objective-C framework (Chisel.framework) that enables heap scanning for Objective-C instances. The Python layer evaluates Objective-C expressions in the debugged process, while the native framework uses malloc zone enumeration to find live objects. The architecture is a plugin for LLDB, with commands loaded dynamically from a directory. Key entry points are the LLDB commands themselves (e.g., pviews, pvc, visualize, border, findinstances). External dependencies include LLDB, the iOS/OS X runtime, UIKit, CoreAnimation, and Foundation. The codebase is well-structured but shows some technical drift (Python 2 usage, deprecated imp module, old Xcode project settings).
InjectionIII is a macOS menu bar application that enables hot reloading of Swift, Objective-C, and C++ code in iOS simulators and devices. It works by watching for source file changes, recompiling them using Xcode build logs, and dynamically loading the resulting dylib into the running app using techniques like interposing, vtable patching, and Objective-C swizzling. The app consists of a daemon with a file watcher and injection server, while the client-side code (bundled as injection bundles or via the HotReloading Swift package) handles compilation and injection. It supports standalone injection without the app running, injection on real devices, and integration with SwiftUI. The codebase is mature and actively maintained, though it contains legacy C/ObjC components and is tightly coupled to Xcode build log parsing.
Clipy is a macOS clipboard extension app that lives in the menu bar. It provides clipboard history management, text snippet storage and quick paste, OCR for image-based clipboard content, and customizable global hotkeys to trigger history menu, snippet editor, or paste actions. The app monitors NSPasteboard using a timer, deduplicates entries, and stores them in a local SQLite database (via GRDB wrapper SQLiteData), with a legacy Realm database still present for migration. UI is built with a mix of SwiftUI (settings panes) and AppKit (snippet editor, menu). Dependency injection via swift-dependencies and reactive storage via swift-sharing are used throughout. The architecture is well-modularized with repository and service layers, extensive unit tests, and a migration system for both database schema and user defaults. However, the project shows signs of drift: legacy Realm code and XIB files persist, localization strings may be out of sync, and the last commit date is anomalous (future date) suggesting the project may be unmaintained despite a large user base.
This repository is a documentation-only collection of Apple Xcode user defaults (`defaults write` commands) and related shell one-liners. It contains no application code, libraries, tests, or executable entry points; the only substantive content is a large README that catalogs tweaks for Xcode's build system, Swift compiler parallelism, indexing, logging, simulator behavior, derived data cleanup, and related developer-experience settings. The README is organized by topic and cites sources for many of the tips, making it a curated cheat sheet rather than a software product. Because there is no codebase, there is no runtime architecture, API, or data flow. The repository's practical value is as a reference for iOS/macOS developers who want to tune Xcode behavior by copying commands into Terminal. The included GitHub Actions workflow only checks markdown links, and the renovate configuration manages dependency updates for a repository that has no actual dependencies. The CC BY-ND 4.0 license permits sharing with attribution but prohibits derivative works, which may limit how freely the curated content can be reused in other projects or tools.