3 min read

Issue #45

iOS Code Review newsletter for Swift developers | Curated code improvement tips

Hi there, welcome to the 45th issue of iOS Code Review!
I hope you enjoy the reading below šŸŒž

šŸ’Ž Supporter of the week - RevenueCat šŸ’Ž

In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it simple by providing a backend and a wrapper around Apple's StoreKit and Google Play Billing. Get started for free.

Learn more

Modern UIButton actions

With iOS 17 on the doorstep (yes, it's 3 months until WWDC), most projects have upgraded to newer minimum deployment targets. So it's a perfect time to remind about this lovely UIAction API for adding handlers to UIButtons - where we don't need to involve @objc #selectors anymore šŸŽ‰

Inline images in Text in SwiftUI

There's a lightweight way to insert images inside Text in SwiftUI - in string interpolation. If it's a custom image, it will be displayed in the original size. But if the image is an SF symbol, it will take on view modifiers applied to the Text - font, symbol variants, color, etc.

Deciphering Core Data error codes

CoreData produces nondescriptive errors such as Ā Domain=NSCocoaErrorDomain Code=1610 "The operation couldn't be completed. (Cocoa error 1610.) . There's a way to quickly check the meaning of the error code - by opening CoreDataErrors.h with Quick Open (just make sure to open the original and not the Swift interface). Alternatively, it's available online: CoreDataErrors.h as a gist on GitHub

Storyboards vs programmatic layout

When we talk about UIKit, programmatic layout has lots of benefits - easier code review, traceable changes via git, and code is a single-source-of-truth. But some teams prefer storyboards for their own reasons. In that case, here's an article with advice on how to improve quality of life when working with interface builder:

  • understanding the XML structure
  • what issues to look for during code review
  • avoiding merge conflicts by locking against changes

Note: In the article the author mentions faster compilation time with storyboards vs programmatic layout. That can be true with lots and lots of layout code, but also the code structure itself affects compilation time, not only the amount of it. For example, if you use a global spacing constant, changing that one value can cause almost a full re-compile, while changing one storyboard file only recompiles that one file.

Why did we change our iOS rule to allow using Storyboard?
Our UI creation rule was creating a UI programmatically. But recently, we changed it.

āœŒļø
Alright, that's it for today! Thank you to RevenueCat for sponsoring this issue ā¤ļø
I'm curious if you found one of the tips particularly interesting - let me know by replying to this email!