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

Hi there,

It’s that Thursday again 🥳 I found so many gems in the last few weeks, that today’s issue contains more tips than usual. I also re-tweet additional tips throughout the week that didn’t make it into the newsletter, so make sure to follow @ios_code_review for even more tips.

SwiftUI previews can be very handy for other use-cases besides previewing SwiftUI views. 

You can use previews to preview UIKit views, which can save you dozens of hours in rebuilding to see your changes:

SwiftUI previews can also be used to preview app themes and other code-only visuals such as generated images:

Swift’s strings are unicode-compatible in the best way, counting the real displayed graphemes as the user would see them.

We need to be careful though when working with NSString APIs, because they deal with unicode differently. In the example below, print((word as NSString).length) would print 5 , not 4. So be careful not to apply ranges returned from NSString-based APIs to String instances.

SFSymbols are really powerful these days. They support thickness, styling and even multiple colors. What you see here on the screenshot is achievable with just native APIs on iOS 15. For an overview on how to use SFSymbols in SwiftUI and UIKit, check out The Complete Guide to SF Symbols by Paul Hudson. There’s also an official Mac app for browsing and previewing all available symbols.

Sometimes it’s useful to test not only what a type does functionally, but also that there are no retain cycles and an instance deallocates as expected. This can be useful for view controllers and other complex classes dealing with closures and dependencies, where retain cycles are common.

Here’s a short snippet by @ZiadeMarcus for verifying that an instance has deallocated after a test. It uses addTeardownBlock which is pretty neat on its own and can be used for other purposes too.

We write unit tests with the intention that they pass, but they really help us when they fail and catch errors in our code. So we should strive to have useful failure messages that hint at what’s wrong. Not all assert failures provide insight out of the box - @basthomas gives an overview of commonly used XCTAssert* functions and how their failure messages are reported:

In iOS 15 you can do po [tableView _rowData] in the debugger to print the internal geometry (e.g. heights, y-offsets for each row, etc) of the table view. This can be useful to track down why things look the way they do. For Swift, it would be po tableView.value(forKey: "_rowData”)!. This tip was shared by @smileyborg.

Another trick is to print app’s view controller hierarchy with po [UIViewController _printHierarchy]:

🤘

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 🙌