First of, a block in C is defined by { ... }. Identifiers defined inside this block have scope visibility / lifetime (used from now on interchangeable) limited to that block. The if (x) statement in Apple’s example above is creating such a C block, in which a struct is created and that struct is assigned to (Objective-C) block (called closures from now on for easier differentiation).
Every C block creates a new visibility scope were stack variables are stored (stack area) similar to stack frames. Which means after the block is closed it is not save any more to access these memory locations.

Closures are (apparently) the only Objective-C objects that start on the stack, the problem with that is, that the visibility is gone after the closing brace of the if-then-else and hence the block is lost. So the block has to be “saved” by copying it from the stack to the heap before the C block is finished.

Compilers

If you run the example code from Apple you will realise, that the code works flawless. It does not crash with a dreaded segfault and it even behaves exactly as you would expect it to.
Why? This is because clang does not reuse stack areas that were previously used and therefore nothing overwrite the memory location with something different (assuming you are not doing it from a different thread). The situation looks different if you are using gcc with the -O2 flag. gcc then reuses stack areas and overwrites your stack area. Since gcc is not capable of closures and clang doesn’t reuse stack areas you might be never run actually into a problem (There is a caveat tought[1]). This behaviour is, though, just an implementation detail that might change or vary from compiler to compiler and therefore you should not bet on it, it might change.
You can find some demo source code here that shows gcc -O0 versus gcc -O2.

Closures inside of an Array

A time where you run into problems is, when you try to save closures in an array like this:

The output is “2 2 2” instead of the expected “1 2 3”. This is because the stack area used for the for loop is the same for all iterations and therefore every new created closures overwrites the closures created in the previous iteration. In b[1], b[2] and b[3]is just a pointer stored to the closure and since the place of creation on the stack was the same for all three closures the pointer is the same which leads tob[1]==b[2]==b[3]`.

I wrote a small program that shows the different behaviours of closures on stack, closures on heap and blocks that use different stack areas.

You can find this code in my github gists here for easy copy and compile[1].

The code is commented so you should really quickly see what the difference between copy and strong is doing here. By marking the pointer copy the object is copied during assignment and not just the pointer is copied over. For that to work, the NSCopying has the be implemented for that class. Luckily NSString, NSDictionary, and many others already support this protocol.

So now after you know what it makes for a difference with pointers, let’s see when you would want to use one over the other.

Even though per.name is NSString and should not be mutable it is possible to alter it through the 2nd pointer to the same address which is a NSMutableSring pointer. This said you can use copy to help you prevent this kind of trap so you might always want to use copy if the immutable class you are using conforms to NSCopying.

On the other hand, if you keep good track of your pointers and you know what you are doing, this could save you time during assignment because the assignment is much faster than copying the whole object [2]. So if you are only using immutable objects pointer assignments can help get some more speed. But remember

If your project doesn’t build (or link) any more now, just reopen Xcode.

This is how you can decide in which target you are inside your code:

#if TESTS
NSLog(@"I'm the tests target");
#elif TOOTH
NSLog(@"I'm the Tooth target");
#else
NSLog(@"Error: You added a new target and didn't set the Macros");
#endif

Adding a new test target

Of course you want to be able to write tests for your new target as well.

Go to the “Test Navigator”

On the bottom left click the “+” sign and chose “New Test Target…”

Select the Target you want to build tests for

WAIT! Don’t worry that you don’t see any tests for the new test target, just wait…. until it’s there, or restart Xcode

Right click on it and enable your test target

Go to “Build Settings” and select your tests target

Framework Search Path: Add “$(SRCROOT)” otherwise you will get errors with Frameworks like Crashlytics that it can’t find #import “Crashlytics/Crashlytics.h” (I add this as a project key value so I don’t have to do it for every new test target)

Both are of course possible in Spotlight as well by simply searching for:

author:atp
author:5by5

Find all pictures taken with an iPhone 4S on the last day of the year 2011 and the first day of 2012. The range includes the from date but not the until date.

$ mdfind 'kind:image created:31/12/11-2/1/12 model:"iPhone 4S"'

mdls

But how to figure out these strange looking search fields, that’s where mdls comes into play.

$ mdls <file>

Prints out all meta information fields for that file. With mdfind you can then search for those fields.

If you are curious about all possible field values you can get them with

$ mdimport -X

and

$ mdimport -A

Be warned, it is a lot of information.

Final note

It’s worth having a look at the man page of these commands and the help provided with mdfind -h because the information is not consistent. For example the man page doesn’t tell you about the -s flag which brings smart folders to the command line.

And for the curious how I came across mdfind. I stumbled upon that command while reading this blog post by Brett Terpstra.

“Project” -> “Update from files…” -> add the en.lproj/Localizable.strings -> “Update the project from a new version of these files”

click “Update”

translate

2) This is the workflow if you updated the sv.lproj/Localizable.strings files e.g. manually added them in vim or you had someone translate it for you

It might be always good idea to update your Base language first so you can directly see after important the Swedish Localizable.strings file which “Translation Keys” have changed and need updating or if the translator got everything.

When you are writing Objective-C code and using git you probably realised that the `git diff` is not mentioning the function name in which the change occurred. This can easily be changed by just running following cmd inside your git repository:

Have folder with all the Mavericks wallpapers and screen saver images but without wasting a lot of space. Why duplicate all of them, so you can set it as the folder that should be used for randomly choosing a background plus you can delete the ones you don’t want.

So we generate a folder in which we link all the default Mavericks wallpapers + screen saver images and set this as our folder to chose background images from, here’s the script: