Aswifter — Where Technology Meets Perspective Deep dives into software, hardware, and the ideas changing how we build things. Browse Latest Posts We cover the technical side of technology — not just the product launches and press releases, but the architecture decisions, the tradeoffs, and the engineering culture that shapes what gets built. Ou… Topics
The Performance Regression You Didn’t Profile For Last quarter, a team I was advising shipped what looked like an innocent feature: a local cache of Document structs, each containing an array of Section structs, each containing an array of Paragraph structs. Three layers of value types, each with its own Array storage. The team assumed
Profiling a Swift app means measuring where your code actually spends time, memory, energy, and I/O, then using that evidence to make targeted changes. It sits next to related disciplines like benchmarking, tracing, and performance regression testing. If you ship production iOS, macOS, watchOS, or tvOS apps, profiling isn’t a final polish step. It’s how
Swift’s structured concurrency model arrived with Swift 5.5 and got sharper in Swift 6. It gives Apple platform engineers a way to write asynchronous code that reads almost like synchronous code. The main pieces are async/await, task groups, child tasks, and actors. They sit alongside older tools like DispatchQueue, OperationQueue, and completion-handler APIs. The pitch
Swift enums with associated values are the language’s most distinctive modeling tool. They can carry per-case payloads, conform to protocols, and participate in exhaustive pattern matching — none of which C or Java enums can do. Used well, they replace entire class hierarchies and give you compile-time guarantees that no state goes unhandled. Used poorly,
Swift error propagation is how a function says, “I can’t finish this,” and hands the failure to a caller that might actually be able to do something about it. It sits alongside optionals, assertions, and preconditions in Swift’s failure-handling toolbox, but it’s the only one built for recoverable, expected failures that cross API boundaries. For
Most Swift developers get comfortable with throws early on. It’s a clean, familiar way to bail out when something goes wrong. But in a real, production-scale app, error propagation is less about marking a function and more about a series of deliberate choices. How you model, map, and handle failures shapes everything from your app’s
Error propagation in Swift isn’t just a language feature you tack on at the end. It’s a design decision that shapes your entire API surface, threading model, and even how your app recovers—or doesn’t—in the field. Between throws, Result, typed throws, and the occasional deliberate try!, you’ve got a lot of tools. The trick is
Most Swift developers operate on a simple mental model: structs get copied, classes get referenced, the compiler handles the rest. That model has held up since Swift 1.0 — mostly. But SE-0377 and SE-0395 introduce borrowing and consuming parameter ownership modifiers, and the model no longer holds without qualification. These keywords aren’t ergonomic shortcuts. They
Swift’s standard library gives you Array, Set, Dictionary, and their lazy or slice variants. They’re solid. But production apps have a way of outgrowing them. Maybe you need a ring buffer for a real‑time audio pipeline, an ordered set that remembers insertion order while blocking duplicates, or a sparse grid that doesn’t burn memory on
Why Build a Custom Collection in Swift? A custom Swift collection is any type that conforms to the Collection protocol, giving it first-class access to iteration, subscripting, and dozens of standard library algorithms. For professional developers working on iOS, macOS, watchOS, or tvOS apps, rolling your own collection isn’t about reinventing Array—it’s about modeling domain-specific
