View profile

 iOS Code Review | Curated code improvement tips - Issue #5

 iOS Code Review
 iOS Code Review
@ios_code_review
Hi there,
Hope your Thursday is going the way you want it to go 🌟
Let’s dive in right away!

Check your back buttons
Do you remember about this obscure feature added in iOS 14? Holding the back button shows the navigation stack history and lets you navigate to any item. Cool feature, right? Not so fast…
The titles are taken from the back button. If you’re still hiding the back button titles by setting navigationItem.backButtonTitle = "" , you will have this bug, where rows are just empty. I checked some popular apps and many of them have this issue 😵
Since iOS 14, there’s a proper way to hide the back button title by using backButtonDisplayMode. @sarunw wrote a detailed guide on it, make sure to check it out!
PS. if you’re on SwiftUI, remember to add the .navigationTitle(_:) modifier even when you hide the navigation bar on that view.
the nasty history stack bug. source: sarunw.com
the nasty history stack bug. source: sarunw.com
A new way to manage the back button title in iOS 14 with backButtonDisplayMode | Sarunw
A new way to manage the back button title in iOS 14 with backButtonDisplayMode | Sarunw
Apple adds a new way to control where the back button will pick up its title. Let’s see how this make thing a lot easier going forward.
sarunw.com
On force unwrapping
Yet another debate on force unwrapping happened last week. With usually no end in sight for this polarising topic, we might have found the answer.
I loved this perspective from @johnhaney: both sides of the debate have the same goal - to account for the nil cases. The only difference is that for some, it’s to think of it right away, and for others, only to do that if&when the crashes happen in production and become a problem.
Check the whole thread if you want to read other interesting opinions.
John Haney
@mattie Yep. Good common ground there. Avoiding ! because nil is scary and crashes are bad is the surface level. The nil case being accounted for properly is “the right way” and for you that’s crash and fix it if the crash ever happens. For me, it’s soft unwrap and think about nil case.
Testing throwing code
Test code is also code. @nicklockwood shares three tips for modernizing the implementation of your unit tests with XCTUnwrap and marking test functions as throwing:
Nick Lockwood
Some maybe non-obvious tips when using XCTests in Swift:

1) All XCTAssert functions take a throwing autoclosure, so instead of:

XCTAssertNoThrow(try foo())
XCTAssertEqual(try! foo(), bar)

You can just write:

XCTAssertEqual(try foo(), bar)

And if foo() throws the test fails
Nick Lockwood
2) If you need to call throwing functions outside of an assert, there's no need to wrap your test body in do/catch: you can mark the test function itself as throwing and the test will fail if it throws:

func testFoo() throws {
let bar = try baz()
XCTAssertEqual(foo(), bar)
}
Nick Lockwood
3) Avoid force-unwrapping Optionals in tests because if the unwrap crashes it will halt the entire test run instead of just failing the test. Instead you can use XCTUnwrap():

let nonOptionalValue = try XCTUnwrap(optionalValue)

XCTUnwrap() both fails the test and throws if nil.
Pro rebase tip
If you’re using rebase and are switching branches in the process, this tip will save you a bunch of friction. This is an older tweet, but I regularly meet people who are unaware of this trick, so here it is :)
If you’re unsure why one would want to use rebase, I recommend reading the Demystifying Git Rebase article series.
Marina Gornostaeva ✨
I use rebase a lot, and find using remote branches so much easier - no need to get the local base branch up to date:

git fetch
git rebase origin/master

vs

git checkout master
git pull
git checkout mybranch
git rebase master

Hope this helps someone make their workflow better✨
🤘
Alright, that’s it for today.
Did you enjoy this issue? Let me know by pressing the buttons below, so I can improve the newsletter.
Got feedback? Want to see more, or less of certain kinds of tips? I’d love to hear from you. Reply to this email or reach out on Twitter via @ios_code_review 🙌
Did you enjoy this issue? Yes No
 iOS Code Review
 iOS Code Review @ios_code_review

Bi-weekly newsletter amplifying code improvement tips from the Apple developer community in a bite-sized format. Swift, Objective-C, iOS, macOS, SwiftUI, UIKit and more. Curated by Marina Gornostaeva and published every other Thursday.

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.