A Swift library providing a type-safe percentage type with operator support and SwiftUI/Cocoa overloads.
Percentage is a Swift library that provides a dedicated Percentage type to make percentages more readable and type-safe in Swift code. It replaces error-prone fraction Double values with clear percentage literals and provides comprehensive arithmetic and utility functions, eliminating ambiguity when working with percentages.
Swift developers building iOS, macOS, or other Apple platform applications who need to handle percentages in their code, particularly those using SwiftUI or Cocoa APIs that accept opacity, brightness, or similar parameters.
Developers choose Percentage over manual Double handling because it offers a first-class, type-safe percentage type with operator support, SwiftUI/Cocoa overloads, and utility methods, which enhances code clarity and reduces bugs related to fraction-percentage confusion.
A percentage type for Swift
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Replaces error-prone Double fractions with a dedicated Percentage type and clear literals like 45%, reducing bugs from fraction-percentage confusion, as highlighted in the README's philosophy.
Supports arithmetic operators (+, -, *, /) and conforms to Hashable, Codable, and other protocols, enabling seamless integration and operations, as shown in usage examples.
Overloads common APIs like opacity and brightness to accept percentages directly, simplifying UI code without manual conversion, demonstrated in the SwiftUI/Cocoa overloads section.
Includes methods for calculating percentages of values, clamping ranges, locale-aware formatting, and computing original values before changes, providing robust functionality beyond basic types.
Only supports Swift Package Manager, with no Carthage or CocoaPods support, which can alienate teams invested in alternative package managers, as admitted in the FAQ.
For projects with infrequent percentage calculations, the additional type and dependency might not justify the benefits, introducing complexity where raw Doubles would suffice.
Using a custom type instead of raw Doubles could introduce minor overhead in performance-critical sections, though not explicitly measured, it's a consideration for high-frequency calculations.