FabrizioBrancati/Queuer

Queuer is a Swift library that provides concurrency primitives for managing asynchronous operations on multi-platform systems. It offers a queue-based API with support for pausing, resuming, and canceling tasks, along with automatic retry logic and grouping capabilities. The system is designed for strict concurrency safety and includes comprehensive testing across various operating systems.

The Sources/Queuer module now provides a new concurrency framework centered on the Queuer class, which wraps an OperationQueue and exposes methods for pausing, resuming, and canceling operations. It introduces ConcurrentOperation and AsyncConcurrentOperation classes that support pause/resume states, manual or automatic retry logic with configurable delays, and custom pause/resume/cancel callbacks. GroupOperation allows bundling multiple operations into a single unit that can be canceled, paused, or resumed as a whole. The Queuer API also includes syntactic sugar methods for chaining operations, adding barriers, and performing async waits, along with supporting structs like Scheduler (for timer-based scheduling) and Semaphore (for thread synchronization).

Sources · high confidence

Queuer has been updated to version 4.0.0, introducing support for the Swift 6 language mode with strict concurrency enabled by default. This release adds \AsyncConcurrentOperation\ for async/await-based tasks with automatic retries and cooperative cancellation, along with new queue methods like \addBarrier\, \asyncWait\, and \syncWait\. The library now officially supports Linux, Android, and Windows, and ships a dedicated \[e-mail redacted]\ manifest to ensure compatibility with Swift 5.9 and 5.10 while enabling Swift 6 features. Additionally, the project has migrated its test suite to include Swift Testing alongside XCTest, and integrated pre-commit hooks and swift-format for consistent code quality.

(repo-wide) · high confidence

Added comprehensive XCTest suite for Queuer operations and concurrency; Initial test suite for Queuer operations and utilities.

The project now requires Swift 5.9 and has updated the swift-docc-plugin dependency to version 1.5.0 (migrating from the apple/swift-docc-plugin repository to swiftlang/swift-docc-plugin). Additionally, Strict Concurrency is explicitly enabled for the Queuer target, and the package now supports visionOS v1 alongside existing iOS, macOS, macCatalyst, tvOS, and watchOS platforms.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 68 → 70 (+1.7)
• Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.

• Code Health 99 → 99 (+0.0)
• Architecture 70 → 93 (+22.7)
• Maturity 55 → 55 (+0.0)
• Readiness 77 → 71 (-5.9)
• Security 92 → 92 (+0.0)

• Dependency hygiene PARTLY measured — SwiftPM pinning read, dependency currency NOT established
• Documentation: no contributor guidance (README.md)
• Documentation: no usage examples (README.md)
• Hotspot: Sources/Queuer/AsyncConcurrentOperation.swift (Sources/Queuer/AsyncConcurrentOperation.swift)

• Duplicate intent across sibling types. Both Async and Concurrent operations expose an identical 'retry()' method. While the underlying implementation differs (async vs sync), the public API surface is identical, which is acceptable, BUT combined with 'manualRetry' property, it creates confusion: should the user call 'retry()' or set 'manualRetry = true' and let the system handle it? The API doesn't clearly distinguish between automatic retry logic and manual intervention.
• Inconsistent abstraction levels. The API allows adding raw closures directly to the queue alongside explicit Operation objects. This bypasses the 'AsyncConcurrentOperation' or 'ConcurrentOperation' wrappers, leading to inconsistent handling of lifecycle events (pause, resume, cancel, retry) for closure-based tasks versus object-based tasks.
• Naming and signature inconsistency. 'addChainedOperations' has two overloads (array vs single) which is acceptable, but 'addChainedAsyncOperations' is a separate method name for async completion. This forces users to choose between method names based on the completion handler's signature rather than the operation type. It also implies that 'addChainedOperations' only supports synchronous completion, which is a confusing constraint.
• Redundant lifecycle methods. In standard Operation patterns, 'start' initiates execution. Having both 'start' and 'execute' suggests ambiguity about which method triggers the actual work or if they are interchangeable aliases.

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

FabrizioBrancati/Queuer was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.