$ account apple
This repository is Apple's `container` tool: a Docker-compatible CLI and background service that runs Linux containers as lightweight virtual machines on Apple silicon macOS. The production system is a multi-process, XPC-based client-server architecture: a `container` CLI (ArgumentParser-based) talks to a `container-apiserver` daemon over XPC, which manages container lifecycle (create/run/exec/kill/stats), OCI image pull/push/save/load, volumes (ext4 images), networks (vmnet plugin), and machine VMs (Virtualization.framework). A plugin system registered with launchd (`container-runtime-linux`, `container-network-vmnet`, `container-core-images`, `machine-apiserver`, plus an experimental kind-like `k8s` plugin for local Kubernetes clusters) handles runtime and networking duties. Image builds are delegated to a BuildKit shim running in a Linux VM over a gRPC/protobuf protocol, with context transfer handled by a custom fssync walker.
apple/containerization is a Swift package and CLI for running Linux containers inside lightweight virtual machines. On macOS it drives Virtualization.framework; on Linux it drives Cloud Hypervisor + KVM. The public surface is the Containerization library (consumed programmatically via SwiftPM) plus the cctl command-line tool (image pull/push/save/load, login, rootfs creation, run), with vminitd as the guest-side init agent. The code defines the actual boundaries: OCI registry clients, ext4 image building, VM boot, and in-guest process supervision. The examples/ directory includes a minimal consumer (ctr-example) and a full application (sandboxy) that runs AI coding agents in sandboxed Linux VMs, but the repo itself is a container-runtime framework, not an AI product. Architecture is a multi-module SwiftPM package. Containerization defines the core protocols (Container, VirtualMachineManager, VirtualMachineInstance, Network, Mount, Kernel) with macOS VZ and Linux Cloud Hypervisor implementations; ContainerizationOCI implements the OCI image spec and a full registry client (token auth, realm validation, referrers API, push/pull/catalog) over content-addressed, digest-verified storage; ContainerizationOS provides syscall wrappers, TOCTOU-safe fd-relative filesystem operations, sockets, PTYs, and process reaping; ContainerizationEXT4 is a hand-written ext4 formatter/reader that creates root filesystems and unpacks image layers; ContainerizationNetlink handles Linux interface/route configuration; ContainerizationArchive wraps libarchive with traversal protection; CloudHypervisor is a typed REST client over Unix-domain sockets. Inside the guest, vminitd exposes a gRPC API over vsock (generated from SandboxContext.proto) and performs mounts, cgroups v2 management, process supervision, and stdio relay, launching containers via either runc or the native vmexec helper. Key data flows: images are pulled from Docker Hub/GHCR/other OCI registries through RegistryClient, validated by SHA-256 digest, stored in an ImageStore, unpacked into ext4 root filesystems, then booted as VMs with virtiofs/virtio-blk mounts, bridged TAP networking (iptables NAT on Linux, vmnet on macOS), and vsock-connected stdio. Runtime dependencies include cloud-hypervisor, virtiofsd, and runc binaries, libarchive/zstd C libraries, and a custom Linux kernel (6.18.5) built from in-repo configs. Testing is extensive: per-module unit tests using Swift Testing plus a large integration suite covering process lifecycle, TTY, seccomp, capabilities, cgroup limits, volumes, pods, and network statistics. Engineering quality is high and security-conscious: digest parsing rejects traversal digests, filesystem primitives default to not following symlinks, seccomp profiles are derived from containerd with capability gating, and registry token requests validate realms to prevent SSRF. Maintenance is active with recent commits and CI for both platforms. The main risks are breadth-driven: two VMM backends and two runtime backends (runc vs vmexec) must stay in sync, the hand-maintained ext4 and seccomp implementations must track kernel/upstream changes, and external binaries are pinned rather than auto-updated.
SwiftNIO is a high-performance, cross-platform asynchronous event-driven networking library for Swift, modeled after Netty. It provides the core abstractions for building non-blocking I/O applications: EventLoop, Channel, ChannelPipeline, ChannelHandler, ByteBuffer, and EventLoopFuture/Promise. The library includes in-tree protocol implementations for HTTP/1.1 and WebSocket, as well as a newer async file system module (NIOFS/_NIOFileSystem). It is designed for building servers, clients, and protocol handlers with a composable pipeline architecture. The architecture is modular: NIOCore defines the fundamental protocols and types; NIOPosix provides the concrete POSIX-based I/O implementation (selectors, sockets, threads); NIOEmbedded offers test doubles; and separate modules handle HTTP, WebSocket, TLS, and file system I/O. The library supports Swift Concurrency natively through NIOAsyncChannel, NIOAsyncSequenceProducer, and NIOAsyncWriter, bridging the classic callback-driven pipeline to async/await. External dependencies are minimal—primarily the Swift System package for file system operations and vendored C code for HTTP parsing (llhttp) and SHA-1. Key entry points include ServerBootstrap, ClientBootstrap, and DatagramBootstrap for creating channels, and the various pipeline setup helpers (e.g., configureHTTPServerPipeline). Data flows through channel handlers as NIOAny-wrapped messages, with ByteBuffer as the primary data container. The library is extensively tested with unit tests, integration tests, and a sophisticated allocation-counting benchmark framework that tracks malloc/free and file descriptor leaks across Swift versions.
This is the official Swift implementation of Protocol Buffers (protobuf), maintained by Apple. It provides a runtime library (`SwiftProtobuf`) for serializing and deserializing protobuf binary, JSON, and text formats, as well as a protoc plugin (`protoc-gen-swift`) that generates idiomatic Swift code from `.proto` files. The architecture is a classic library with a code generation tool: the plugin reads protobuf descriptor data (via a vendored C++ protobuf library and upb C runtime), then emits Swift source files using a visitor pattern and a custom bytecode instruction set for efficient name mapping. The runtime library uses protocol-oriented design (`Message`, `ExtensibleMessage`, `Visitor`) and supports all protobuf features including maps, oneofs, extensions, well-known types (Any, Duration, Timestamp), and editions. Key entry points are `SwiftProtobuf` (runtime) and `protoc-gen-swift` (standalone executable or SPM plugin). The build system is Swift Package Manager with CMake for vendored C++ dependencies. The repo also includes extensive fuzz testing, performance benchmarks, and compile tests for Swift language features.
This repository is a curated collection of website-specific 'quirks' (hard-coded behaviors) for password managers, maintained by Apple. It contains structured JSON datasets including password rules (to generate compatible passwords), shared credential relationships (domains that share login backends), change-password URLs, 2FA appending sites, and web browser extension distribution information. The repo also includes reference implementations: a Password Rules language parser (JavaScript) and a regex-to-Password-Rules converter, along with validation and formatting scripts. While primarily a data curation project, the tools are reusable components for any password manager implementation. The data is validated against JSON schemas and linted in CI, ensuring high quality. The repository is actively maintained with frequent contributions from the community.
This repository (apple/swift-collections) is a pure Swift library providing high-performance, specialized data structures that extend the Swift standard library. It includes stable modules like DequeModule (ring-buffer deque), OrderedCollections (ordered set/dictionary), HeapModule (min-max heap), BitCollections (BitSet/BitArray), and HashTreeCollections (persistent hash-array mapped trie TreeSet/TreeDictionary). It also contains experimental preview modules (e.g., SortedCollections using B-trees, RopeModule for rope-based BigString, and BasicContainers with non-copyable collections). The code is heavily optimized with copy-on-write, unsafe pointer usage, and advanced Swift ownership features. It is designed for production use with source stability guarantees, while preview modules are explicitly unstable. The library is consumed as a Swift package and integrates seamlessly with standard collection protocols.
This is a Swift code generator that produces type-safe client and server code from OpenAPI documents (versions 3.0, 3.1, and preliminary 3.2). It is distributed as a Swift Package Manager build plugin, a command plugin, and a standalone CLI tool (`swift-openapi-generator`). The core architecture follows a pipeline: parse the OpenAPI document using YamsParser, translate the parsed representation into a structured Swift intermediate representation (IR) via a multiplex translator, and render the IR into Swift source files using a text-based renderer. The generated code is decoupled from specific HTTP transport libraries via `ClientTransport` and `ServerTransport` protocols, and supports middleware for cross-cutting concerns like logging, authentication, retrying, metrics, and tracing. The repository includes extensive examples covering a wide range of use cases: basic clients and servers, event streaming, multipart content, database integrations, and middleware stacks. The test suite is comprehensive, including unit tests, golden-file reference tests, and integration tests that compile and run generated code against mock transports. The project is actively maintained with a proposal process (SOAR) for feature additions and has a well-documented ecosystem of separate runtime and transport libraries.
SimpleFold is a research repository focused on protein structure prediction using flow-matching generative models. While it includes application-like features such as a CLI and inference scripts, its core architecture is designed for ML research, specifically training and evaluating large-scale diffusion transformers (FoldingDiT) on structural biology data. The codebase is hybrid in nature, combining rigorous data engineering pipelines (parsing MMCIF, filtering, tokenization) with standard deep learning frameworks (PyTorch Lightning, Hydra). It supports dual backends (PyTorch and MLX) for inference, indicating a focus on accessibility across hardware platforms. The repository's primary value lies in its data processing pipeline, which is heavily adapted from the Boltz-1 project. It handles complex structural data (PDB, SwissProt, AFESM) through a modular pipeline including parsing, filtering, and tokenization. The model architecture implements flow-matching with ESM-2 embeddings for sequence context. Evaluation metrics include pLDDT confidence, TM-score, and RMSD, typical for structural biology research. However, the codebase exhibits signs of research-to-production transition challenges. Hardcoded paths (e.g., `/mnt/task_runtime/...`) and reliance on external binaries (TMscore, OpenStructure) reduce portability. The data pipeline is a fork of an external project (`boltz`), introducing maintenance overhead for divergence. Despite these issues, the use of Hydra for configuration management and PyTorch Lightning for training orchestration demonstrates solid engineering practices for an ML research project.
SwiftNIO HTTP/2 is a Swift library providing HTTP/2 protocol support for SwiftNIO-based applications. It implements the HTTP/2 specification (RFC 7540) and HPACK header compression (RFC 7541) in pure Swift, with no external dependencies beyond SwiftNIO core. The library features a modular architecture separating frame handling, connection state management, stream multiplexing, and header compression. Key components include a connection state machine for managing HTTP/2 connection lifecycle, stream multiplexing logic for creating child channels per HTTP/2 stream, and an HPACK implementation with Huffman coding. The repository includes extensive unit tests, integration tests, performance benchmarks, and fuzz testing to ensure correctness and performance.