Chasing UIViewController retain cycles

A retain cycle is a common memory issue preventing objects to be released. It’s happens when two (or more) objects have a strong reference one to each other. The main object can not be released because the other object has a strong reference to it, and this other object will only be released when the main object is released. Dead end, these two objects will never be released.

This can lead to random crashes due to lack of memory on your users’ phone or weird behaviours in your app due to existing but not visible objects that are interfering with the normal execution.

Do I have a retain cycle?

That’s easy to test, in your class, add a print statement in the deinit method, also add a breakpoint. Assuming that your view controller is part of a navigation controller, run your app and go to the screen then hit back, you should hit the breakpoint and “MyViewController deinit called” should appear in your console. If this is not happening, then you view controller is part of a retain cycle and will never be released.

deinit {
    print("MyViewController deinit called")

Find and fix the retain cycles

We now know that a view controller generates retain cycles, let’s try to fix them. There are several reasons why a retain cycle exists.

I passed my view controller to someone else and he is retaining me

Typical example is with delegate. Let’s say we have this class that needs a delegate


protocol MyCustomObjectDelegate {
   // some methods to be implemented

class MyCustomObject {
    var delegate: MyCustomObjectDelegate?


let myCustomObject = MyCustomObject()
myCustomObject.delegate = self

To fix the retain cycle, we need to change this a little bit:


protocol MyCustomObjectDelegate: class {
   // some methods to be implemented

class MyCustomObject {
    weak var delegate: MyCustomObjectDelegate?

Note that MyCustomObjectDelegate is now a class protocol and that the reference to this object is now weak.

Another case, slightly more subtle is possible, in this case, your delegate is not optional because you always need one and it always has to provide you with some values


protocol MyCustomObjectDelegate {
   // some methods to be implemented

class MyCustomObject {
    private let delegate: MyCustomObjectDelegate

    init(delegate: MyCustomObjectDelegate) {
        self.delegate = delegate


let myCustomObject = MyCustomObject(delegate: self)

In that case, we will need to use the unowned keyword instead of the weak keyword:

protocol MyCustomObjectDelegate: class {
   // some methods to be implemented

class MyCustomObject {
    private unowned let delegate: MyCustomObjectDelegate

    // init remains the same

A block / closure is retained

It’s also easy to generate a retain cycle when using closures. In the following example, the addInfiniteScrollWithHandler methods copies my block to eventually use it later. A copy automatically performs a retain on it, and if the block make use of self, then it’s incrementing my view controller retainCount.

tableView.addInfiniteScrollWithHandler { tableView in

The following one is similar, except that a method has been passed as the closure, this is nasty because the self is here implicit:

func infiniteScrollHandler(tableView: UITableView) {}

To fix it, we need to use a safe version of self, using the [weak self] parameters in the closure. From now, all self. occurrences have to be replaced with self?. or self!.:

tableView.addInfiniteScrollWithHandler { [weak self] tableView in

This can happen, but remember that most of the closures you are writing will probably not be retained! It’s not always necessary and therefore considered as overkill to write [weak self] and handle the optional self in all every closures. In the following example, the block will be executed directly and will not be retained, this will not generate a retain cycle.

UIView.animateWithDuration(0.25, animations: {
    self.view.alpha = 1.0


Running multiple instances of Parse Server on the same machine

When migrating from to Parse Server, I learned the hard way that NodeJS is not multi-threaded.

ParseServer is made in JavaScript with NodeJS and unfortunately, this technology doesn’t take advantage of the multiple cores your server can have.

This lead to a waste of resources: imagine that a running instance of your server is only using 25/30% CPU before latency goes up. At that point, you have to deploy a new instance of the same server to maintain a low latency. Why? Because of the use of a single thread, incoming requests are quickly queued, especially if one the request takes time to build the response.

To take advantage of the multiples cores you may have on your server, you can use a worker manager such as Throng to manage multiple instances of your Parse Server on the same machine:

Don’t ask for too many workers. The appropriate number of workers depends of the number of cores your machine has and is usually a number between 1 and (2 x NUMBER_OF_CORES) + 1.

Writing self-documenting code

Great article giving tips on how to write self-documenting good (aka good code), even though this is written for JavaScript, most of the tips can directly be applied to any languages.

15 Ways to Write Self-documenting JavaScript by Jani Hartikainen:

Note: this definitely has to be ported to Swift, any volunteer?

Having fun with iTMSTransporter

I haven’t found much about this strange iTMSTransporter API enabling developers to script communication with iTunes Connect, so I dug and it was worth it.


I have 25 In-App Purchase products that are hosted by Apple, and these products need to be updated 2 to 4 times a year. Wow, that represents a lot of time, let’s write a script.

The solution : iTMSTransporter

The iTunes Connect
 Transporter is provided by Apple, an installer and the documentation are available through iTunes Connect under the “Resources & Help” section (you need to have a valid iTunes Connect account to access). Guess what? As an Xcode user, it’s already installed since the IDE itself is using the API to communicate with iTunes Connect when you uploading binaries (for instance).

It also can be used to:

  • upload app binaries
  • upload screenshots
  • update app metadata
  • manage app pricing
  • manage In-App Purchase products
  • etc.

Well yes, that’s basically the same possibilities than Application Loader, but scriptable.

How to use it?

Once it installed, let’s say that you have added it to you path, you can use the iTMSTransporter command and try to understand something to the help message.

There are basically 3 modes that can be easily translated into three steps, plus the one where you actually edit the information you want to send to iTunes Connect.

Step 1 : lookup for metadata

In my case, I had to find metadata related to a given In-App Purchase product identifier, so the first step is to download the .itmsp package from iTunes Connect with the following command:

iTMSTransporter -m lookupMetadata -u "$ITC_USERNAME" -p "$ITC_PASSWORD" -vendor_id "$ITC_PRODUCT_PARENT_ID"

Doing such will download a package (aka a directory that OS X will not open directly) with an XML file representing ALL THE DATA about your application. If you just need to update products one by one, you can easily add filters:

iTMSTransporter -m lookupMetadata -u "$ITC_USERNAME" -p "$ITC_PASSWORD" -vendor_id "$ITC_PRODUCT_PARENT_ID" -subitemids "$ITC_PRODUCT_ID" -subitemtype InAppPurchase

Step 2 : update metadata

This is the most challenging part since you need to update the metadata.xml file by adding or editing some fields.

As I was writing a shell script, I used xmlstarlet to work with my xml file. XPath

Note 1: if you want to upload some files (screenshots, .ipa files or .pkg files), you just need to add them to the .itmsp package and update the related fields in the metadata.xml file (such as the size of the file, or the md5 hash).

Note 2: except some required field, all the non-modified fields are ignored, you can safely remove some of them.

Step 3 : verify

iTMSTransporter -m verify -u "$ITC_USERNAME" -p "$ITC_PASSWORD" -f "$ITMSP_PATH"

If this command pass, you can go to the step 4, otherwise, you should carefully read the hints “provided” by Apple in the error log.

Step 4 : upload

iTMSTransporter -m upload -u "$ITC_USERNAME" -p "$ITC_PASSWORD" -f "$ITMSP_PATH"

Note: when the upload is completed, the sent package may take some processing time to appear on iTunes Connect, especially when sending In-App Purchase packages.

Voila !

The documentation found on iTunes Connect if “helpful”, but here is the best source of information I found:, this is about uploading screenshots but the process can be easily adapted.

Did you mean: …?

I was thinking mispelling was a really hard feature to implement, but it’s in fact far more easy to do once you have the Lenvenshtein distance algorithm ready.

So I wrote a Swift extension on String to compute this distance, the algorithm is simply translated from Wikipedia pseudo code.

Tracking and character spacing on iOS

Finally got to understand how to use the “tracking” value from the InDesign files I received for an app I’m working on. Thanks to this post from devsign, this is one more step to a pixel perfect label integration.

In tools like Photoshop and InDesign, tracking is the term that describes the relative amount of spacing between characters in a string of text.

A wonderful bit about tracking: pick a value, and your text will have that same visual style, regardless of the font size. It scales[…]