little helpers

A 2-post collection

Useful Xcode breakpoints

Here I will document useful breakpoints when you're developing for OSX or iOS with Xcode. This is primarily for me to remember what is useful as I am googling some of these all the time.

It's sad that there are no "breakpoint-templates" that will automatically apply to all Xcode projects that you'll ever create. But enough of the introductory words, here comes the list:

Objective C exception breakpoint

Obviously the most important breakpoint there is, this one has a "template" of some sort as it has its very own menu entry:

Objective C Exception Breakpoint

So far so good, but the annoying thing is that the exception message will not be printed when the breakpoint is reached but only if you continue (and crash your program for real, and of course void your stack backtrace)

So add this to the default:

i386/iOS simulator (32Bit)

Objective C Exception Breakpoint modifications

Just add the following actions:

  • po *(id*)($esp+4)

which will print for example:

-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds

x86_64/iOS simulator (64Bit)

Use the following actions:

  • po $rdx
  • po $rcx
  • po $r8

iOS device (ARM/ARM64)

Use these:

  • po $r2
  • po $r3
  • po *(id*)($sp)

If all this is to verbose to you look at the prebuild lldb script from here:

Memory errors

Attention: This may be superseeded by the new Address sanitizer in Xcode 7

Sometimes it happens that you find a nasty memory error that is not at all obvious where it came from. Mostly it appears somewhere far away from the original error because the stack was smashed or a buffer overflow bleed into neighboring variables and overwrote something.

To find those errors you'll usually first enable all the memory protection error loggers that are available:

Memory debugging

And now you'll add a symbolic breakpoint at malloc_error_break to catch the offender that is smashing your stack right away (or at least very near to the cause)

Core Graphics Errors

All of Core Graphics error logging will go through the function CGPostError so it is sensible to add a breakpoint at exactly that location. It will break at anything Core Graphics will spit out. You know those 'XXX tried to draw to a nil context` errors may be hard to find if a lot is going on in your application at the same time.

Slow loading views

Perhaps because you used a wrong font-name? Who knows! Set a symbolic breakpoint to CTFontLogSuboptimalRequest to be notified when Core Text does not find the font directly but has to resort to a detailed search (that is very slow, on an iPad 4 it takes about 3 seconds to complete)

Auto layout

This one is obvious when it happens. But it's better to catch it directly instead of waiting for one to happen so for completeness, set a symbolic breakpoint to UIViewAlertForUnsatisfiableConstraints

Improve the debugger

Sometimes lldb can be quite stubborn:

(lldb) p self.window.bounds
error: property 'bounds' not found on object of type 'UIWindow *'
error: 1 errors parsing expression

But this can be fixed:

(lldb) expr @import UIKit
(lldb) p self.window.bounds
(CGRect) $4 = (origin = (x = 0, y = 0), size = (width = 375, height = 667))

Wow, much better, but what has this to do with breakpoints you may ask? Just try the following: Set a new breakpoint in your app delegate that is hit immediately after starting your application, set it to auto-continue and add an action expr @import UIKit.

The next run of your app will stop briefly at that breakpoint, execute that command and continue running. If you hit any other breakpoint (or press pause) the command already has been executed and lldb knows everything about UIKit already! Great!

(You may want to @import Foundation and @import CoreGraphics too)

C compiler macros and attributes to help you

"So what?", I hear you asking, but this will not be just another list of useful preprocessor macros to use (or not use) in your programs or libraries. I want to show you what you can do to make your code easier to understand, both for people and machines.

Some things mentioned here will be common knowledge for the seasoned C/C++/objective C programmer, but some things I found and am using today were buried deep in obscure system header files or compiler documentation. I want to spare you my journey finding them one by one and then refactoring your code to make use of it one thing at a time (you do refactor your old code don't you?).

Some things mentioned here will be compiler or vendor specific, but I will mention where it works and if it is a good idea to use it. Some things will be useful only if you run a static analyzer on your code as they are merely hints to clarify for ambiguities in the code. Others will give the compiler hints about optimization possibilities, and even others are used to make your API more readable to the humans that use it and even warn them if they are using it wrong.

Platform detection

#if defined(__linux__)
    /* Linux */
#elif !defined(_WIN32) && (defined(__unix__) || defined(__unix) || (defined(__APPLE__) && defined(__MACH__)))
    #include <sys/param.h>
    #ifdef __APPLE__   
        #include "TargetConditionals.h"
            /* iOS Simulator */
        #elif TARGET_OS_IPHONE
            /* iOS Device */
            /* OSX */
    #elif defined(BSD)
        /* BSD */
#elif defined(_WIN64)
    /* Windows x64 */
#elif defined(_WIN32)
    /* Windows 32 Bit */
#elif __posix
    /* At least POSIX compatible */
#elif __unix
    /* some other UNIX not catched above */


Things that work on more than one compiler and platform. Much of this will be preprocessor magic or written down in the standards, but to each thing there are caveats.

  • inline / noinline
    explicitly define if a function may be inlined. Inlining functions means
    to insert the function verbatim at the calling position instead of creating
    a branch and really call that function. This may speed up your code if used
    correctly but can increase generated machine code size. Only use for short
    "hot" functions and keep an eye on performance and size of your binary.
    Do not assume inlining speeds up your code. Increased code size may mean you'll
    probably end up ruining CPU cache locality. See also: Article of the
    WebKit crowd to reducing code size to speed up WebKit
  • __GNUC__
    this preprocessor macro is defined for all compilers that support the GNU C
    compiler extensions (at least GCC and clang do)


Things that primarily work on Apple platforms (official clang/LLVM compiler is assumed).


apply this attribute to the init function of your class that should be called by all other init-functions instead of [super init] and thus by subclasses calling up into super You'll get a warning if you forget to call the designated initializer and so could be sure all initialization goes the same path and all internal state is really set at the end of the custom init function.

In use it looks like this:

#if __has_attribute(objc_designated_initializer)
#define NS_DESIGNATED_INITIALIZER __attribute((objc_designated_initializer))

- (instancetype)init NS_DESIGNATED_INITIALIZER;
- (instancetype)initWithURL:(NSURL *)URL;

So if we forget to call init from initWithURL we get the following warning:

Warning: Secondary initializer should not invoke an initializer on 'super'
Warning: Secondary initializer missing a 'self' call to another initializer


Use instancetype to return instances of an initialized class instead of id to aid the compiler type checking. On init functions it is assumed the function returns an instance of the class object on which we called init but that is not the case for class constructor methods (often provided for convenience reasons to make the code more readable), because the compiler does not know the intent of the function.


[[[NSArray alloc] init] fooBar];

leads to:

No visible @interface for `NSArray` declares the selector `fooBar`

But the following will not lead to a warning (at least if it does not use instancetype):

[[NSArray array] fooBar];

If we'd declare the convenience function the following we'd get that first warning again:

+ (instancetype)array;


This one is again used for convenience to allow the compiler and Xcode to aid you with warnings and autocompletion when using typedef enum declarations.

Usually you'll declare a set of mutually exclusive flags or states the following:

typedef enum {
} ExampleEnum;

ExampleEnum fooBar;

If you do that, the compiler decides for you what datatype is used (usually int) and you'll have no control over that. To avoid the uncertainity a lot of people used the following construct to mitigate that:

typedef enum {

typedef NSInteger ExampleEnum;
ExampleEnum fooBar;

But that leads to a disconnect of the type name and the possible values, so autocompletion and switch ... case warnings won't work. So Apple invented NS_ENUM that ties those things together again:

typedef NS_ENUM(NSInteger, ExampleEnum) {

ExampleEnum fooBar;


If you want to use an enum as some kind of flag storage where flags are not mutually exclusive there is NS_OPTIONS. It works the same way NS_ENUM works but allows the variables of the defined type to contain combined values of multiple flags added together (= logical OR).

So if you have something like this:

typedef enum {
	FirstFlag  = 0,
    SecondFlag = (1 << 0),
    ThirdItem  = (1 << 1),
    FourthItem = (1 << 2)
} ExampleFlags;

ExampleFlags fooBar;

instead use this:

typedef NS_OPTIONS(NSInteger, ExampleFlags) {
	FirstFlag  = 0,
    SecondFlag = (1 << 0),
    ThirdItem  = (1 << 1),
    FourthItem = (1 << 2)

ExampleFlags fooBar;


Mark a function in any of your class that it needs a call to super to work correctly if subclassed and overridden. This just adds a warning if you forget to call super on the subclass. Can be a lifesaver when you'll have to debug strange behaviour or ship libraries. It tells the user of the function to make sure he knows what he's doing when he overrides the function.

Just append to your function declaration:

- (NSString *)debugMe NS_REQUIRES_SUPER;


Add format string typechecking, likely known from NSLog and printf, to your functions. The macro takes 2 arguments, the first one is the position of the format string argument, the second is the position of the ... element for the elements to include in the string.

Use like this:

void MyLog(NSString *fmt, ...) NS_FORMAT_FUNCTION(1,2);

So the compiler checks if the types of the arguments after the format string match the types defined in the format string. Additionally it will be checked if the format string is a constant string and a warning will be issued if it is not.