Understanding Manual Retain Release in Objective-C

You might often hear programmers claiming Automatic Reference Counting (ARC) is one of the best things that happened to Objective-C. It relieves you, the programmer, from typing out redundant code. It’s a convenience if you’ve ever written any Manual Retain Release (MRR) code. But if you joined the club later and haven’t actually every written any MRR code, you might get a wrong impression that MRR is verbosely spammed with calls to retain and release. One factor could be that people assume MRR code is equivalent to C style memory management, where you need to call malloc and free and then figure out complex ways to manage the ownership. Another factor could be because a lot of ARC vs MRR discussion overlook the fact that MRR already has reference counting, something equivalent of what was finally introduced in C++11 with smart pointers. Another confusion might have to do with the fact that ARC is not really clear on memory ownership rules. So some people might assume every assignment operation is either a transfer of ownership or claiming ownership, which isn’t entirely false, but not in the sense of how retain and release is designed to work.

Multiple objects in single frame with Metal

It’s been a long time since I touched Metal. Recently, I’ve been poking at Metal again. This brought me to an interesting challenge. So far I’ve been rendering single objects and when I try to render more than one item I face an interesting problem. Let’s see if I can fix that.

Objective-C Properties Problems

Objective-C 2.0 introduced properties as syntactic sugar over getter and setter a very long time back. Properties are very convenient for most of the things but there are quite a few issues that I feel always with them. Today I would like to document them.

Objective-C Subclass Factory Pattern

It’s not an secret that creating instances in Objective-C can be very verbose. It doesn’t help that we don’t have default values and by default everything is initialized to zero. It gets even more verbose when you want to write a robust code and don’t want to expose properties as readwrite where they shouldn’t be. That said, a lot of times keeping them readwrite is better than wiring things around it. Remember that properties in Objective-C, unlike say C++, are just syntactic sugar over getters and setters.

Objective-C safe downcasting

Swift has this nice concept of optional chaining which is used in a lot of places. One really good use case is when down casting a type the operation becomes a no-op if casting to an incorrect sibling. To illustrate take a look at this Swift example code: