Issue #63

Hi there, welcome to the 63rd issue of iOS Code Review!

You might have noticed that this email comes from a new email address. This change was necessary for the new sending requirements for Gmail and Yahoo inboxes - so emails come from the trusted domain ghost.io.

That's also why I had to remove the  symbol from the email subject and sender - else it lands in gmail spam.

To make sure the newsletter doesn't land in spam in the future, mark it as starred, add the new email to contacts, or move it to your primary inbox if you use gmail.

Now let's dive in!

Serialising dictionary writes correctly

Did you know that dict[id] = data actually does two operations: first, reading the current state using the property getter of dict and then setting the new modified dictionary with the setter.

So when we want to make sure that access to the dictionary is performed serially from the same queue, it's not enough to add DispatchQueue.sync to willSet of the property.
In his article Toomas shares his story of uncovering an intermittent issue caused by an incorrect implementation and finding fix.

Avoiding subtle mistake when guarding mutable state with DispatchQueue

Last week, I spent quite a bit of time on investigating an issue which sometimes happened, sometimes did not. There was quite a bit of code involved running on multiple threads, so tracking it down…

Augmented CodeToomas Vahter

Document directory path changes

When persisting local file urls (to CoreData or elsewhere) we need to use relative urls and append the documents directory base path in runtime. Full urls to files in the documents directory might become invalid in the future. TIL!

What if we stopped nitpicking?

Some time ago I was asked one of those questions in an interview, what would I do differently today compared to the past. I had the answer - as a lead developer, I'd allow for more creative freedom in the codebase, and move away from too rigid coding guidelines that govern every little detail of writing code. There are things that matter, and things that don't. Rules that make sense for public APIs and foundation code don't necessarily make sense for feature code that changes often.

When I stumbled on this 3-year old article about the impact of nitpicking on the team culture, I could relate to it so much. Nowadays my reviews are balanced, and I learned to let go of my perfectionism. But I wish I read an article like this many years ago and didn't have to learn it by experience :D

These days my go-to approach is: automate as much as can be automated, and let the humans do what computers can't - think of architecture, edge cases, UX, and so on.

I loved this quote: "Developers like to imagine that they are composed of nothing but cold, hard logic; but actually, we are humans with unavoidable feelings and emotions."
Dan shares his story of learning the impact of too much nitpicking the hard way.

Stop Nitpicking in Code Reviews

One of the best changes I’ve made at work recently is to stop nitpicking in code reviews. Nitpicking isn’t about code that is wrong but suboptimal. It’s pointing out a variable name that could use a more appropriate word, a conditional that could be formatted more cleanly,

Dan Lew CodesDan Lew

Thinking of 2024

I'm considering to change the newsletter to be weekly, with 3 sections each time, instead of 5 sections every two weeks. It would take a bit more effort, but that way I can share more learnings with all of you! Would you like to receive the newsletter weekly? Please let me know, for example by simply replying "yes" to the email.

✌️
Alright, that's it for today! Let's spread the good code vibes ✨🧘🌈☀️
Thank you to Runway for sponsoring this issue ❤️
I'm curious if you found any of the tips particularly interesting - let me know by replying to this email!