How to prevent Fabric from launching when building your XCode project

Recently, Fabric has been acting really buggy freezing up and mass opening many browser tabs.  If you use Fabric and don’t use the app or don’t want it to launch everytime you build your XCode project, you have a couple options.

Option #1 Prevent Fabric from launching after uploading your project’s DSYM file.

Open up the run script: Pods/Fabric/run and change:

eval $DIR$PATH_SEP$UPLOAD_COMMAND > /dev/null 2>&1 &


eval $DIR$PATH_SEP$UPLOAD_COMMAND;killall Fabric > /dev/null 2>&1 &


Option #2 Only upload DSYM when archiving builds for release.

Check the “Run script only when installing” option under Build Phases:

Screen Shot 2016-04-23 at 5.30.21 AM



How to speed up slow Swift compile times

Swift code compiling slowly? Here’s how to find out what’s causing it.

Under Build Settings, add “-Xfrontend” “-debug-time-function-bodies” to your Other Swift Compiler flags.

Open terminal.

List files sorted by slowest compile time:

$ xcodebuild -workspace MyProject.xcworkspace -scheme MyProject clean build | grep [1-9].[0-9]ms | sort -n

List functions grouped by slowest compile time:

$ xcodebuild -workspace MyProject.xcworkspace -scheme MyProject clean build | grep [1-9].[0-9]ms | awk '{arr[$2]+=$1} END {for (i in arr) {print arr[i], i}}' | sort -n

Print total compile time:

$ xcodebuild -workspace MyProject.xcworkspace -scheme MyProject clean build | grep [1-9].[0-9]ms | sort -n | awk '{SUM+=$1}END{print SUM}'

More here:

Fix random mergeChangesFromContextDidSaveNotification: crashes

Getting crashes when merging NSManagedObjectContexts?

1. Clean up leaked observers. We were getting a really random crash trying to merge contexts between threads. Turns out we forgot to clean up an observer on one of our views that was using a NSManagedObject being merged. When the object changed, the observer fired on a deallocated view. Enables zombies to find the culprit.

2. Merge on the proper thread. If you must use multiple contexts, the recommended configuration is one context per-thread. When interacting with a context, you must make sure to do so on the proper thread. Block example:

    - (void)contextDidSaveNotification:(NSNotification*)saveNotification {
        [self.mergeContext performBlock:^{
            [self.mergeContext mergeChangesFromContextDidSaveNotification:notification];

3. Fault in updated objects. This is a last resort type of thing but it’s possible the object for some reason doesn’t exist in the context we’re merging to yet (even though it should). I found that faulting in updated objects before merging fixed this issue before.

4. Avoid manipulating an object across contexts simultaneously. I’ve seen it cause crashes (awakeFromSnapshotEvents: message sent to deallocated instance), especially when using nested contexts.

The case of NSCursor being mysteriously reset on the initial drag

Cursor being mysteriously reset on the first drag? It’s somehow caused by having a NSToolbar on your window.

Sample project available here:

After some investigating with a NSCursor category:

@implementation NSCursor(Hack)
- (void)set
    NSLog(@"%@",[NSThread callStackSymbols]);

I found this fixed it (use at your own risk!):

@interface NSDragDestination : NSObject {
    unsigned long long _lastDragDestinationOperation;
@implementation NSDragDestination(NSToolbarFix)
- (void)_setLastDragDestinationOperation:(unsigned long long)arg1;
    // Fixes NSToolbar breaking default NSCursor behavior, e.g., cursor image on initial drag.
    _lastDragDestinationOperation = arg1;

How to store Blocks in NSDictionary

Are you getting a crash trying to store your block in a NSDictionary instance?


Blocks “just work” when you pass blocks up the stack in ARC mode, such as in a return. You don’t have to call Block Copy any more. You still need to use [^{} copy] when passing “down” the stack into arrayWithObjects: and other methods that do a retain.


As an optimization, block storage starts out on the stack—just like blocks themselves do. If the block is copied using Block_copy (or in Objective-C when the block is sent a copy), variables are copied to the heap. Thus, the address of a __block variable can change over time.

This means that the block variables in your function are stored in the stack, and when the function returns, they get wiped out. If you’re using ARC, your crash is caused by block variables being over released. Calling copy on a block makes block variables stick around.

Here’s what it looks like:

        __weak id weakSelf = self;  // Weak block variable prevents retain cycle.
        void (^myBlock)() = ^() { 
            NSLog(@"Called from %@!", weakSelf);
        // Copy the block so the block variable sticks around!
        NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:[myBlock copy], @"MyBlock", nil];