A Swift library for retrying throwing operations with configurable delay strategies and async support.
Retry is a Swift library that provides elegant retry functionality for operations that can throw errors. It allows developers to automatically retry failed operations with configurable delay strategies, making error handling more robust and resilient in Swift applications.
iOS and macOS developers building Swift applications who need reliable error recovery mechanisms for network calls, file operations, or other throwing tasks.
Developers choose Retry for its clean API, flexible retry strategies, and built-in async support that prevents UI blocking, offering a more elegant alternative to manual retry loops.
Haven't you wished for try to sometimes try a little harder? Meet retry
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Supports fixed delays, exponential backoff, and custom logic, allowing fine-tuned control over retry timing and termination, as shown in the sync retry examples with .delay and .custom strategies.
Provides retryAsync to perform retries without blocking the main thread, ensuring UI responsiveness in iOS/macOS apps, highlighted in the key features and usage warnings.
Integrates with Swift's error model using finalCatch and finalDefer blocks for comprehensive error recovery and cleanup, demonstrated in the example code with multiple retry attempts.
Allows custom strategies to stop retries based on conditions like count or logic, offering granular control over retry limits, as seen in the .custom example that returns nil to halt.
Confined to the Swift ecosystem for iOS/macOS, making it unsuitable for projects targeting other platforms or languages without Swift support, as indicated by its CocoaPods and SPM installation.
Installation via CocoaPods requires manual setup of SWIFT_VERSION and MACOSX_DEPLOYMENT_TARGET in the Podfile, adding complexity compared to plug-and-play libraries with simpler integration.
Does not include built-in handling for common network scenarios like rate limiting or transient HTTP errors, requiring additional custom code for robust API clients, despite its generic retry focus.