sorted by: new top controversial old
1
Demystifying SwiftUI’s .ignoredByLayout() — How to Apply Geometry Effects Without Breaking Your Layout (fatbobman.com)
 

Among SwiftUI’s many APIs, .ignoredByLayout() is something of an “understated member.” Information is scarce, usage scenarios are uncommon, and its very name tends to raise questions. It seems to suggest some kind of “ignoring” of the layout—but how does that differ from modifiers like offset or scaleEffect, which by default don’t affect their parent’s layout? When does ignoredByLayout actually come into play, and what exactly does it “ignore” or “hide”? In this article, we’ll lift the veil on this subtle API in SwiftUI’s layout mechanism.

1
From 180 cm to 5′ 11″ - A Complete Guide to Swift Measurement (fatbobman.com)
 

In everyday life we constantly convert values between different units of measurement. For developers this seems easy—write a few formulas, sprinkle in a couple of switch statements and you’re done. But the moment you try to support dozens of units, seamless internationalisation, formatting, precision and rounding, the workload sky-rockets and the drudgery can make you question your life choices. The good news: starting with iOS 10 Apple added a comprehensive Measurement API to Foundation, taking all that “donkey work” off our hands. This article walks you through its usage and best practices.

1
SwiftUI: Using equatable() to Avoid the NavigationLink Pre-Build Pitfall (fatbobman.com)
 

NavigationLink is a component SwiftUI developers love. By ingeniously combining the behavior of Button with navigation logic, it dramatically simplifies code. Unfortunately, in certain scenarios, using it the wrong way can create serious performance issues and make your app sluggish. This article analyzes the cause of the problem and offers a practical—albeit slightly mysterious—solution: adding the equatable() modifier to optimize performance.

1
Building Type‑Safe, High‑Performance SwiftData / Core Data Models (fatbobman.com)
 

Swift’s powerful type system empowers us to create semantically explicit and safe data models. Yet when we move to SwiftData or Core Data, the constraints of their underlying storage mechanisms often force us to compromise on type expressiveness. Those concessions blur our domain models’ intent and plant hidden seeds of instability.

This article explores how, within the restrictions of persistence layers, we can leverage ingenious type wrappers and conversions to build data models that are simultaneously Type-safe, semantically clear, and highly efficient.

view more: ‹ prev next ›