Google Depot Tools bug on iOS

Hope it will save some time for you. If you see

AssertionError: Multiple codesigning identities for identity: iPhone Developer

and don’t know how to fix, when building webrtc, libyuv or any other libraries with Google’s depot tools, simplest fix you can do is just remove the assertion. You don’t need developer’s profile and binary singing for libraries. That’s obvious for you, but not obvious for the script. 🙂 In my case, I found the assertion in the /chromium/src/tools/gyp/pylib/gyp/

P.S. Found similar post on Stackoverflow.

Memory Leaks in [UIImage imageNamed] (iOS)

Yep, if you see your app bailing out with out of memory, you probably want to check how you load images into UIImage instances. Apparently that problem existed since iOS SDK was released and has never been fixed. At least I could reproduce it back in 7.0.1. It’s not exactly a memory leak, though you may see app memory usage going up in Allocations and Leaks tool after you load large images.
Technically it’s not a bug. More like an oversight on Apple’s side. UIImage does caching for images. Problem is that memory cache may take too much memory and make app eventually crash in OUM situation. It’s also a time waster for people who are trying to catch memory leaks issues that don’t exist and, believe me, tools won’t help you much finding the issue.
So, if you dynamically load images with [UIImage imageNamed], try to replace it with non-caching alternative:


- (UIImage *)imageNamed:(NSString *)filename
 NSString *path = [AppUtils pathForResource:filename];
 UIImage *img = [UIImage imageWithContentsOfFile:path];
 return img;


Apple’s docs confirms that imageNamed method indeed uses an image caching:

This method looks in the system caches for an image object with the specified name and returns that object if it exists. If a matching image object is not already in the cache, this method loads the image data from the specified file, caches it, and then returns the resulting object.

Unfortunately, Apple does not provide a mechanism to control how images cached, so you have no choice but use the code similar to the example I’ve written above. If you need a cache for your images, then… well, you need to implement your own cache. Image caching implementation is outside of the scope of this article I’ll probably get back to it later. 😉

UITextView bug in iOS 7.0

Just stumbled upon an amusing bug in iOS 7. UITextView refused to change font size and color in Storyboard and xib files. Those storyboards were converted from iOS 5 format long time ago and so far I have not had any incompatibility issues until now. Whatever I was trying, UITextView controls did not want to change the font!

After hours of random experiments and googling I’ve found a workaround. Change font and color programmatically, but… you have to make UITextView editable first. You’ve heard that right. So code should look like this:

textView.editable = YES;
textView.font = [UIFont fontWithName:@"Arial" size:24];
textView.editable = NO;

P.S. Thanks Apple for all wasted hours!

Proudly powered by WordPress
Theme: Esquire by Matthew Buchanan.