When Array Isn’t Enough Most production Swift code leans heavily on Array, Set, and Dictionary. They’re fast, battle-tested, and cover the vast majority of use cases. But every so often you run into a data structure that doesn’t map cleanly onto these defaults. Maybe you need a ring buffer for a real-time audio pipeline, a
Sometimes an array is almost right—except you need every element to be unique. Or a dictionary would work, if only it remembered the order you added things. The Swift standard library doesn’t hand you a finished type for those moments. It gives you a set of protocols you can stitch together yourself. Custom collections let
Swift’s standard library hands you Array, Set, and Dictionary—solid workhorses that cover most day-to-day needs. But the moment you reach for a ring buffer, a sorted bag, or a lazy evaluation pipeline, you’re staring down the barrel of a custom collection. A custom Swift collection is any type that conforms to the Collection protocol, inherits
Why Build Your Own Collection? Swift’s Array, Set, and Dictionary are workhorses. They’re fast, well-tested, and handle the vast majority of data storage tasks you’ll encounter. But sometimes, a general-purpose container doesn’t quite fit. Maybe you need a fixed-size window that automatically discards old data, or a structure that enforces strict ordering rules at the
You reach for Array, Set, and Dictionary without thinking. They’re the workhorses. But then you hit a data model that doesn’t slot into those shapes—maybe you’re wrapping a C pointer, juggling a sparse bitmap, or exposing a virtual view over a remote API. That’s when building a custom Swift collection stops being a theoretical detour
Every Swift developer has written a generic function, added @inlinable, or used a protocol witness, and then wondered: did the compiler actually do what I expected? Did it specialize the generic? Did it devirtualize the call? Did it eliminate the retain cycle I suspect is there? The Swift compiler’s intermediate representationâSIL, or Swift Intermediate Languageâis
Swift’s standard library gives you Array, Set, and Dictionary right out of the box. They’re fast, well-tested, and handle most day-to-day tasks. But sometimes you hit a wall—maybe you need a fixed-capacity ring buffer for real-time audio, or a data structure that keeps elements in a specific order without the overhead of a full sort.
Swift property wrappers landed in Swift 5.1 with a clean promise: take repetitive property logic and package it into a reusable component. A @UserDefault wrapper reads and writes to UserDefaults. @Clamped keeps a number inside a range. @Trimmed strips whitespace from a string. The idea is sound. But in the years since, I’ve watched codebases
The Allure of Syntactic Sugar Swift property wrappers, introduced in Swift 5.1, are a clever bit of engineering. They let you abstract common property logic—like validation, persistence, or transformation—into a reusable component. Just slap @Clamped on a variable and its value stays within bounds. Use @UserDefault and your property syncs automatically with UserDefaults. It’s a
I still remember the first time I saw a Swift property wrapper in action. It was a neat little @UserDefault annotation that turned a tedious UserDefaults dance into a single line. The code looked cleaner, the intent was obvious, and I thought: this is the future of state management. That was 2019. Today, I spend
