Snapp Technology
Hi folks,
This week marks our 100th edition and is all about stopping the fight with SwiftUI. Whether it’s finally getting a handle on those annoying re-renders by swapping closure bindings for subscripts, or actually following Apple’s advice to split views into structs instead of computed properties, we’re moving toward a world where our code actually matches how the framework thinks. Throw in some Swift 6 concurrency fixes for our tests and a proper way to stream observation changes, and we’ve got a lot of ground to cover to keep our apps snappy and our builds warning-free.
Have fun!
Articles
Swift
Streaming changes with Observations
The new Observations bit lets us turn observable models into async streams. No more manually triggering recursive observation or fighting with the Swift Concurrency world. It’s a clean bridge between reactive updates and for await loops that makes our UI code feel way less clunky.
UI/UX
Custom bindings in SwiftUI: closures vs subscripts
We’ve all used Binding(get:set:) and wondered why our views are re-rendering for no reason. Turns out, creating these closures in the body is a performance trap. Switching to labeled subscripts in the model gives SwiftUI a stable dependency to track and keeps our rows from flickering during unrelated state updates.
Splitting Large SwiftUI Views in the Apple’s way
Apple’s latest guidance is clear: stop using computed properties to split your views. While @ViewBuilder is great for tiny local branches, it doesn’t create a new invalidation boundary. Moving heavy sections into their own private view structs is the only real way to stop wasteful re-evaluations and actually gain some performance.
A Custom Pull-to-Refresh in SwiftUI
Sometimes .refreshable just isn’t enough when the designers want a branded, animated experience. This entry shows an approach that treats the refresh lifecycle as a state machine, giving us total control over the indicator’s progress and animations. It’s a solid blueprint for anyone who’s tired of the generic system spinner.
Little SwiftUI Tip: Get & Set & Watch Interface Orientation & Orientation Lock
Tracking interface orientation in SwiftUI is surprisingly annoying since it’s not in the environment. Using KVO on effectiveGeometry is the way to go to keep our UI in sync. It’s a bit of a workaround, but it’s the most reliable way to handle orientation locks and rotations without fighting the framework.
How to mark content as private using privacySensitive()
With privacySensitive(), we can finally tell SwiftUI which parts of our views should be hidden on the lock screen or in widgets. Pair it with .redacted(reason: .privacy) to easily mask out credit card numbers or personal info. It’s a small but essential tool for keeping our users’ data safe by default.
Testing
XCTest Meets @MainActor: How to Fix Strict Concurrency Warnings
Flipping the switch to Strict Concurrency in Swift 6 turns our test suites into a sea of warnings. The fix is simpler than it looks: mark the test class as @MainActor and switch to the async throws versions of setUp and tearDown. It’s the quickest path to a clean build without abandoning XCTest.
Talk
SwiftUI is functional
A deep dive into why SwiftUI’s declarative nature is actually a functional programming win. It’s not just about the syntax; it’s about how the render tree and observation framework reconcile state. For those of us coming from a more OO background, it’s a great reminder of why the MVU pattern scales so much better for modern UIs.