A modern, type-safe Swift wrapper for NSUserDefaults with expressive API and compile-time checks.
SwiftyUserDefaults is a Swift library that provides a modern, type-safe wrapper around Apple's NSUserDefaults API. It solves the problem of stringly-typed keys and runtime type errors by allowing developers to define keys with associated types, enabling compile-time checks and a more expressive syntax. It extends support to custom Codable, NSCoding, and RawRepresentable types out of the box.
iOS, macOS, watchOS, and tvOS developers who use UserDefaults for lightweight persistence and want a safer, more maintainable alternative to the standard API. It's particularly valuable for Swift developers prioritizing type safety and modern language features.
Developers choose SwiftyUserDefaults because it eliminates common UserDefaults pitfalls with compile-time type checking, reduces boilerplate code with shortcuts like keyPath syntax, and supports advanced features like observation, custom serialization, and launch arguments—all while maintaining full compatibility with the underlying NSUserDefaults system.
Modern Swift API for NSUserDefaults
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses Swift generics to associate keys with specific types, eliminating runtime type mismatches and enabling early error detection, as shown in the key definition examples.
Offers expressive shortcuts like keyPath dynamicMemberLookup and property wrappers, reducing boilerplate and improving code readability, especially with Swift 5.1+.
Built-in compatibility for Codable, NSCoding, and RawRepresentable types, plus arrays and dictionaries, simplifying persistence of complex objects without extra code.
Includes KVO observation for value changes, caching via property wrappers, and type-safe launch argument handling, extending UserDefaults' utility.
For types not natively supported, developers must implement custom DefaultsBridge protocols, which the README admits can be confusing and requires boilerplate code.
Multiple migration guides (e.g., from 4.x to 5.x) indicate significant version updates that may require code adjustments, adding maintenance overhead.
Features like dynamicMemberLookup require Swift 5.1+, limiting backward compatibility and tying projects to newer Swift releases.