Issue #60

Welcome to the 60th edition of iOS Code Review, just in time for the winter season! It's been an incredible journey through 60 issues, and I'm grateful for your continued support. Thank you for being part of the iOS Code Review community! Here's to another 60 issues of learning, sharing, and exploring the ever-evolving landscape of iOS development☕️

I'm excited to bring you another curated selection of learnings. Grab a warm beverage and dive in!

For this special issue, I'm happy to feature a set of tools built by my good twitter-friend Daniel Saidi. We've had parallel careers, in the same 4 years working as lead iOS developers in competing book subscription services in Scandinavia, and then going indie at the same time. I'm always happy to bring more recognition to indie tools, and I am grateful for Daniel's support of the newsletter ❤️

Alternative to Spacer

Using a .frame modifier can save you a lot in performance over a Spacer, especially in lists or long horizontal/vertical stacks. David shares a number of scenarios where we can replace a Spacer with .frame and get the same behaviour:

The alternative to SwiftUI’s Spacer

Early on, SwiftUI introduced Spacer. But did you know that you can replace it with something else in most use cases?

David YangDavid Yang

Pin SwiftUI view to an edge

From iOS 15, there’s a handy safeAreaInset that allows us to place additional content extending the safe area. Without safeAreaInset, we'd have to manually calculate height of the additional content and adjust scroll view content insets manually. safeAreaInset is available from iOS 15 🙌

How to show anchor bottom view in SwiftUI

Issue #954 From iOS 15, there’s a handy safeAreaInset that allows us to place additional content extending the safe area. Shows the specified content beside the modified view. safeAreaInset allows us to customize which edge and alignment we can place our views. This works for both ScrollView, List…

Swift DiscoveryKhoa Pham

Living with flaky tests (temporarily)

Sometimes tests are failing, and we can't fix them right away. That might be the case during a lengthy refactoring process, or we might have a flaky test that fails sometimes.
While it's a viable workaround to re-run the flaky test, or comment out failing ones, XCTest has an XCTExpectedFailure API that allows a test to fail temporarily:

let options = XCTExpectedFailure.Options()
options.isStrict = false
XCTExpectFailure("Working on a fix for this intermittent problem.", options: options)
XCTAssertTrue(true, "This always works.")
XCTAssertTrue(testResultOfSomeActivity, "This only seems to work half the time.")

Read Leonardo's article that goes in depth on various scenarios when this API could be useful:

Unit Test Expected Failures in Swift - Holy Swift

Explore managing expected failures in Swift’s XCTest with expert insights on balancing hard and soft skills in iOS development.

Holy SwiftLeonardo Maia Pugliese

Reusable components without extra effort

Okay, almost :) The idea is to employ more generalised naming of types as a guide to whether the component is reusable in your code, and use variable names for context. Here's an example:

// Before
let moneyBuddyCard = MoneyBuddyCard(...)
let adviceView = AdviceView(...)

// After
let moneyBuddyCard = DecoratedCardView(...)
let adviceView = DecoratedCardView(...)

Deliver reusable components without making them reusable

Reusability and duplication are tough to balance. What if I told you that, sometimes, you don’t have to?

Writing better documentation

Editing is an important step in the process of writing documentation. Google has crafted a short, yet comprehensive guide to elevate your technical writing skills. I was amazed by how applying these simple rules transforms my writing.
At the end there's an exercise to improve this bit of text:

Determine whether or not you can simplify your document through the use of terminology that is equivalent but relatively shorter in length and therefore more easily comprehensible by your audience. It's important to make sure your document is edited before it is seen by your audience, which might include people that are less or more familiar with the matter covered by your document. The first thing you need is a rough draft. Some things that can help make your document easier to read are making sure you have links to background information, and also checking for active voice instead of passive voice. If you have long sentences you can consider shortening them or implementing the use of a list to make the information easier to scan.

I encourage you to try the exercise, and share your results!

Self-editing | Technical Writing | Google for Developers

Google for Developers

✌️
Alright, that's it for today! Let's spread the good code vibes ✨🧘🌈☀️
Thank you to Daniel with KeyboardKit for sponsoring this issue ❤️
I'm curious if you found any of the tips particularly interesting - let me know by replying to this email!