What’s new in Swift 4

There’s very good article on most important changes in Swift 4 by Ray Wanderlich here:
Most important changes are in containers. They promoted strings to containers finally! A lot of cleanups and improvements.
I found Generic Subscripts a good addition. I’ve tried to use generics in my custom class and ran into the fact that I can’t create a subscript. Now I can.
Check it out!

NSMutableArray implementation

Stumbled upon on very good deep dive into NSMutableArray implementation. When I just started working on iOS and MacOS development, somebody told me that NSMutableArray is based on a circular buffer, so it’s very efficient for queues and stacks as well. I remembered that and as 99% of engineers never really cared about details. Besides, Apple never released sources for its core classes. However curious minds, as usual, got to the bottom of the issue.

Here’s very well written article on implementation details.

Swift 3.0 changes

Erica Sadun wrote a good article on what’s coming up in Swift 3.0. Funny, how many people noticed that “++” and “–” operators are going to be cut. Honestly, it’s not important thing in the world of iterators and dynamic arrays. However, I don’t like the trend of calling indexes evil. People, do you understand what random access in arrays existed for!? How about matrixes and vector operations? Programming is not just about traversing sets and maps.
Another takeout from the Swift 3.0 is that most of improvements are in the department of code styling, syntax sugaring, interoperability API’s and future versions of Swift, meaning that language finally becomes stable. It’s a good thing, right? 🙂

Anyway, here’s the article.

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/xcode_emulation.py.

P.S. Found similar post on Stackoverflow.

Nice SWIFT tutorial from AirPair

In case if you want to get a basic introduction on what SWIFT is all about, look here:

Most popular iOS project on github

It’s the gitignore! 😀

Here it is: https://github.com/github/gitignore/blob/master/Objective-C.gitignore

And it has 22 contributors and 4812 forks! Wow!

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.