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

Hi there,

Hope your Thursday is going the way you want it to go 🍁 Let’s dive in 👇

While it’s undoubtedly a superior way to write asynchronous code, I generally stayed away from async/await-related tips, because no one could really use them yet. I wrote about the issues few weeks ago. But not for much longer!

Xcode 13.2 beta was released yesterday with support for backward deployment of async/await all the way back to iOS 13. This is achieved by embedding the Swift runtime with the app, like it was done before Swift gained ABI stability.

If you’re open to trying it out for real in your projects, the Swift team is actively seeking feedback and issue reports during this beta period to help make the backport more stable. Just download Xcode 13.2 beta and try async/await features on your iOS 13 or iOS 14 device.

A reminder about print() being slow. If you print something frequently, the lag can be really noticeable.

There’s a way out - you can use os_log API instead. It doesn’t slow the app down, and as an added benefit logs can be seen both in the debugger console and in Console.app, even on release builds from App Store. An even cooler thing is that interpolated values are redacted in release builds, unless included with %{public}@ instead of %@.

To learn more about os_log, check out the best article ever about os_log from @twannl. To learn about shortcomings of os_log, check out Problems with os_log by @mjtsai.

There are a lot of new views and modifiers in SwiftUI that can only be used from iOS 15 and up. If you support iOS 14 too, then you might use fallbacks there.

@davedelong came up with a nice approach - housing custom fallback code under .backport, so it’s easy to find usages in the project and remove fallbacks later when you drop support for iOS 14.

If it looks confusing, this short article by @ralfebert goes step-by-step into arriving at this approach: Using iOS-15-only View modifiers in older iOS versions

Custom operators are usually confusing to readers of the code, and many developers don’t like them for this reason. But I found a really nice use-case shared by @twannl. The meaning is clear enough at call site (in my opinion), and it actually would save lots of typing in a project where colors are used extensively in the code:

–

and just to end on a reassuring note - I think a lot of us feel this way right now. It’s totally normal 🥲

✌️

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 further.

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 🙌