At WWDC 14, Apple introduced its new programming language: Swift. Nobody knows for sure what will happen to Objective-C, but one can only guess it won’t be around for long. My guess is that Apple will be accepting ObjC apps up till iOS 10, but that is just my guest.

You can unregister a UICollectionView supplementary view by re-registering it with nil class as stated in Apple’s docs. (Remember to use the same reuseIdentifier).

[self.collectionView registerClass:nil
        forSupplementaryViewOfKind:UICollectionElementKindSectionHeader
               withReuseIdentifier:kHEADER_IDENTIFIER];

Anyone that have recently developed any pods for Cocoapods know that resources should be gathered using the resource_bundles option. What is quite hard to figure out is how, exactly, to access those resources once they’re set up in the bundle. It seems obvious now that I got it working, but I struggle a lot since there wasn’t anything in Stackoverflow or anywhere else that provided the answer I came up with.

After setting up the resource_bundles, Cocoapods copies the resources found in a “resources” folder within the Pods project, but none of them are added in the target’s “Copy bundle resources”. For that reason, I couldn’t access any of the Pod’s images or xibs in my project. Every time XCode threw me this error:

‘Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘Could not load NIB in bundle:<{PATH_TO_APP}> (loaded)’ with name ‘{VIEW_CONTROLLER_NAME}’

The obvious solution that wasn’t listed anywhere is using the Cocoapods generated bundle (which the folder actually doesn’t exist) as a NSBundle:

NSString *bundlePath = [[NSBundle mainBundle] pathForResource:@"MyBundle" ofType:@"bundle"];

NSBundle *bundle = [NSBundle bundleWithPath:bundlePath];

MyViewController *viewController = [[MyViewController alloc] initWithNibName:@"MyViewController" bundle:bundle];

[self.navigationController pushViewController:viewController animated:YES];

Yes, it’s that simple, that obvious, though it’s not listed anywhere. I believe to be prudent and convenient to write about it in order to help anyone who encounter themselves in the same situation as I did.

This morning, Cicada 3301 went back to active! In his/hers Twitter account used on last year’s challenge there was new link to an image posted on imgur.

First Chapter

Reproducing the tradicional previous steps, by extracting the image using outguess we came onto a message, once again signed. Its authenticity could be proved using Cicada’s previous known public key.

Now let’s get our hands dirty! The first task was easy, since it’s steps were already elucidated on previous years. Now things start to get interesting.

If you’re interested in following the challenge progress, Uncovering Cicada is on a good pace.

Good luck, and good hunting!

I believe that every iOS developer is already aware of Apple’s new directive forbidding any apps using frame to be submitted to the Appstore when the new iOS 7 goes public. That means that ALL new app will have be developed using this tool created by the son of a devil called autolayout.

Anyone that has already used autolayout knows that margin, width, height and other properties are calculated in runtime, therefore, they consume sometimes unnecessary CPU time. For some inescrutable reason, Apple decided to create this new concept from scratch to ease working with different sized screens, while they could easily reuse existing CSS concepts like marginpadding, among others. In addition to being extremely confusing (a UIView's margin constraints are in its superview), having a pitiful syntax  (“V:|-(-5)-[view1]-(>=10)-[view2]-(912837)-|”)autolayout also makes everything slow.

Protip: if you’re configuring your coinstraints via code, never forget seting self.translatesAutoresizingMaskIntoConstraints = NO in your view. It took me a couple of coffee cups to realise this was the reason why my  constraints weren’t being executing along with [self layoutIfNeeded].

I recently had to work with a UICollectionView and the scroll was getting really laggy. Anytime a new cell was loaded, the framerate dropped. After spending a few hours trying to find the root of the problem with a couple of friends (we even considered the problem being the SDK’s dequeue thanks to  Profiler) some inspired insight hit us and we decided to disable autolayout on the UICollectionViewCell's xib and everything flowed like a beautiful stream under the morning sunlight of tropical woods. So let us analise what happened: Apple created a new concept, from the grounds, that theoretically would solve all problems when working with screens of different sizes, but this devilish concept is composed of runtime calculated values that ruin the app’s smoothness. Yep, it gets hard to work happily…

This view that is the UICollectionView's cell will not have autolayout. Nobody knows what will happen when we submit the app to the Appstore and we sincerely hope that Apple doesn’t mind this view that, although is not explicitly using frames, also is not configured to accept autolayout.

I’m yet to find an iOS developer that has nothing to complain about this weird invention, but, as usual, Apple’s “this is what we want, so deal with it” policy doesn’t give us any alternatives. Instead of easing developers’ work, they’re making our daily lives every more difficult while Android scores another point Apple is walking backwards.