5 min read

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 ❤️

💎 Sponsor of the week - KeyboardKit Pro

The KeyboardKit Pro SDK helps you build highly customizable keyboards for iOS. With support for 60+ languages and many powerful features, KeyboardKit Pro makes it easy to bring your functionality to brand new places.

Sign up for KeyboardKit Pro with discount code BF23-KKPRO during Black Week to get 50% off your first purchase!
Get started for free 🚀

Also check out EmojiKit to add powerful emoji features to your app, and LicenseKit to protect your closed-source software with commercial licenses. Made by Daniel Saidi.

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?

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…

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.

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

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!