When you need to quickly display NSArray what you do? Yes, NSLog(@”%@”, myarray), me too. But when you will do this on array fetched from CoreData what will you get? Well, something like:

So what is that? What is surprise – this is not an error, it is normal when you are fetching something, becouse of lazy loading – objects are not fully loaded until you need them. So what can we do? Just a little more work:

This way you will get your array properly displayed, the other way is to [request setReturnsObjectsAsFaults:NO] on your NSFetchRequest but if you will forget to remove it after testing your arrays will always be fully populated which can lead to memory warnings.

Seen that error today, it happened after I upgraded XCode to 7.0 – in lower version everything was ok (well, it was not but just I did not saw it). So what does it means? Somewhere in your code you are changing something that affects UI – this can be button or label text or just table data, doesn’t matters. What is important – you should not do it in background. Solution is simple just use:

Changing any UI stuff in background can work or cannot. You never know, it is always a good practice to put this on main thread.

This can be frustrating at first time, but this method is for C structures, for comparing NSString with another one just use:


Apple on Friday issued to developers a golden master build of the upcoming Xcode 6.1.1 update, bringing bug fixes for Xcode Server, the Swift programming language and Interface Builder, among others. The Xcode 6.1.1 GM, labeled build 6A2006, concentrates on fixing bugs from the most recent Xcode 6.1 release, including common SourceKit crashes in Swift and general issues with Xcode Server.
Specifically, Apple resolved multiple issues causing crash events in Swift, as well as other coding bugs, while patching permission problems, crashes and SSH handling in Xcode Server. The GM also addresses an issue in Interface Builder that would prevent opening or compiling IB documents containing a slash in its image name.
Finally, the OCUnit and SenTestingKit framework were deprecated with Xcode 6.1.1 and will be completely removed from the software in a future release. Developers are encouraged to migrate to XCTest for Xcode testing.
Alongside Xcode 6.1.1, Apple released Command Line Tools Packages for OS X 10.9 Mavericks and OS X 10.10 Yosemite, enabling UNIX-style development from Terminal.
Developers can access the Xcode 6.1.1 GM — a 2.5GB download — and the Command Line Tools Package via Apple’s developer portal.

This can be really painfull – you made you translation and at compiling time you see such error:

Don’t worry, you dont need to manually check it line by line, just open Terminal, go to folder with your Localizable.strings and enter:

you will see output like this:

which gives you exact line number and reason.

Yes, Grad Centeral Dispatch may seems big and complex. But if you need to put some work into background, its pretty easy, all you have to do is:

Simple, isn’t it? In case you want to put more CPU cycles into your background process, you can change priority to DISPATCH_QUEUE_PRIORITY_DEFAULT or even DISPATCH_QUEUE_PRIORITY_HIGH. You can use also DISPATCH_QUEUE_PRIORITY_BACKGROUND but this one will cause your code to run at very end, when all higher priorities are done.

So far I saw many examples, but not every of them is valid, follow my rules and you will get proper singleton pattern.

in MySingleton.h file:

in MySingleton.m file:

And thats all. The key is to use dispatch_once which will guarantee code inside will be executed only once per whole app lifetime. You can use it like this:

Using configuration mentioned above you may receive one of those (or another) errors:

Working solution is to remove arm64 from “Standard Architectures” and leave arm64 in “Valid Architectures”